| Message ID | 1472033024-14890-4-git-send-email-riteshh@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/24, Ritesh Harjani wrote: > This adds support for sdhc-msm controllers to get supported > clk-rates from DT. sdhci-msm would need it's own set_clock > ops to be implemented. For this, supported clk-rates needs > to be populated in sdhci_msm_pltfm_data. > > Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> > --- Please include the DT binding review list in binding updates. > .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + > drivers/mmc/host/sdhci-msm.c | 60 ++++++++++++++++++++++ > 2 files changed, 61 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > index 485483a..6a83b38 100644 > --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > @@ -17,6 +17,7 @@ Required properties: > "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) > "core" - SDC MMC clock (MCLK) (required) > "bus" - SDCC bus voter clock (optional) > +- clk-rates: Array of supported GCC clock frequencies for sdhc, Units - Hz. > Why not use OPPv2 binding for this? We already have a way to express frequencies for devices with that binding, and we'll need to attach voltages to those frequencies at some point in the future if we want to handle DVFS on these devices.
Hi Stephen, On 8/26/2016 3:57 AM, Stephen Boyd wrote: > On 08/24, Ritesh Harjani wrote: >> This adds support for sdhc-msm controllers to get supported >> clk-rates from DT. sdhci-msm would need it's own set_clock >> ops to be implemented. For this, supported clk-rates needs >> to be populated in sdhci_msm_pltfm_data. >> >> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> >> --- > > Please include the DT binding review list in binding updates. > >> .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + >> drivers/mmc/host/sdhci-msm.c | 60 ++++++++++++++++++++++ >> 2 files changed, 61 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >> index 485483a..6a83b38 100644 >> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >> @@ -17,6 +17,7 @@ Required properties: >> "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) >> "core" - SDC MMC clock (MCLK) (required) >> "bus" - SDCC bus voter clock (optional) >> +- clk-rates: Array of supported GCC clock frequencies for sdhc, Units - Hz. >> > > Why not use OPPv2 binding for this? We already have a way to > express frequencies for devices with that binding, and we'll need > to attach voltages to those frequencies at some point in the > future if we want to handle DVFS on these devices. > OPPv2 may not work out in this case. This was also discussed at [1]. These clk-rates are not as per voltage points(or any OPP) but as per bus speed mode request from higher layer. [1] - https://patchwork.kernel.org/patch/9204879/ Thanks Ritesh -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/30, Ritesh Harjani wrote: > On 8/26/2016 3:57 AM, Stephen Boyd wrote: > >On 08/24, Ritesh Harjani wrote: > >>This adds support for sdhc-msm controllers to get supported > >>clk-rates from DT. sdhci-msm would need it's own set_clock > >>ops to be implemented. For this, supported clk-rates needs > >>to be populated in sdhci_msm_pltfm_data. > >> > >>Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> > >>--- > > > >Please include the DT binding review list in binding updates. > > > >> .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + > >> drivers/mmc/host/sdhci-msm.c | 60 ++++++++++++++++++++++ > >> 2 files changed, 61 insertions(+) > >> > >>diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > >>index 485483a..6a83b38 100644 > >>--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > >>+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt > >>@@ -17,6 +17,7 @@ Required properties: > >> "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) > >> "core" - SDC MMC clock (MCLK) (required) > >> "bus" - SDCC bus voter clock (optional) > >>+- clk-rates: Array of supported GCC clock frequencies for sdhc, Units - Hz. > >> > > > >Why not use OPPv2 binding for this? We already have a way to > >express frequencies for devices with that binding, and we'll need > >to attach voltages to those frequencies at some point in the > >future if we want to handle DVFS on these devices. > > > OPPv2 may not work out in this case. This was also discussed at [1]. > These clk-rates are not as per voltage points(or any OPP) but as per > bus speed mode request from higher layer. > That post you link to had a response from Andy that echoed the same sentiment and then no reply. Are they a set of frequencies the device can operate at? Yes. Do they have associated voltages that aren't expressed in this patch? Yes. Perhaps I've missed something though and the index of the array of rates corresponds to some bus speed mode? That isn't clearly expressed in the binding. Do the frequencies come from some spec for those bus speed modes? Either way, I'd like to understand why we need to put frequency tables into DT (hint: the commit text should explain that).
Hi Stephen, On 9/7/2016 9:44 PM, Stephen Boyd wrote: > On 08/30, Ritesh Harjani wrote: >> On 8/26/2016 3:57 AM, Stephen Boyd wrote: >>> On 08/24, Ritesh Harjani wrote: >>>> This adds support for sdhc-msm controllers to get supported >>>> clk-rates from DT. sdhci-msm would need it's own set_clock >>>> ops to be implemented. For this, supported clk-rates needs >>>> to be populated in sdhci_msm_pltfm_data. >>>> >>>> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> >>>> --- >>> >>> Please include the DT binding review list in binding updates. Sure, will do it. >>> >>>> .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + >>>> drivers/mmc/host/sdhci-msm.c | 60 ++++++++++++++++++++++ >>>> 2 files changed, 61 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>> index 485483a..6a83b38 100644 >>>> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>> @@ -17,6 +17,7 @@ Required properties: >>>> "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) >>>> "core" - SDC MMC clock (MCLK) (required) >>>> "bus" - SDCC bus voter clock (optional) >>>> +- clk-rates: Array of supported GCC clock frequencies for sdhc, Units - Hz. >>>> >>> >>> Why not use OPPv2 binding for this? We already have a way to >>> express frequencies for devices with that binding, and we'll need >>> to attach voltages to those frequencies at some point in the >>> future if we want to handle DVFS on these devices. >>> >> OPPv2 may not work out in this case. This was also discussed at [1]. >> These clk-rates are not as per voltage points(or any OPP) but as per >> bus speed mode request from higher layer. >> > > That post you link to had a response from Andy that echoed the > same sentiment and then no reply. > > Are they a set of frequencies the device can operate at? Yes. Do > they have associated voltages that aren't expressed in this > patch? Yes. > > Perhaps I've missed something though and the index of the array > of rates corresponds to some bus speed mode? That isn't clearly > expressed in the binding. Do the frequencies come from some spec > for those bus speed modes? Either way, I'd like to understand why > we need to put frequency tables into DT (hint: the commit text > should explain that). > As discussed offline, I will get back on this. Regards Ritesh -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, August 24, 2016 3:33:38 PM CEST Ritesh Harjani wrote: > #define CMUX_SHIFT_PHASE_SHIFT 24 > #define CMUX_SHIFT_PHASE_MASK (7 << CMUX_SHIFT_PHASE_SHIFT) > > +struct sdhci_msm_pltfm_data { > + u32 *clk_table; > + int clk_table_sz; > +}; > + > struct sdhci_msm_host { > struct platform_device *pdev; > void __iomem *core_mem; /* MSM SDCC mapped address */ > @@ -83,6 +88,7 @@ struct sdhci_msm_host { > struct clk *bus_clk; /* SDHC bus voter clock */ > struct mmc_host *mmc; > bool use_14lpp_dll_reset; > + struct sdhci_msm_pltfm_data *pdata; > }; > > /* Platform specific tuning */ > Just noticed this. Please don't add another structure, just put the new members into struct sdhci_msm_host directly. We only need platform_data structures for drivers that also work with old-style board files, which this one doesn't. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd, On 9/12/2016 1:03 PM, Arnd Bergmann wrote: > On Wednesday, August 24, 2016 3:33:38 PM CEST Ritesh Harjani wrote: >> #define CMUX_SHIFT_PHASE_SHIFT 24 >> #define CMUX_SHIFT_PHASE_MASK (7 << CMUX_SHIFT_PHASE_SHIFT) >> >> +struct sdhci_msm_pltfm_data { >> + u32 *clk_table; >> + int clk_table_sz; >> +}; >> + >> struct sdhci_msm_host { >> struct platform_device *pdev; >> void __iomem *core_mem; /* MSM SDCC mapped address */ >> @@ -83,6 +88,7 @@ struct sdhci_msm_host { >> struct clk *bus_clk; /* SDHC bus voter clock */ >> struct mmc_host *mmc; >> bool use_14lpp_dll_reset; >> + struct sdhci_msm_pltfm_data *pdata; >> }; >> >> /* Platform specific tuning */ >> > > Just noticed this. Please don't add another structure, just put the > new members into struct sdhci_msm_host directly. > > We only need platform_data structures for drivers that also work > with old-style board files, which this one doesn't. Ok, I will move this into sdhci_msm_host directly. Thanks Ritesh > > Arnd > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Stephen/Adrian, Let me give a little background on this. We would need more suggestions and opinion on this. Sorry for the delay it took. Background - Below change adds clk-rates DT entry since sdhci-msm driver uses this clk-rates table to find the nearest *floor* value of clock (this clock request comes will come from core layer) supported by msm platform. Currently we don't have an API from clock driver which we can use it here to find these values(supported by msm platforms) and call for clk_set_rate. Hence the custom DT entry to have a table. Please let us know if there is an API to find the floor value of clock from clock driver. I tried clk_set_max_rate, but it is not giving expected output (at least for msm platforms). Comment- The request from Stephen was to check if we could utilize OppV2 framework since it provides an API - dev_pm_opp_find_freq_floor. Also to check if we could get it done from existing clock driver APIs. Please correct me I am missing anything. Concern and opinion? 1. What about if there are more clocks getting added to sdhci DT node? I see the Oppv2 framework taking device pointer as 1st argument. In cases where we have more than 1 clocks per device, how will Oppv2 handle this? 2. Here the concern is that shifting to Oppv2 framework only for use of this 1 API does not seems very useful. In case if there exist a clock driver API to do this, we may not have anything to be populated in DT. Opinion and suggestions please? Is it ok to continue to use clk-rates DT entry here for this case? Regards Ritesh On 9/12/2016 11:47 AM, Ritesh Harjani wrote: > Hi Stephen, > > > On 9/7/2016 9:44 PM, Stephen Boyd wrote: >> On 08/30, Ritesh Harjani wrote: >>> On 8/26/2016 3:57 AM, Stephen Boyd wrote: >>>> On 08/24, Ritesh Harjani wrote: >>>>> This adds support for sdhc-msm controllers to get supported >>>>> clk-rates from DT. sdhci-msm would need it's own set_clock >>>>> ops to be implemented. For this, supported clk-rates needs >>>>> to be populated in sdhci_msm_pltfm_data. >>>>> >>>>> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> >>>>> --- >>>> >>>> Please include the DT binding review list in binding updates. > Sure, will do it. > >>>> >>>>> .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + >>>>> drivers/mmc/host/sdhci-msm.c | 60 >>>>> ++++++++++++++++++++++ >>>>> 2 files changed, 61 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>> index 485483a..6a83b38 100644 >>>>> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt >>>>> @@ -17,6 +17,7 @@ Required properties: >>>>> "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) >>>>> (required) >>>>> "core" - SDC MMC clock (MCLK) (required) >>>>> "bus" - SDCC bus voter clock (optional) >>>>> +- clk-rates: Array of supported GCC clock frequencies for sdhc, >>>>> Units - Hz. >>>>> >>>> >>>> Why not use OPPv2 binding for this? We already have a way to >>>> express frequencies for devices with that binding, and we'll need >>>> to attach voltages to those frequencies at some point in the >>>> future if we want to handle DVFS on these devices. >>>> >>> OPPv2 may not work out in this case. This was also discussed at [1]. >>> These clk-rates are not as per voltage points(or any OPP) but as per >>> bus speed mode request from higher layer. >>> >> >> That post you link to had a response from Andy that echoed the >> same sentiment and then no reply. >> >> Are they a set of frequencies the device can operate at? Yes. Do >> they have associated voltages that aren't expressed in this >> patch? Yes. >> >> Perhaps I've missed something though and the index of the array >> of rates corresponds to some bus speed mode? That isn't clearly >> expressed in the binding. Do the frequencies come from some spec >> for those bus speed modes? Either way, I'd like to understand why >> we need to put frequency tables into DT (hint: the commit text >> should explain that). >> > As discussed offline, I will get back on this. > > Regards > Ritesh -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 485483a..6a83b38 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -17,6 +17,7 @@ Required properties: "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) "core" - SDC MMC clock (MCLK) (required) "bus" - SDCC bus voter clock (optional) +- clk-rates: Array of supported GCC clock frequencies for sdhc, Units - Hz. Example: diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c index 85ddaae..a46dd98 100644 --- a/drivers/mmc/host/sdhci-msm.c +++ b/drivers/mmc/host/sdhci-msm.c @@ -74,6 +74,11 @@ #define CMUX_SHIFT_PHASE_SHIFT 24 #define CMUX_SHIFT_PHASE_MASK (7 << CMUX_SHIFT_PHASE_SHIFT) +struct sdhci_msm_pltfm_data { + u32 *clk_table; + int clk_table_sz; +}; + struct sdhci_msm_host { struct platform_device *pdev; void __iomem *core_mem; /* MSM SDCC mapped address */ @@ -83,6 +88,7 @@ struct sdhci_msm_host { struct clk *bus_clk; /* SDHC bus voter clock */ struct mmc_host *mmc; bool use_14lpp_dll_reset; + struct sdhci_msm_pltfm_data *pdata; }; /* Platform specific tuning */ @@ -582,6 +588,56 @@ static const struct sdhci_pltfm_data sdhci_msm_pdata = { .ops = &sdhci_msm_ops, }; +static int sdhci_msm_dt_get_array(struct device *dev, const char *prop_name, + u32 **table, int *size) +{ + struct device_node *np = dev->of_node; + int count, ret; + u32 *arr; + + count = of_property_count_elems_of_size(np, prop_name, sizeof(u32)); + if (count < 0) { + dev_err(dev, "%s: Invalid dt property, err(%d)\n", + prop_name, count); + return count; + } + + arr = devm_kzalloc(dev, count * sizeof(*arr), GFP_KERNEL); + if (!arr) + return -ENOMEM; + + ret = of_property_read_u32_array(np, prop_name, arr, count); + if (ret) { + dev_err(dev, "%s Invalid dt array property, err(%d)\n", + prop_name, ret); + return ret; + } + *table = arr; + *size = count; + return 0; +} + +static struct sdhci_msm_pltfm_data *sdhci_msm_populate_pdata(struct device *dev, + struct sdhci_msm_host *msm_host) +{ + struct sdhci_msm_pltfm_data *pdata = NULL; + int table_sz = 0; + u32 *table = NULL; + + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) + return NULL; + + if (sdhci_msm_dt_get_array(dev, "clk-rates", &table, &table_sz)) { + dev_err(dev, "failed in DT parsing for supported clk-rates\n"); + return NULL; + } + pdata->clk_table = table; + pdata->clk_table_sz = table_sz; + + return pdata; +} + static int sdhci_msm_probe(struct platform_device *pdev) { struct sdhci_host *host; @@ -608,6 +664,10 @@ static int sdhci_msm_probe(struct platform_device *pdev) sdhci_get_of_property(pdev); + msm_host->pdata = sdhci_msm_populate_pdata(&pdev->dev, msm_host); + if (!msm_host->pdata) + goto pltfm_free; + /* Setup SDCC bus voter clock. */ msm_host->bus_clk = devm_clk_get(&pdev->dev, "bus"); if (!IS_ERR(msm_host->bus_clk)) {
This adds support for sdhc-msm controllers to get supported clk-rates from DT. sdhci-msm would need it's own set_clock ops to be implemented. For this, supported clk-rates needs to be populated in sdhci_msm_pltfm_data. Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org> --- .../devicetree/bindings/mmc/sdhci-msm.txt | 1 + drivers/mmc/host/sdhci-msm.c | 60 ++++++++++++++++++++++ 2 files changed, 61 insertions(+)