Re: [PATCH] mmc: sdhci: Use mmc core regulator infrastucture

[Tim Kryger]

On Fri, Apr 25, 2014 at 1:15 AM, Ulf Hansson  wrote:
> On 25 April 2014 00:36, Tim Kryger  wrote:
>> Switch the common SDHCI code over to use mmc_host's regulator pointers
>> and remove the ones in the sdhci_host structure.  Additionally, use the
>> common mmc_regulator_get_supply function to get the regulators and set
>> the ocr_avail mask.
>>
>> This change sets the ocr_avail directly based upon the voltage ranges
>> supported which ensures ocr_avail is set correctly while allowing the
>> use of regulators that can't provide exactly 1.8v, 3.0v, or 3.3v.
>>
>> Signed-off-by: Tim Kryger 
>
> This looks good to me!
>
> I plan to get Russell's sdhci patchset merged, prior to this patch. So
> likely we need to rebase this patch on top of that soon.
>
> Kind regards
> Ulf Hansson

Hi Ulf,

Can you clarify if this is the series you intend to merge and provide
a rough estimate on when it might happen?

http://www.spinics.net/lists/arm-kernel/msg324984.html

Thanks,
Tim Kryger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mmc: core: Improve support for deferred regulators

[Tim Kryger]

On Tue, May 6, 2014 at 3:57 PM, Tim Kryger  wrote:
> Callers of mmc_regulator_get_supply could benefit from knowing if either
> of the regulators are present but not yet available.  Since callers do
> not currently examine the return value, modify this function to return
> zero or -EPROBE_DEFER if either regulator get returns the same.
>
> Furthermore, since callers check vmmc/vqmmc using IS_ERR and can deal
> with absent regulators, switch to devm_regulator_get_optional. This has
> the added benefit of allowing this function to behave correctly even in
> the !CONFIG_REGULATOR case such that the stub can be removed.
>
> Signed-off-by: Tim Kryger 
> ---

Changes since v1:
  - Removed stub function for !CONFIG_REGULATOR case

>  drivers/mmc/core/core.c  |   31 +++
>  include/linux/mmc/host.h |8 ++--
>  2 files changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index acbc3f2..2d9f6c5 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1310,31 +1310,38 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
>  }
>  EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
>
> +#endif /* CONFIG_REGULATOR */
> +
>  int mmc_regulator_get_supply(struct mmc_host *mmc)
>  {
> struct device *dev = mmc_dev(mmc);
> -   struct regulator *supply;
> int ret;
>
> -   supply = devm_regulator_get(dev, "vmmc");
> -   mmc->supply.vmmc = supply;
> +   mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc");
> mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc");
>
> -   if (IS_ERR(supply))
> -   return PTR_ERR(supply);
> +   if (IS_ERR(mmc->supply.vmmc)) {
> +   if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER)
> +   return -EPROBE_DEFER;
> +   dev_info(dev, "No vmmc regulator found\n");
> +   } else {
> +   ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
> +   if (ret > 0)
> +   mmc->ocr_avail = ret;
> +   else
> +   dev_warn(dev, "Failed getting OCR mask: %d\n", ret);
> +   }
>
> -   ret = mmc_regulator_get_ocrmask(supply);
> -   if (ret > 0)
> -   mmc->ocr_avail = ret;
> -   else
> -   dev_warn(mmc_dev(mmc), "Failed getting OCR mask: %d\n", ret);
> +   if (IS_ERR(mmc->supply.vqmmc)) {
> +   if (PTR_ERR(mmc->supply.vqmmc) == -EPROBE_DEFER)
> +   return -EPROBE_DEFER;
> +   dev_info(dev, "No vqmmc regulator found\n");
> +   }
>
> return 0;
>  }
>  EXPORT_SYMBOL_GPL(mmc_regulator_get_supply);
>
> -#endif /* CONFIG_REGULATOR */
> -
>  /*
>   * Mask off any voltages we don't support and select
>   * the lowest voltage
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index cb61ea4..cfa2ecb 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -396,7 +396,6 @@ int mmc_regulator_get_ocrmask(struct regulator *supply);
>  int mmc_regulator_set_ocr(struct mmc_host *mmc,
> struct regulator *supply,
> unsigned short vdd_bit);
> -int mmc_regulator_get_supply(struct mmc_host *mmc);
>  #else
>  static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
>  {
> @@ -409,13 +408,10 @@ static inline int mmc_regulator_set_ocr(struct mmc_host 
> *mmc,
>  {
> return 0;
>  }
> -
> -static inline int mmc_regulator_get_supply(struct mmc_host *mmc)
> -{
> -   return 0;
> -}
>  #endif
>
> +int mmc_regulator_get_supply(struct mmc_host *mmc);
> +
>  int mmc_pm_notify(struct notifier_block *notify_block, unsigned long, void 
> *);
>
>  static inline int mmc_card_is_removable(struct mmc_host *host)
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: core: Improve support for deferred regulators

[Tim Kryger]

Callers of mmc_regulator_get_supply could benefit from knowing if either
of the regulators are present but not yet available.  Since callers do
not currently examine the return value, modify this function to return
zero or -EPROBE_DEFER if either regulator get returns the same.

Furthermore, since callers check vmmc/vqmmc using IS_ERR and can deal
with absent regulators, switch to devm_regulator_get_optional. This has
the added benefit of allowing this function to behave correctly even in
the !CONFIG_REGULATOR case such that the stub can be removed.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/core/core.c  |   31 +++
 include/linux/mmc/host.h |8 ++--
 2 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..2d9f6c5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1310,31 +1310,38 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
 }
 EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
 
+#endif /* CONFIG_REGULATOR */
+
 int mmc_regulator_get_supply(struct mmc_host *mmc)
 {
struct device *dev = mmc_dev(mmc);
-   struct regulator *supply;
int ret;
 
-   supply = devm_regulator_get(dev, "vmmc");
-   mmc->supply.vmmc = supply;
+   mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc");
mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc");
 
-   if (IS_ERR(supply))
-   return PTR_ERR(supply);
+   if (IS_ERR(mmc->supply.vmmc)) {
+   if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, "No vmmc regulator found\n");
+   } else {
+   ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
+   if (ret > 0)
+   mmc->ocr_avail = ret;
+   else
+   dev_warn(dev, "Failed getting OCR mask: %d\n", ret);
+   }
 
-   ret = mmc_regulator_get_ocrmask(supply);
-   if (ret > 0)
-   mmc->ocr_avail = ret;
-   else
-   dev_warn(mmc_dev(mmc), "Failed getting OCR mask: %d\n", ret);
+   if (IS_ERR(mmc->supply.vqmmc)) {
+   if (PTR_ERR(mmc->supply.vqmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, "No vqmmc regulator found\n");
+   }
 
return 0;
 }
 EXPORT_SYMBOL_GPL(mmc_regulator_get_supply);
 
-#endif /* CONFIG_REGULATOR */
-
 /*
  * Mask off any voltages we don't support and select
  * the lowest voltage
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index cb61ea4..cfa2ecb 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -396,7 +396,6 @@ int mmc_regulator_get_ocrmask(struct regulator *supply);
 int mmc_regulator_set_ocr(struct mmc_host *mmc,
struct regulator *supply,
unsigned short vdd_bit);
-int mmc_regulator_get_supply(struct mmc_host *mmc);
 #else
 static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
 {
@@ -409,13 +408,10 @@ static inline int mmc_regulator_set_ocr(struct mmc_host 
*mmc,
 {
return 0;
 }
-
-static inline int mmc_regulator_get_supply(struct mmc_host *mmc)
-{
-   return 0;
-}
 #endif
 
+int mmc_regulator_get_supply(struct mmc_host *mmc);
+
 int mmc_pm_notify(struct notifier_block *notify_block, unsigned long, void *);
 
 static inline int mmc_card_is_removable(struct mmc_host *host)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: core: Improve support for deferred regulators

[Tim Kryger]

Callers of mmc_regulator_get_supply could benefit from knowing if either
of the regulators are present but not yet available.  Since callers do
not currently examine the return value, modify this function to return
zero or -EPROBE_DEFER if either regulator get returns the same.

Furthermore, since callers check vmmc/vqmmc using IS_ERR and can deal
with absent regulators, switch to devm_regulator_get_optional. This has
the added benefit of allowing this function to behave correctly even in
the !CONFIG_REGULATOR case such that the stub can be removed.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/mmc/core/core.c  |   31 +++
 include/linux/mmc/host.h |8 ++--
 2 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..2d9f6c5 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1310,31 +1310,38 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
 }
 EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
 
+#endif /* CONFIG_REGULATOR */
+
 int mmc_regulator_get_supply(struct mmc_host *mmc)
 {
struct device *dev = mmc_dev(mmc);
-   struct regulator *supply;
int ret;
 
-   supply = devm_regulator_get(dev, vmmc);
-   mmc-supply.vmmc = supply;
+   mmc-supply.vmmc = devm_regulator_get_optional(dev, vmmc);
mmc-supply.vqmmc = devm_regulator_get_optional(dev, vqmmc);
 
-   if (IS_ERR(supply))
-   return PTR_ERR(supply);
+   if (IS_ERR(mmc-supply.vmmc)) {
+   if (PTR_ERR(mmc-supply.vmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, No vmmc regulator found\n);
+   } else {
+   ret = mmc_regulator_get_ocrmask(mmc-supply.vmmc);
+   if (ret  0)
+   mmc-ocr_avail = ret;
+   else
+   dev_warn(dev, Failed getting OCR mask: %d\n, ret);
+   }
 
-   ret = mmc_regulator_get_ocrmask(supply);
-   if (ret  0)
-   mmc-ocr_avail = ret;
-   else
-   dev_warn(mmc_dev(mmc), Failed getting OCR mask: %d\n, ret);
+   if (IS_ERR(mmc-supply.vqmmc)) {
+   if (PTR_ERR(mmc-supply.vqmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, No vqmmc regulator found\n);
+   }
 
return 0;
 }
 EXPORT_SYMBOL_GPL(mmc_regulator_get_supply);
 
-#endif /* CONFIG_REGULATOR */
-
 /*
  * Mask off any voltages we don't support and select
  * the lowest voltage
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index cb61ea4..cfa2ecb 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -396,7 +396,6 @@ int mmc_regulator_get_ocrmask(struct regulator *supply);
 int mmc_regulator_set_ocr(struct mmc_host *mmc,
struct regulator *supply,
unsigned short vdd_bit);
-int mmc_regulator_get_supply(struct mmc_host *mmc);
 #else
 static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
 {
@@ -409,13 +408,10 @@ static inline int mmc_regulator_set_ocr(struct mmc_host 
*mmc,
 {
return 0;
 }
-
-static inline int mmc_regulator_get_supply(struct mmc_host *mmc)
-{
-   return 0;
-}
 #endif
 
+int mmc_regulator_get_supply(struct mmc_host *mmc);
+
 int mmc_pm_notify(struct notifier_block *notify_block, unsigned long, void *);
 
 static inline int mmc_card_is_removable(struct mmc_host *host)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mmc: core: Improve support for deferred regulators

[Tim Kryger]

On Tue, May 6, 2014 at 3:57 PM, Tim Kryger tim.kry...@linaro.org wrote:
 Callers of mmc_regulator_get_supply could benefit from knowing if either
 of the regulators are present but not yet available.  Since callers do
 not currently examine the return value, modify this function to return
 zero or -EPROBE_DEFER if either regulator get returns the same.

 Furthermore, since callers check vmmc/vqmmc using IS_ERR and can deal
 with absent regulators, switch to devm_regulator_get_optional. This has
 the added benefit of allowing this function to behave correctly even in
 the !CONFIG_REGULATOR case such that the stub can be removed.

 Signed-off-by: Tim Kryger tim.kry...@linaro.org
 ---

Changes since v1:
  - Removed stub function for !CONFIG_REGULATOR case

  drivers/mmc/core/core.c  |   31 +++
  include/linux/mmc/host.h |8 ++--
  2 files changed, 21 insertions(+), 18 deletions(-)

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index acbc3f2..2d9f6c5 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -1310,31 +1310,38 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
  }
  EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);

 +#endif /* CONFIG_REGULATOR */
 +
  int mmc_regulator_get_supply(struct mmc_host *mmc)
  {
 struct device *dev = mmc_dev(mmc);
 -   struct regulator *supply;
 int ret;

 -   supply = devm_regulator_get(dev, vmmc);
 -   mmc-supply.vmmc = supply;
 +   mmc-supply.vmmc = devm_regulator_get_optional(dev, vmmc);
 mmc-supply.vqmmc = devm_regulator_get_optional(dev, vqmmc);

 -   if (IS_ERR(supply))
 -   return PTR_ERR(supply);
 +   if (IS_ERR(mmc-supply.vmmc)) {
 +   if (PTR_ERR(mmc-supply.vmmc) == -EPROBE_DEFER)
 +   return -EPROBE_DEFER;
 +   dev_info(dev, No vmmc regulator found\n);
 +   } else {
 +   ret = mmc_regulator_get_ocrmask(mmc-supply.vmmc);
 +   if (ret  0)
 +   mmc-ocr_avail = ret;
 +   else
 +   dev_warn(dev, Failed getting OCR mask: %d\n, ret);
 +   }

 -   ret = mmc_regulator_get_ocrmask(supply);
 -   if (ret  0)
 -   mmc-ocr_avail = ret;
 -   else
 -   dev_warn(mmc_dev(mmc), Failed getting OCR mask: %d\n, ret);
 +   if (IS_ERR(mmc-supply.vqmmc)) {
 +   if (PTR_ERR(mmc-supply.vqmmc) == -EPROBE_DEFER)
 +   return -EPROBE_DEFER;
 +   dev_info(dev, No vqmmc regulator found\n);
 +   }

 return 0;
  }
  EXPORT_SYMBOL_GPL(mmc_regulator_get_supply);

 -#endif /* CONFIG_REGULATOR */
 -
  /*
   * Mask off any voltages we don't support and select
   * the lowest voltage
 diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
 index cb61ea4..cfa2ecb 100644
 --- a/include/linux/mmc/host.h
 +++ b/include/linux/mmc/host.h
 @@ -396,7 +396,6 @@ int mmc_regulator_get_ocrmask(struct regulator *supply);
  int mmc_regulator_set_ocr(struct mmc_host *mmc,
 struct regulator *supply,
 unsigned short vdd_bit);
 -int mmc_regulator_get_supply(struct mmc_host *mmc);
  #else
  static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
  {
 @@ -409,13 +408,10 @@ static inline int mmc_regulator_set_ocr(struct mmc_host 
 *mmc,
  {
 return 0;
  }
 -
 -static inline int mmc_regulator_get_supply(struct mmc_host *mmc)
 -{
 -   return 0;
 -}
  #endif

 +int mmc_regulator_get_supply(struct mmc_host *mmc);
 +
  int mmc_pm_notify(struct notifier_block *notify_block, unsigned long, void 
 *);

  static inline int mmc_card_is_removable(struct mmc_host *host)
 --
 1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: Use mmc core regulator infrastucture

[Tim Kryger]

On Fri, Apr 25, 2014 at 1:15 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 25 April 2014 00:36, Tim Kryger tim.kry...@linaro.org wrote:
 Switch the common SDHCI code over to use mmc_host's regulator pointers
 and remove the ones in the sdhci_host structure.  Additionally, use the
 common mmc_regulator_get_supply function to get the regulators and set
 the ocr_avail mask.

 This change sets the ocr_avail directly based upon the voltage ranges
 supported which ensures ocr_avail is set correctly while allowing the
 use of regulators that can't provide exactly 1.8v, 3.0v, or 3.3v.

 Signed-off-by: Tim Kryger tim.kry...@linaro.org

 This looks good to me!

 I plan to get Russell's sdhci patchset merged, prior to this patch. So
 likely we need to rebase this patch on top of that soon.

 Kind regards
 Ulf Hansson

Hi Ulf,

Can you clarify if this is the series you intend to merge and provide
a rough estimate on when it might happen?

http://www.spinics.net/lists/arm-kernel/msg324984.html

Thanks,
Tim Kryger
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] mmc: core: Improve support for deferred regulators

[Tim Kryger]

On Fri, Apr 25, 2014 at 2:33 PM, Andrew Bresticker
 wrote:
>>
>> -   if (IS_ERR(supply))
>> -   return PTR_ERR(supply);
>> +   if (IS_ERR(mmc->supply.vmmc)) {
>> +   if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER)
>> +   return -EPROBE_DEFER;
>> +   dev_info(dev, "No vmmc regulator found\n");
>> +   } else {
>> +   ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
>> +   if (ret > 0)
>> +   mmc->ocr_avail = ret;
>> +   else
>> +   dev_warn(dev, "Failed getting OCR mask: %d\n", ret);
>> +   }
>
> I think we also need to handle the case where supply is NULL, i.e.
> !CONFIG_REGULATOR.  The SDHCI driver, for example, calls
> regulator_is_supported_voltage() which will always return false on
> NULL regulators.  Perhaps we should set the supplies to
> ERR_PTR(-ENODEV) in that case?

As of v3.15-rc3, this function would do the right thing because
df7926f modified the regulator get optional stubs to return -ENODEV in
the !CONFIG_REGULATOR case.  However, this implementation of
mmc_regulator_get_supply doesn't actually get built for that case.  A
stub implementation is used instead.  Presently that stub
mmc_regulator_get_supply does nothing other than return zero but
perhaps it should initialize the supplies as you suggest.
Alternatively, the stub could be eliminated such that this
implementation is used in all cases.  Do you have a preference?

-Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND] mmc: core: Improve support for deferred regulators

[Tim Kryger]

On Fri, Apr 25, 2014 at 2:33 PM, Andrew Bresticker
abres...@chromium.org wrote:

 -   if (IS_ERR(supply))
 -   return PTR_ERR(supply);
 +   if (IS_ERR(mmc-supply.vmmc)) {
 +   if (PTR_ERR(mmc-supply.vmmc) == -EPROBE_DEFER)
 +   return -EPROBE_DEFER;
 +   dev_info(dev, No vmmc regulator found\n);
 +   } else {
 +   ret = mmc_regulator_get_ocrmask(mmc-supply.vmmc);
 +   if (ret  0)
 +   mmc-ocr_avail = ret;
 +   else
 +   dev_warn(dev, Failed getting OCR mask: %d\n, ret);
 +   }

 I think we also need to handle the case where supply is NULL, i.e.
 !CONFIG_REGULATOR.  The SDHCI driver, for example, calls
 regulator_is_supported_voltage() which will always return false on
 NULL regulators.  Perhaps we should set the supplies to
 ERR_PTR(-ENODEV) in that case?

As of v3.15-rc3, this function would do the right thing because
df7926f modified the regulator get optional stubs to return -ENODEV in
the !CONFIG_REGULATOR case.  However, this implementation of
mmc_regulator_get_supply doesn't actually get built for that case.  A
stub implementation is used instead.  Presently that stub
mmc_regulator_get_supply does nothing other than return zero but
perhaps it should initialize the supplies as you suggest.
Alternatively, the stub could be eliminated such that this
implementation is used in all cases.  Do you have a preference?

-Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 RESEND 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

On Mon, Apr 28, 2014 at 4:07 AM, Thierry Reding
 wrote:
> On Fri, Apr 25, 2014 at 11:31:10AM -0700, Tim Kryger wrote:
>> This series introduces the driver for the Kona PWM controller found in
>> Broadcom mobile SoCs like bcm281xx and updates the device tree and the
>> defconfig to enable use of this hardware on the bcm28155 AP board.
>>

>> Tim Kryger (5):
>>   Documentation: dt: Add Kona PWM binding
>>   pwm: kona: Introduce Kona PWM controller support
>>   ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
>>   ARM: dts: Enable the PWM for bcm28155 AP board
>>   ARM: bcm_defconfig: Enable PWM and Backlight

> I've applied patches 1 and 2 (with two tiny whitespace cleanups) to my
> for-next branch.

Sounds good.  Thank you.

Matt and Christian, are you okay taking patches 3-5 through your tree?

-Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 RESEND 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

On Mon, Apr 28, 2014 at 4:07 AM, Thierry Reding
thierry.red...@gmail.com wrote:
 On Fri, Apr 25, 2014 at 11:31:10AM -0700, Tim Kryger wrote:
 This series introduces the driver for the Kona PWM controller found in
 Broadcom mobile SoCs like bcm281xx and updates the device tree and the
 defconfig to enable use of this hardware on the bcm28155 AP board.


 Tim Kryger (5):
   Documentation: dt: Add Kona PWM binding
   pwm: kona: Introduce Kona PWM controller support
   ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
   ARM: dts: Enable the PWM for bcm28155 AP board
   ARM: bcm_defconfig: Enable PWM and Backlight

 I've applied patches 1 and 2 (with two tiny whitespace cleanups) to my
 for-next branch.

Sounds good.  Thank you.

Matt and Christian, are you okay taking patches 3-5 through your tree?

-Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] mmc: core: Improve support for deferred regulators

[Tim Kryger]

It is important that callers of mmc_regulator_get_supply know if either
vmmc or vqmmc are present but not yet available.  To support this need,
modify this function to return zero except when either of the regulator
get operations fail with -EPROBE_DEFER.  Current callers don't check the
return value and may continue to use IS_ERR on the vmmc/vqmmc values to
determine if those regulators are available.  Furthermore, since all of
these callers are capable of dealing with absent regulators, switch over
to use the non-optional variety of the regulator get call.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/core/core.c |   27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..095eef0 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1313,21 +1313,28 @@ EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
 int mmc_regulator_get_supply(struct mmc_host *mmc)
 {
struct device *dev = mmc_dev(mmc);
-   struct regulator *supply;
int ret;
 
-   supply = devm_regulator_get(dev, "vmmc");
-   mmc->supply.vmmc = supply;
+   mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc");
mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc");
 
-   if (IS_ERR(supply))
-   return PTR_ERR(supply);
+   if (IS_ERR(mmc->supply.vmmc)) {
+   if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, "No vmmc regulator found\n");
+   } else {
+   ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
+   if (ret > 0)
+   mmc->ocr_avail = ret;
+   else
+   dev_warn(dev, "Failed getting OCR mask: %d\n", ret);
+   }
 
-   ret = mmc_regulator_get_ocrmask(supply);
-   if (ret > 0)
-   mmc->ocr_avail = ret;
-   else
-   dev_warn(mmc_dev(mmc), "Failed getting OCR mask: %d\n", ret);
+   if (IS_ERR(mmc->supply.vqmmc)) {
+   if (PTR_ERR(mmc->supply.vqmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, "No vqmmc regulator found\n");
+   }
 
return 0;
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 3/5] ARM: dts: Declare the PWM for bcm11351 (bcm281xx)

[Tim Kryger]

Add the device tree node for the PWM on bcm11351 SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm11351.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 64d069b..6b05ae6 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -193,6 +193,14 @@
status = "disabled";
};
 
+   pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xcc>;
+   clocks = <_ccu BCM281XX_SLAVE_CCU_PWM>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
clocks {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 4/5] ARM: dts: Enable the PWM for bcm28155 AP board

[Tim Kryger]

Mark the PWM as enabled on the bcm28155 AP board.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm28155-ap.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
b/arch/arm/boot/dts/bcm28155-ap.dts
index af3da55..9ce91dd 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -69,6 +69,10 @@
status = "okay";
};
 
+   pwm: pwm@3e01a000 {
+   status = "okay";
+   };
+
usbotg: usb@3f12 {
vusb_d-supply = <_reg>;
vusb_a-supply = <_reg>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

Add the binding description for the Kona PWM controller found on Broadcom's
mobile SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000..8eae9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+
+This controller has 6 channels.
+
+Required Properties :
+- compatible: should contain "brcm,kona-pwm"
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+
+Example:
+
+pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xc4>;
+   clocks = <_clk>;
+   #pwm-cells = <3>;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 5/5] ARM: bcm_defconfig: Enable PWM and Backlight

[Tim Kryger]

Enable PWM drivers and the PWM-based backlight driver.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/configs/bcm_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 0100464..f09f7c6 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -91,6 +91,7 @@ CONFIG_FB=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
@@ -104,6 +105,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_PWM=y
+CONFIG_PWM_BCM_KONA=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

Add support for the six-channel Kona PWM controller found on Broadcom
mobile SoCs like bcm281xx.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 drivers/pwm/Kconfig|9 ++
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 5b34ff2..4ad7b89 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,15 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.
 
+config PWM_BCM_KONA
+   tristate "Kona PWM support"
+   depends on ARCH_BCM_MOBILE
+   help
+ Generic PWM framework driver for Broadcom Kona PWM block.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm-kona.
+
 config PWM_BFIN
tristate "Blackfin PWM support"
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index e57d2c3..5c86a19 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
new file mode 100644
index 000..ee8a59d
--- /dev/null
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The Kona PWM has some unusual characteristics.  Here are the main points.
+ *
+ * 1) There is no disable bit and the hardware docs advise programming a zero
+ *duty to achieve output equivalent to that of a normal disable operation.
+ *
+ * 2) Changes to prescale, duty, period, and polarity do not take effect until
+ *a subsequent rising edge of the trigger bit.
+ *
+ * 3) If the smooth bit and trigger bit are both low, the output is a constant
+ *high signal.  Otherwise, the earlier waveform continues to be output.
+ *
+ * 4) If the smooth bit is set on the rising edge of the trigger bit, output
+ *will transition to the new settings on a period boundary (which could be
+ *seconds away).  If the smooth bit is clear, new settings will be applied
+ *as soon as possible (the hardware always has a 400ns delay).
+ *
+ * 5) When the external clock that feeds the PWM is disabled, output is pegged
+ *high or low depending on its state at that exact instant.
+ */
+
+#define PWM_CONTROL_OFFSET (0x)
+#define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan))
+#define PWM_CONTROL_TYPE_SHIFT(chan)   (16 + (chan))
+#define PWM_CONTROL_POLARITY_SHIFT(chan)   (8 + (chan))
+#define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan)
+
+#define PRESCALE_OFFSET(0x0004)
+#define PRESCALE_SHIFT(chan)   ((chan) << 2)
+#define PRESCALE_MASK(chan)(0x7 << PRESCALE_SHIFT(chan))
+#define PRESCALE_MIN   (0x)
+#define PRESCALE_MAX   (0x0007)
+
+#define PERIOD_COUNT_OFFSET(chan)  (0x0008 + ((chan) << 3))
+#define PERIOD_COUNT_MIN   (0x0002)
+#define PERIOD_COUNT_MAX   (0x00ff)
+
+#define DUTY_CYCLE_HIGH_OFFSET(chan)   (0x000c + ((chan) << 3))
+#define DUTY_CYCLE_HIGH_MIN(0x)
+#define DUTY_CYCLE_HIGH_MAX(0x00ff)
+
+struct kona_pwmc {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip)
+{
+   return container_of(_chip, struct kona_pwmc, chip);
+}
+
+static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
+{
+   unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
+
+   /* Cl

[PATCH v6 RESEND 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

This series introduces the driver for the Kona PWM controller found in
Broadcom mobile SoCs like bcm281xx and updates the device tree and the
defconfig to enable use of this hardware on the bcm28155 AP board.

Changes since v5:
  - Rebased on v3.15-rc1

Changes since v4:
  - Added in real polarity support
  - Labeled trigger bits as such rather than use the name from hw docs
  - Listed unsual hardware characteristics at the top of the file
  - Removed default from Kconfig and update defconfig accordingly
  - Always use unsigned int for temporary register values

Changes since v3:
  - Removed polarity support for now
  - Cleaned up whitespace issues, shortened some variable names
  - Use container_of instead of dev_get_drvdata to get private data
  - Removed workaround for PWM framework bug
  - Reworded some binding documentation

Changes since v2:
  - SoC DTS file updated to use real clock's phandle + specifier
  - Toggle smooth mode off during apply so new settings take immediately

Changes since v1:
  - Fixed up macros to be clearer and more complete
  - Corrected spelling and punctuation mistakes
  - Added support for polarity
  - Made peripheral clock use more efficient
  - Made prescale and duty computation clearer
  - Moved Makefile addition to keep alphabetical
  - Split complex lines into multiple steps


Tim Kryger (5):
  Documentation: dt: Add Kona PWM binding
  pwm: kona: Introduce Kona PWM controller support
  ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
  ARM: dts: Enable the PWM for bcm28155 AP board
  ARM: bcm_defconfig: Enable PWM and Backlight

 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 ++
 arch/arm/boot/dts/bcm11351.dtsi|8 +
 arch/arm/boot/dts/bcm28155-ap.dts  |4 +
 arch/arm/configs/bcm_defconfig |3 +
 drivers/pwm/Kconfig|9 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 7 files changed, 365 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

Add support for the six-channel Kona PWM controller found on Broadcom
mobile SoCs like bcm281xx.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 drivers/pwm/Kconfig|9 ++
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 5b34ff2..4ad7b89 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,15 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.
 
+config PWM_BCM_KONA
+   tristate Kona PWM support
+   depends on ARCH_BCM_MOBILE
+   help
+ Generic PWM framework driver for Broadcom Kona PWM block.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm-kona.
+
 config PWM_BFIN
tristate Blackfin PWM support
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index e57d2c3..5c86a19 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
new file mode 100644
index 000..ee8a59d
--- /dev/null
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/math64.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pwm.h
+#include linux/slab.h
+#include linux/types.h
+
+/*
+ * The Kona PWM has some unusual characteristics.  Here are the main points.
+ *
+ * 1) There is no disable bit and the hardware docs advise programming a zero
+ *duty to achieve output equivalent to that of a normal disable operation.
+ *
+ * 2) Changes to prescale, duty, period, and polarity do not take effect until
+ *a subsequent rising edge of the trigger bit.
+ *
+ * 3) If the smooth bit and trigger bit are both low, the output is a constant
+ *high signal.  Otherwise, the earlier waveform continues to be output.
+ *
+ * 4) If the smooth bit is set on the rising edge of the trigger bit, output
+ *will transition to the new settings on a period boundary (which could be
+ *seconds away).  If the smooth bit is clear, new settings will be applied
+ *as soon as possible (the hardware always has a 400ns delay).
+ *
+ * 5) When the external clock that feeds the PWM is disabled, output is pegged
+ *high or low depending on its state at that exact instant.
+ */
+
+#define PWM_CONTROL_OFFSET (0x)
+#define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan))
+#define PWM_CONTROL_TYPE_SHIFT(chan)   (16 + (chan))
+#define PWM_CONTROL_POLARITY_SHIFT(chan)   (8 + (chan))
+#define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan)
+
+#define PRESCALE_OFFSET(0x0004)
+#define PRESCALE_SHIFT(chan)   ((chan)  2)
+#define PRESCALE_MASK(chan)(0x7  PRESCALE_SHIFT(chan))
+#define PRESCALE_MIN   (0x)
+#define PRESCALE_MAX   (0x0007)
+
+#define PERIOD_COUNT_OFFSET(chan)  (0x0008 + ((chan)  3))
+#define PERIOD_COUNT_MIN   (0x0002)
+#define PERIOD_COUNT_MAX   (0x00ff)
+
+#define DUTY_CYCLE_HIGH_OFFSET(chan)   (0x000c + ((chan)  3))
+#define DUTY_CYCLE_HIGH_MIN(0x)
+#define DUTY_CYCLE_HIGH_MAX(0x00ff)
+
+struct kona_pwmc {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip)
+{
+   return container_of(_chip, struct kona_pwmc, chip);
+}
+
+static void

[PATCH v6 RESEND 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

This series introduces the driver for the Kona PWM controller found in
Broadcom mobile SoCs like bcm281xx and updates the device tree and the
defconfig to enable use of this hardware on the bcm28155 AP board.

Changes since v5:
  - Rebased on v3.15-rc1

Changes since v4:
  - Added in real polarity support
  - Labeled trigger bits as such rather than use the name from hw docs
  - Listed unsual hardware characteristics at the top of the file
  - Removed default from Kconfig and update defconfig accordingly
  - Always use unsigned int for temporary register values

Changes since v3:
  - Removed polarity support for now
  - Cleaned up whitespace issues, shortened some variable names
  - Use container_of instead of dev_get_drvdata to get private data
  - Removed workaround for PWM framework bug
  - Reworded some binding documentation

Changes since v2:
  - SoC DTS file updated to use real clock's phandle + specifier
  - Toggle smooth mode off during apply so new settings take immediately

Changes since v1:
  - Fixed up macros to be clearer and more complete
  - Corrected spelling and punctuation mistakes
  - Added support for polarity
  - Made peripheral clock use more efficient
  - Made prescale and duty computation clearer
  - Moved Makefile addition to keep alphabetical
  - Split complex lines into multiple steps


Tim Kryger (5):
  Documentation: dt: Add Kona PWM binding
  pwm: kona: Introduce Kona PWM controller support
  ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
  ARM: dts: Enable the PWM for bcm28155 AP board
  ARM: bcm_defconfig: Enable PWM and Backlight

 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 ++
 arch/arm/boot/dts/bcm11351.dtsi|8 +
 arch/arm/boot/dts/bcm28155-ap.dts  |4 +
 arch/arm/configs/bcm_defconfig |3 +
 drivers/pwm/Kconfig|9 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 7 files changed, 365 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 5/5] ARM: bcm_defconfig: Enable PWM and Backlight

[Tim Kryger]

Enable PWM drivers and the PWM-based backlight driver.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/configs/bcm_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 0100464..f09f7c6 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -91,6 +91,7 @@ CONFIG_FB=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
@@ -104,6 +105,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_PWM=y
+CONFIG_PWM_BCM_KONA=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

Add the binding description for the Kona PWM controller found on Broadcom's
mobile SoCs.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000..8eae9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+
+This controller has 6 channels.
+
+Required Properties :
+- compatible: should contain brcm,kona-pwm
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+
+Example:
+
+pwm: pwm@3e01a000 {
+   compatible = brcm,bcm11351-pwm, brcm,kona-pwm;
+   reg = 0x3e01a000 0xc4;
+   clocks = pwm_clk;
+   #pwm-cells = 3;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 4/5] ARM: dts: Enable the PWM for bcm28155 AP board

[Tim Kryger]

Mark the PWM as enabled on the bcm28155 AP board.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/boot/dts/bcm28155-ap.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
b/arch/arm/boot/dts/bcm28155-ap.dts
index af3da55..9ce91dd 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -69,6 +69,10 @@
status = okay;
};
 
+   pwm: pwm@3e01a000 {
+   status = okay;
+   };
+
usbotg: usb@3f12 {
vusb_d-supply = usbldo_reg;
vusb_a-supply = iosr1_reg;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 RESEND 3/5] ARM: dts: Declare the PWM for bcm11351 (bcm281xx)

[Tim Kryger]

Add the device tree node for the PWM on bcm11351 SoCs.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/boot/dts/bcm11351.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 64d069b..6b05ae6 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -193,6 +193,14 @@
status = disabled;
};
 
+   pwm: pwm@3e01a000 {
+   compatible = brcm,bcm11351-pwm, brcm,kona-pwm;
+   reg = 0x3e01a000 0xcc;
+   clocks = slave_ccu BCM281XX_SLAVE_CCU_PWM;
+   #pwm-cells = 3;
+   status = disabled;
+   };
+
clocks {
#address-cells = 1;
#size-cells = 1;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RESEND] mmc: core: Improve support for deferred regulators

[Tim Kryger]

It is important that callers of mmc_regulator_get_supply know if either
vmmc or vqmmc are present but not yet available.  To support this need,
modify this function to return zero except when either of the regulator
get operations fail with -EPROBE_DEFER.  Current callers don't check the
return value and may continue to use IS_ERR on the vmmc/vqmmc values to
determine if those regulators are available.  Furthermore, since all of
these callers are capable of dealing with absent regulators, switch over
to use the non-optional variety of the regulator get call.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/mmc/core/core.c |   27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..095eef0 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1313,21 +1313,28 @@ EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
 int mmc_regulator_get_supply(struct mmc_host *mmc)
 {
struct device *dev = mmc_dev(mmc);
-   struct regulator *supply;
int ret;
 
-   supply = devm_regulator_get(dev, vmmc);
-   mmc-supply.vmmc = supply;
+   mmc-supply.vmmc = devm_regulator_get_optional(dev, vmmc);
mmc-supply.vqmmc = devm_regulator_get_optional(dev, vqmmc);
 
-   if (IS_ERR(supply))
-   return PTR_ERR(supply);
+   if (IS_ERR(mmc-supply.vmmc)) {
+   if (PTR_ERR(mmc-supply.vmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, No vmmc regulator found\n);
+   } else {
+   ret = mmc_regulator_get_ocrmask(mmc-supply.vmmc);
+   if (ret  0)
+   mmc-ocr_avail = ret;
+   else
+   dev_warn(dev, Failed getting OCR mask: %d\n, ret);
+   }
 
-   ret = mmc_regulator_get_ocrmask(supply);
-   if (ret  0)
-   mmc-ocr_avail = ret;
-   else
-   dev_warn(mmc_dev(mmc), Failed getting OCR mask: %d\n, ret);
+   if (IS_ERR(mmc-supply.vqmmc)) {
+   if (PTR_ERR(mmc-supply.vqmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, No vqmmc regulator found\n);
+   }
 
return 0;
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: sdhci: Use mmc core regulator infrastucture

[Tim Kryger]

Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure.  Additionally, use the
common mmc_regulator_get_supply function to get the regulators and set
the ocr_avail mask.

This change sets the ocr_avail directly based upon the voltage ranges
supported which ensures ocr_avail is set correctly while allowing the
use of regulators that can't provide exactly 1.8v, 3.0v, or 3.3v.

Signed-off-by: Tim Kryger 
---

This patch is the same as the following series only squashed together.
https://lkml.org/lkml/2014/4/17/653

 drivers/mmc/host/sdhci.c  |   96 +
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 35 insertions(+), 64 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..2d081d8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1429,6 +1429,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
 static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host->mmc;
unsigned long flags;
int vdd_bit = -1;
u8 ctrl;
@@ -1437,8 +1438,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host->flags & SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(>lock, flags);
-   if (host->vmmc && ios->power_mode == MMC_POWER_OFF)
-   mmc_regulator_set_ocr(host->mmc, host->vmmc, 0);
+   if (!IS_ERR(mmc->supply.vmmc) &&
+   ios->power_mode == MMC_POWER_OFF)
+   mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, 0);
return;
}
 
@@ -1463,9 +1465,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios->vdd);
 
-   if (host->vmmc && vdd_bit != -1) {
+   if (!IS_ERR(mmc->supply.vmmc) && vdd_bit != -1) {
spin_unlock_irqrestore(>lock, flags);
-   mmc_regulator_set_ocr(host->mmc, host->vmmc, vdd_bit);
+   mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd_bit);
spin_lock_irqsave(>lock, flags);
}
 
@@ -1742,6 +1744,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
 static int sdhci_do_start_signal_voltage_switch(struct sdhci_host *host,
struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host->mmc;
u16 ctrl;
int ret;
 
@@ -1760,8 +1763,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl &= ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc, 270, 
360);
+   if (!IS_ERR(mmc->supply.vqmmc)) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc, 270,
+   360);
if (ret) {
pr_warning("%s: Switching to 3.3V signalling 
voltage "
" failed\n", 
mmc_hostname(host->mmc));
@@ -1781,8 +1785,8 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc,
+   if (!IS_ERR(mmc->supply.vqmmc)) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc,
170, 195);
if (ret) {
pr_warning("%s: Switching to 1.8V signalling 
voltage "
@@ -1811,8 +1815,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc, 110, 
130);
+   if (!IS_ERR(mmc->supply.vqmmc)) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc, 110,
+   130);
if (ret) {
pr_warning("%s: Switching to 1.2V signalling 
voltage "
" failed\n", 
mmc_hostname(host->mmc));
@@ -2975,25 +2980,22 @@ int sdhci_add_host(struct sdhci_host *host)
!(host->mmc->caps & MMC_CAP_NONREMOVABLE))
mmc->caps |= MMC_CAP_NEEDS_POLL;
 
+   /* If t

Re: [PATCH 0/2] SDHCI should use more common MMC structs and functions

[Tim Kryger]

On Thu, Apr 24, 2014 at 1:34 AM, Ulf Hansson  wrote:
> On 18 April 2014 02:46, Tim Kryger  wrote:
>> This series updates SDHCI to use the common regulator infrastructure that mmc
>> core provides.
>>
>> Tim Kryger (2):
>>   mmc: sdhci: Use supplies in common mmc_host struct
>>   mmc: sdhci: Use common mmc_regulator_get_supply
>
> Both patches looks good, but I would prefer if you could squash them
> into one patch.

Sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: core: Try other signal levels during power up

[Tim Kryger]

The eMMC signalling voltage is determined by VCCQ which is provided to
the card by the host.  Signalling is not required to begin at 3.3v and,
if the host and card both support a particular VCC/VCCQ combination, it
can be used immediately.

In contrast, SD Cards must begin with 3.3v signalling and may switch to
a lower voltage signalling if instructed to do so in CMD11.  A message
is required to coordinate this operation because the card only receives
a 3.3v VDD and must know when to use the 1.8v produced by its internal
regulator.

It makes sense for the core to begin with 3.3v signalling but when that
can't be set, 1.8v and 1.2v signalling also should be attempted.  This
is especially important when an external regulator with a limited range
is used to supply VCCQ to an eMMC part.

Signed-off-by: Tim Kryger 
---

Changes since v1:
  - Eliminated temporary err variable and added debug output

 drivers/mmc/core/core.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..72926a9 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1533,8 +1533,13 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
host->ios.timing = MMC_TIMING_LEGACY;
mmc_set_ios(host);
 
-   /* Set signal voltage to 3.3V */
-   __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330);
+   /* Try to set signal voltage to 3.3V but fall back to 1.8v or 1.2v */
+   if (__mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330) == 0)
+   dev_dbg(mmc_dev(host), "Initial signal voltage of 3.3v\n");
+   else if (__mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180) == 0)
+   dev_dbg(mmc_dev(host), "Initial signal voltage of 1.8v\n");
+   else if (__mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120) == 0)
+   dev_dbg(mmc_dev(host), "Initial signal voltage of 1.2v\n");
 
/*
 * This delay should be sufficient to allow the power supply
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: core: Try other signal levels during power up

[Tim Kryger]

On Thu, Apr 24, 2014 at 1:38 AM, Ulf Hansson  wrote:
> On 18 April 2014 20:58, Tim Kryger  wrote:

>>  void mmc_power_up(struct mmc_host *host, u32 ocr)
>>  {
>> +   int err;
>> +
>
> The variable err is not needed, since we don't plan on printing it nor
> returning it. Please remove and handle the return code directly in the
> if statements.

Sure.  I'll send out an updated version shortly.

Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: core: Try other signal levels during power up

[Tim Kryger]

On Thu, Apr 24, 2014 at 1:38 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 18 April 2014 20:58, Tim Kryger tim.kry...@linaro.org wrote:

  void mmc_power_up(struct mmc_host *host, u32 ocr)
  {
 +   int err;
 +

 The variable err is not needed, since we don't plan on printing it nor
 returning it. Please remove and handle the return code directly in the
 if statements.

Sure.  I'll send out an updated version shortly.

Thanks,
Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: core: Try other signal levels during power up

[Tim Kryger]

The eMMC signalling voltage is determined by VCCQ which is provided to
the card by the host.  Signalling is not required to begin at 3.3v and,
if the host and card both support a particular VCC/VCCQ combination, it
can be used immediately.

In contrast, SD Cards must begin with 3.3v signalling and may switch to
a lower voltage signalling if instructed to do so in CMD11.  A message
is required to coordinate this operation because the card only receives
a 3.3v VDD and must know when to use the 1.8v produced by its internal
regulator.

It makes sense for the core to begin with 3.3v signalling but when that
can't be set, 1.8v and 1.2v signalling also should be attempted.  This
is especially important when an external regulator with a limited range
is used to supply VCCQ to an eMMC part.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---

Changes since v1:
  - Eliminated temporary err variable and added debug output

 drivers/mmc/core/core.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..72926a9 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1533,8 +1533,13 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
host-ios.timing = MMC_TIMING_LEGACY;
mmc_set_ios(host);
 
-   /* Set signal voltage to 3.3V */
-   __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330);
+   /* Try to set signal voltage to 3.3V but fall back to 1.8v or 1.2v */
+   if (__mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330) == 0)
+   dev_dbg(mmc_dev(host), Initial signal voltage of 3.3v\n);
+   else if (__mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180) == 0)
+   dev_dbg(mmc_dev(host), Initial signal voltage of 1.8v\n);
+   else if (__mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120) == 0)
+   dev_dbg(mmc_dev(host), Initial signal voltage of 1.2v\n);
 
/*
 * This delay should be sufficient to allow the power supply
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] SDHCI should use more common MMC structs and functions

[Tim Kryger]

On Thu, Apr 24, 2014 at 1:34 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 18 April 2014 02:46, Tim Kryger tim.kry...@linaro.org wrote:
 This series updates SDHCI to use the common regulator infrastructure that mmc
 core provides.

 Tim Kryger (2):
   mmc: sdhci: Use supplies in common mmc_host struct
   mmc: sdhci: Use common mmc_regulator_get_supply

 Both patches looks good, but I would prefer if you could squash them
 into one patch.

Sure.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: sdhci: Use mmc core regulator infrastucture

[Tim Kryger]

Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure.  Additionally, use the
common mmc_regulator_get_supply function to get the regulators and set
the ocr_avail mask.

This change sets the ocr_avail directly based upon the voltage ranges
supported which ensures ocr_avail is set correctly while allowing the
use of regulators that can't provide exactly 1.8v, 3.0v, or 3.3v.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---

This patch is the same as the following series only squashed together.
https://lkml.org/lkml/2014/4/17/653

 drivers/mmc/host/sdhci.c  |   96 +
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 35 insertions(+), 64 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..2d081d8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1429,6 +1429,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
 static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host-mmc;
unsigned long flags;
int vdd_bit = -1;
u8 ctrl;
@@ -1437,8 +1438,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host-flags  SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(host-lock, flags);
-   if (host-vmmc  ios-power_mode == MMC_POWER_OFF)
-   mmc_regulator_set_ocr(host-mmc, host-vmmc, 0);
+   if (!IS_ERR(mmc-supply.vmmc) 
+   ios-power_mode == MMC_POWER_OFF)
+   mmc_regulator_set_ocr(host-mmc, mmc-supply.vmmc, 0);
return;
}
 
@@ -1463,9 +1465,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios-vdd);
 
-   if (host-vmmc  vdd_bit != -1) {
+   if (!IS_ERR(mmc-supply.vmmc)  vdd_bit != -1) {
spin_unlock_irqrestore(host-lock, flags);
-   mmc_regulator_set_ocr(host-mmc, host-vmmc, vdd_bit);
+   mmc_regulator_set_ocr(host-mmc, mmc-supply.vmmc, vdd_bit);
spin_lock_irqsave(host-lock, flags);
}
 
@@ -1742,6 +1744,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
 static int sdhci_do_start_signal_voltage_switch(struct sdhci_host *host,
struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host-mmc;
u16 ctrl;
int ret;
 
@@ -1760,8 +1763,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl = ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (host-vqmmc) {
-   ret = regulator_set_voltage(host-vqmmc, 270, 
360);
+   if (!IS_ERR(mmc-supply.vqmmc)) {
+   ret = regulator_set_voltage(mmc-supply.vqmmc, 270,
+   360);
if (ret) {
pr_warning(%s: Switching to 3.3V signalling 
voltage 
 failed\n, 
mmc_hostname(host-mmc));
@@ -1781,8 +1785,8 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (host-vqmmc) {
-   ret = regulator_set_voltage(host-vqmmc,
+   if (!IS_ERR(mmc-supply.vqmmc)) {
+   ret = regulator_set_voltage(mmc-supply.vqmmc,
170, 195);
if (ret) {
pr_warning(%s: Switching to 1.8V signalling 
voltage 
@@ -1811,8 +1815,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (host-vqmmc) {
-   ret = regulator_set_voltage(host-vqmmc, 110, 
130);
+   if (!IS_ERR(mmc-supply.vqmmc)) {
+   ret = regulator_set_voltage(mmc-supply.vqmmc, 110,
+   130);
if (ret) {
pr_warning(%s: Switching to 1.2V signalling 
voltage 
 failed\n, 
mmc_hostname(host-mmc));
@@ -2975,25 +2980,22 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps  MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
 
+   /* If there are external regulators, get them */
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-   host

Re: [PATCH] regulator: Allow set voltage on fixed regulators

[Tim Kryger]

On Fri, Apr 18, 2014 at 11:52 AM, Mark Brown  wrote:
> On Fri, Apr 18, 2014 at 11:30:10AM -0700, Tim Kryger wrote:
>> If a regulator consumer requests a voltage range that can be satisfied,
>> the return value should indicate success even if that regulator has a
>> fixed voltage.  Since there is already logic to check if the requested
>> voltage range overlaps the allowed range, set REGULATOR_CHANGE_VOLTAGE
>> for regulators with constraints that include a positive voltage.
>
> This seems like the wrong place to fix this, it's nothing to do with DT
> and we shouldn't require that nonsensical permissions are set.  Instead
> we should fix this at the point where we're implementing the permission
> check, have the failure case check the current voltage before returning
> an error.

I now see that Bjorn submitted a patch which did exactly that.

https://lkml.org/lkml/2014/2/5/494

His change made it into v3.15-rc1, so mine is no longer necessary.

Thanks,
Tim Kryger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: Allow set voltage on fixed regulators

[Tim Kryger]

On Fri, Apr 18, 2014 at 11:52 AM, Mark Brown broo...@kernel.org wrote:
 On Fri, Apr 18, 2014 at 11:30:10AM -0700, Tim Kryger wrote:
 If a regulator consumer requests a voltage range that can be satisfied,
 the return value should indicate success even if that regulator has a
 fixed voltage.  Since there is already logic to check if the requested
 voltage range overlaps the allowed range, set REGULATOR_CHANGE_VOLTAGE
 for regulators with constraints that include a positive voltage.

 This seems like the wrong place to fix this, it's nothing to do with DT
 and we shouldn't require that nonsensical permissions are set.  Instead
 we should fix this at the point where we're implementing the permission
 check, have the failure case check the current voltage before returning
 an error.

I now see that Bjorn submitted a patch which did exactly that.

https://lkml.org/lkml/2014/2/5/494

His change made it into v3.15-rc1, so mine is no longer necessary.

Thanks,
Tim Kryger
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

On Wed, Apr 16, 2014 at 12:20 AM, Ulf Hansson  wrote:
> On 15 April 2014 19:09, Tim Kryger  wrote:
>> On Fri, Apr 11, 2014 at 1:15 AM, Ulf Hansson  wrote:

>>> A few times I have suggested to switch to use the
>>> mmc_regulator_get_supply() API to simplify and consolidate code. Could
>>> you please have a look at that?
>>
>> This function will solve my problem but it also suggests that SDHCI
>> drivers should use the vmmc/vqmmc pointers in the mmc_host struct
>> rather than the ones in the sdhci_host struct.
>>
>> Is this your intent?  Do you want to see the regulator pointers in the
>> sdhci_host struct removed once all drivers are modified to use the
>> mmc_host ones?
>
> Correct. That will consolidate code!
>
> Then if sdhci has some special needs for regulators, let's first see
> if we can adopt the API to handle it, before we decide to put that
> code in sdhci driver.

Sounds good.  Please forget about this patch and consider the new
series instead.

https://lkml.org/lkml/2014/4/17/653
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: Allow set voltage on fixed regulators

[Tim Kryger]

On Fri, Apr 18, 2014 at 11:52 AM, Mark Brown  wrote:
> On Fri, Apr 18, 2014 at 11:30:10AM -0700, Tim Kryger wrote:
>> If a regulator consumer requests a voltage range that can be satisfied,
>> the return value should indicate success even if that regulator has a
>> fixed voltage.  Since there is already logic to check if the requested
>> voltage range overlaps the allowed range, set REGULATOR_CHANGE_VOLTAGE
>> for regulators with constraints that include a positive voltage.
>
> This seems like the wrong place to fix this, it's nothing to do with DT
> and we shouldn't require that nonsensical permissions are set.  Instead
> we should fix this at the point where we're implementing the permission
> check, have the failure case check the current voltage before returning
> an error.

Are you saying that REGULATOR_CHANGE_VOLTAGE and
REGULATOR_CHANGE_CURRENT are nonsense?

It does seem like, even in the non-DT case, that the decision of
whether to call the underlying set_voltage and set_current functions
could be made solely based on the numerical voltage and current
constraints.

Thanks,
Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: core: Try other signal levels during power up

[Tim Kryger]

The eMMC signalling voltage is determined by VCCQ which is provided to
the card by the host.  Signalling is not required to begin at 3.3v and,
if the host and card both support a particular VCC/VCCQ combination, it
can be used immediately.

In contrast, SD Cards must begin with 3.3v signalling and may switch to
a lower voltage signalling if instructed to do so in CMD11.  A message
is required to coordinate this operation because the card only receives
a 3.3v VDD and must know when to use the 1.8v produced by its internal
regulator.

It makes sense for the core to begin with 3.3v signalling but when that
can't be set, 1.8v and 1.2v signalling also should be attempted.  This
is especially important when an external regulator with a limited range
is used to supply VCCQ to an eMMC part.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/core/core.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..ecdbeae 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1517,6 +1517,8 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned 
int drv_type)
  */
 void mmc_power_up(struct mmc_host *host, u32 ocr)
 {
+   int err;
+
if (host->ios.power_mode == MMC_POWER_ON)
return;
 
@@ -1534,7 +1536,13 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
mmc_set_ios(host);
 
/* Set signal voltage to 3.3V */
-   __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330);
+   err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330);
+
+   /* Since eMMC parts can start at 1.8v or 1.2v try those too */
+   if (err)
+   err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180);
+   if (err)
+   __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120);
 
/*
 * This delay should be sufficient to allow the power supply
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: Allow set voltage on fixed regulators

[Tim Kryger]

If a regulator consumer requests a voltage range that can be satisfied,
the return value should indicate success even if that regulator has a
fixed voltage.  Since there is already logic to check if the requested
voltage range overlaps the allowed range, set REGULATOR_CHANGE_VOLTAGE
for regulators with constraints that include a positive voltage.

Signed-off-by: Tim Kryger 
---
 drivers/regulator/of_regulator.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index ea4f36f..a205d62 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -36,7 +36,7 @@ static void of_get_regulation_constraints(struct device_node 
*np,
constraints->max_uV = be32_to_cpu(*max_uV);
 
/* Voltage change possible? */
-   if (constraints->min_uV != constraints->max_uV)
+   if (constraints->max_uV > 0)
constraints->valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
/* Only one voltage?  Then make sure it's set. */
if (min_uV && max_uV && constraints->min_uV == constraints->max_uV)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

This series introduces the driver for the Kona PWM controller found in
Broadcom mobile SoCs like bcm281xx and updates the device tree and the
defconfig to enable use of this hardware on the bcm28155 AP board.

Changes since v5:
  - Rebased on v3.15-rc1

Changes since v4:
  - Added in real polarity support
  - Labeled trigger bits as such rather than use the name from hw docs
  - Listed unsual hardware characteristics at the top of the file
  - Removed default from Kconfig and update defconfig accordingly
  - Always use unsigned int for temporary register values

Changes since v3:
  - Removed polarity support for now
  - Cleaned up whitespace issues, shortened some variable names
  - Use container_of instead of dev_get_drvdata to get private data
  - Removed workaround for PWM framework bug
  - Reworded some binding documentation

Changes since v2:
  - SoC DTS file updated to use real clock's phandle + specifier
  - Toggle smooth mode off during apply so new settings take immediately

Changes since v1:
  - Fixed up macros to be clearer and more complete
  - Corrected spelling and punctuation mistakes
  - Added support for polarity
  - Made peripheral clock use more efficient
  - Made prescale and duty computation clearer
  - Moved Makefile addition to keep alphabetical
  - Split complex lines into multiple steps


Tim Kryger (5):
  Documentation: dt: Add Kona PWM binding
  pwm: kona: Introduce Kona PWM controller support
  ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
  ARM: dts: Enable the PWM for bcm28155 AP board
  ARM: bcm_defconfig: Enable PWM and Backlight

 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 ++
 arch/arm/boot/dts/bcm11351.dtsi|8 +
 arch/arm/boot/dts/bcm28155-ap.dts  |4 +
 arch/arm/configs/bcm_defconfig |3 +
 drivers/pwm/Kconfig|9 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 7 files changed, 365 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

Add support for the six-channel Kona PWM controller found on Broadcom
mobile SoCs like bcm281xx.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 drivers/pwm/Kconfig|9 ++
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 5b34ff2..4ad7b89 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,15 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.
 
+config PWM_BCM_KONA
+   tristate "Kona PWM support"
+   depends on ARCH_BCM_MOBILE
+   help
+ Generic PWM framework driver for Broadcom Kona PWM block.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm-kona.
+
 config PWM_BFIN
tristate "Blackfin PWM support"
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index e57d2c3..5c86a19 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
new file mode 100644
index 000..ee8a59d
--- /dev/null
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The Kona PWM has some unusual characteristics.  Here are the main points.
+ *
+ * 1) There is no disable bit and the hardware docs advise programming a zero
+ *duty to achieve output equivalent to that of a normal disable operation.
+ *
+ * 2) Changes to prescale, duty, period, and polarity do not take effect until
+ *a subsequent rising edge of the trigger bit.
+ *
+ * 3) If the smooth bit and trigger bit are both low, the output is a constant
+ *high signal.  Otherwise, the earlier waveform continues to be output.
+ *
+ * 4) If the smooth bit is set on the rising edge of the trigger bit, output
+ *will transition to the new settings on a period boundary (which could be
+ *seconds away).  If the smooth bit is clear, new settings will be applied
+ *as soon as possible (the hardware always has a 400ns delay).
+ *
+ * 5) When the external clock that feeds the PWM is disabled, output is pegged
+ *high or low depending on its state at that exact instant.
+ */
+
+#define PWM_CONTROL_OFFSET (0x)
+#define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan))
+#define PWM_CONTROL_TYPE_SHIFT(chan)   (16 + (chan))
+#define PWM_CONTROL_POLARITY_SHIFT(chan)   (8 + (chan))
+#define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan)
+
+#define PRESCALE_OFFSET(0x0004)
+#define PRESCALE_SHIFT(chan)   ((chan) << 2)
+#define PRESCALE_MASK(chan)(0x7 << PRESCALE_SHIFT(chan))
+#define PRESCALE_MIN   (0x)
+#define PRESCALE_MAX   (0x0007)
+
+#define PERIOD_COUNT_OFFSET(chan)  (0x0008 + ((chan) << 3))
+#define PERIOD_COUNT_MIN   (0x0002)
+#define PERIOD_COUNT_MAX   (0x00ff)
+
+#define DUTY_CYCLE_HIGH_OFFSET(chan)   (0x000c + ((chan) << 3))
+#define DUTY_CYCLE_HIGH_MIN(0x)
+#define DUTY_CYCLE_HIGH_MAX(0x00ff)
+
+struct kona_pwmc {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip)
+{
+   return container_of(_chip, struct kona_pwmc, chip);
+}
+
+static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
+{
+   unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
+
+   /* Cl

[PATCH v6 5/5] ARM: bcm_defconfig: Enable PWM and Backlight

[Tim Kryger]

Enable PWM drivers and the PWM-based backlight driver.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/configs/bcm_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 0100464..f09f7c6 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -91,6 +91,7 @@ CONFIG_FB=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
@@ -104,6 +105,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_PWM=y
+CONFIG_PWM_BCM_KONA=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

Add the binding description for the Kona PWM controller found on Broadcom's
mobile SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000..8eae9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+
+This controller has 6 channels.
+
+Required Properties :
+- compatible: should contain "brcm,kona-pwm"
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+
+Example:
+
+pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xc4>;
+   clocks = <_clk>;
+   #pwm-cells = <3>;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 3/5] ARM: dts: Declare the PWM for bcm11351 (bcm281xx)

[Tim Kryger]

Add the device tree node for the PWM on bcm11351 SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm11351.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 64d069b..6b05ae6 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -193,6 +193,14 @@
status = "disabled";
};
 
+   pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xcc>;
+   clocks = <_ccu BCM281XX_SLAVE_CCU_PWM>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
clocks {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 4/5] ARM: dts: Enable the PWM for bcm28155 AP board

[Tim Kryger]

Mark the PWM as enabled on the bcm28155 AP board.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm28155-ap.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
b/arch/arm/boot/dts/bcm28155-ap.dts
index af3da55..9ce91dd 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -69,6 +69,10 @@
status = "okay";
};
 
+   pwm: pwm@3e01a000 {
+   status = "okay";
+   };
+
usbotg: usb@3f12 {
vusb_d-supply = <_reg>;
vusb_a-supply = <_reg>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 4/5] ARM: dts: Enable the PWM for bcm28155 AP board

[Tim Kryger]

Mark the PWM as enabled on the bcm28155 AP board.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/boot/dts/bcm28155-ap.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
b/arch/arm/boot/dts/bcm28155-ap.dts
index af3da55..9ce91dd 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -69,6 +69,10 @@
status = okay;
};
 
+   pwm: pwm@3e01a000 {
+   status = okay;
+   };
+
usbotg: usb@3f12 {
vusb_d-supply = usbldo_reg;
vusb_a-supply = iosr1_reg;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 3/5] ARM: dts: Declare the PWM for bcm11351 (bcm281xx)

[Tim Kryger]

Add the device tree node for the PWM on bcm11351 SoCs.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/boot/dts/bcm11351.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 64d069b..6b05ae6 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -193,6 +193,14 @@
status = disabled;
};
 
+   pwm: pwm@3e01a000 {
+   compatible = brcm,bcm11351-pwm, brcm,kona-pwm;
+   reg = 0x3e01a000 0xcc;
+   clocks = slave_ccu BCM281XX_SLAVE_CCU_PWM;
+   #pwm-cells = 3;
+   status = disabled;
+   };
+
clocks {
#address-cells = 1;
#size-cells = 1;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

Add the binding description for the Kona PWM controller found on Broadcom's
mobile SoCs.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000..8eae9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+
+This controller has 6 channels.
+
+Required Properties :
+- compatible: should contain brcm,kona-pwm
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+
+Example:
+
+pwm: pwm@3e01a000 {
+   compatible = brcm,bcm11351-pwm, brcm,kona-pwm;
+   reg = 0x3e01a000 0xc4;
+   clocks = pwm_clk;
+   #pwm-cells = 3;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 5/5] ARM: bcm_defconfig: Enable PWM and Backlight

[Tim Kryger]

Enable PWM drivers and the PWM-based backlight driver.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/configs/bcm_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 0100464..f09f7c6 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -91,6 +91,7 @@ CONFIG_FB=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
@@ -104,6 +105,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_PWM=y
+CONFIG_PWM_BCM_KONA=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

Add support for the six-channel Kona PWM controller found on Broadcom
mobile SoCs like bcm281xx.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 drivers/pwm/Kconfig|9 ++
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 5b34ff2..4ad7b89 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,15 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.
 
+config PWM_BCM_KONA
+   tristate Kona PWM support
+   depends on ARCH_BCM_MOBILE
+   help
+ Generic PWM framework driver for Broadcom Kona PWM block.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm-kona.
+
 config PWM_BFIN
tristate Blackfin PWM support
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index e57d2c3..5c86a19 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
new file mode 100644
index 000..ee8a59d
--- /dev/null
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/math64.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pwm.h
+#include linux/slab.h
+#include linux/types.h
+
+/*
+ * The Kona PWM has some unusual characteristics.  Here are the main points.
+ *
+ * 1) There is no disable bit and the hardware docs advise programming a zero
+ *duty to achieve output equivalent to that of a normal disable operation.
+ *
+ * 2) Changes to prescale, duty, period, and polarity do not take effect until
+ *a subsequent rising edge of the trigger bit.
+ *
+ * 3) If the smooth bit and trigger bit are both low, the output is a constant
+ *high signal.  Otherwise, the earlier waveform continues to be output.
+ *
+ * 4) If the smooth bit is set on the rising edge of the trigger bit, output
+ *will transition to the new settings on a period boundary (which could be
+ *seconds away).  If the smooth bit is clear, new settings will be applied
+ *as soon as possible (the hardware always has a 400ns delay).
+ *
+ * 5) When the external clock that feeds the PWM is disabled, output is pegged
+ *high or low depending on its state at that exact instant.
+ */
+
+#define PWM_CONTROL_OFFSET (0x)
+#define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan))
+#define PWM_CONTROL_TYPE_SHIFT(chan)   (16 + (chan))
+#define PWM_CONTROL_POLARITY_SHIFT(chan)   (8 + (chan))
+#define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan)
+
+#define PRESCALE_OFFSET(0x0004)
+#define PRESCALE_SHIFT(chan)   ((chan)  2)
+#define PRESCALE_MASK(chan)(0x7  PRESCALE_SHIFT(chan))
+#define PRESCALE_MIN   (0x)
+#define PRESCALE_MAX   (0x0007)
+
+#define PERIOD_COUNT_OFFSET(chan)  (0x0008 + ((chan)  3))
+#define PERIOD_COUNT_MIN   (0x0002)
+#define PERIOD_COUNT_MAX   (0x00ff)
+
+#define DUTY_CYCLE_HIGH_OFFSET(chan)   (0x000c + ((chan)  3))
+#define DUTY_CYCLE_HIGH_MIN(0x)
+#define DUTY_CYCLE_HIGH_MAX(0x00ff)
+
+struct kona_pwmc {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip)
+{
+   return container_of(_chip, struct kona_pwmc, chip);
+}
+
+static void

[PATCH v6 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

This series introduces the driver for the Kona PWM controller found in
Broadcom mobile SoCs like bcm281xx and updates the device tree and the
defconfig to enable use of this hardware on the bcm28155 AP board.

Changes since v5:
  - Rebased on v3.15-rc1

Changes since v4:
  - Added in real polarity support
  - Labeled trigger bits as such rather than use the name from hw docs
  - Listed unsual hardware characteristics at the top of the file
  - Removed default from Kconfig and update defconfig accordingly
  - Always use unsigned int for temporary register values

Changes since v3:
  - Removed polarity support for now
  - Cleaned up whitespace issues, shortened some variable names
  - Use container_of instead of dev_get_drvdata to get private data
  - Removed workaround for PWM framework bug
  - Reworded some binding documentation

Changes since v2:
  - SoC DTS file updated to use real clock's phandle + specifier
  - Toggle smooth mode off during apply so new settings take immediately

Changes since v1:
  - Fixed up macros to be clearer and more complete
  - Corrected spelling and punctuation mistakes
  - Added support for polarity
  - Made peripheral clock use more efficient
  - Made prescale and duty computation clearer
  - Moved Makefile addition to keep alphabetical
  - Split complex lines into multiple steps


Tim Kryger (5):
  Documentation: dt: Add Kona PWM binding
  pwm: kona: Introduce Kona PWM controller support
  ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
  ARM: dts: Enable the PWM for bcm28155 AP board
  ARM: bcm_defconfig: Enable PWM and Backlight

 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 ++
 arch/arm/boot/dts/bcm11351.dtsi|8 +
 arch/arm/boot/dts/bcm28155-ap.dts  |4 +
 arch/arm/configs/bcm_defconfig |3 +
 drivers/pwm/Kconfig|9 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 7 files changed, 365 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: Allow set voltage on fixed regulators

[Tim Kryger]

If a regulator consumer requests a voltage range that can be satisfied,
the return value should indicate success even if that regulator has a
fixed voltage.  Since there is already logic to check if the requested
voltage range overlaps the allowed range, set REGULATOR_CHANGE_VOLTAGE
for regulators with constraints that include a positive voltage.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/regulator/of_regulator.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index ea4f36f..a205d62 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -36,7 +36,7 @@ static void of_get_regulation_constraints(struct device_node 
*np,
constraints-max_uV = be32_to_cpu(*max_uV);
 
/* Voltage change possible? */
-   if (constraints-min_uV != constraints-max_uV)
+   if (constraints-max_uV  0)
constraints-valid_ops_mask |= REGULATOR_CHANGE_VOLTAGE;
/* Only one voltage?  Then make sure it's set. */
if (min_uV  max_uV  constraints-min_uV == constraints-max_uV)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: core: Try other signal levels during power up

[Tim Kryger]

The eMMC signalling voltage is determined by VCCQ which is provided to
the card by the host.  Signalling is not required to begin at 3.3v and,
if the host and card both support a particular VCC/VCCQ combination, it
can be used immediately.

In contrast, SD Cards must begin with 3.3v signalling and may switch to
a lower voltage signalling if instructed to do so in CMD11.  A message
is required to coordinate this operation because the card only receives
a 3.3v VDD and must know when to use the 1.8v produced by its internal
regulator.

It makes sense for the core to begin with 3.3v signalling but when that
can't be set, 1.8v and 1.2v signalling also should be attempted.  This
is especially important when an external regulator with a limited range
is used to supply VCCQ to an eMMC part.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/mmc/core/core.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..ecdbeae 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1517,6 +1517,8 @@ void mmc_set_driver_type(struct mmc_host *host, unsigned 
int drv_type)
  */
 void mmc_power_up(struct mmc_host *host, u32 ocr)
 {
+   int err;
+
if (host-ios.power_mode == MMC_POWER_ON)
return;
 
@@ -1534,7 +1536,13 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
mmc_set_ios(host);
 
/* Set signal voltage to 3.3V */
-   __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330);
+   err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330);
+
+   /* Since eMMC parts can start at 1.8v or 1.2v try those too */
+   if (err)
+   err = __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_180);
+   if (err)
+   __mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_120);
 
/*
 * This delay should be sufficient to allow the power supply
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] regulator: Allow set voltage on fixed regulators

[Tim Kryger]

On Fri, Apr 18, 2014 at 11:52 AM, Mark Brown broo...@kernel.org wrote:
 On Fri, Apr 18, 2014 at 11:30:10AM -0700, Tim Kryger wrote:
 If a regulator consumer requests a voltage range that can be satisfied,
 the return value should indicate success even if that regulator has a
 fixed voltage.  Since there is already logic to check if the requested
 voltage range overlaps the allowed range, set REGULATOR_CHANGE_VOLTAGE
 for regulators with constraints that include a positive voltage.

 This seems like the wrong place to fix this, it's nothing to do with DT
 and we shouldn't require that nonsensical permissions are set.  Instead
 we should fix this at the point where we're implementing the permission
 check, have the failure case check the current voltage before returning
 an error.

Are you saying that REGULATOR_CHANGE_VOLTAGE and
REGULATOR_CHANGE_CURRENT are nonsense?

It does seem like, even in the non-DT case, that the decision of
whether to call the underlying set_voltage and set_current functions
could be made solely based on the numerical voltage and current
constraints.

Thanks,
Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

On Wed, Apr 16, 2014 at 12:20 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 15 April 2014 19:09, Tim Kryger tim.kry...@linaro.org wrote:
 On Fri, Apr 11, 2014 at 1:15 AM, Ulf Hansson ulf.hans...@linaro.org wrote:

 A few times I have suggested to switch to use the
 mmc_regulator_get_supply() API to simplify and consolidate code. Could
 you please have a look at that?

 This function will solve my problem but it also suggests that SDHCI
 drivers should use the vmmc/vqmmc pointers in the mmc_host struct
 rather than the ones in the sdhci_host struct.

 Is this your intent?  Do you want to see the regulator pointers in the
 sdhci_host struct removed once all drivers are modified to use the
 mmc_host ones?

 Correct. That will consolidate code!

 Then if sdhci has some special needs for regulators, let's first see
 if we can adopt the API to handle it, before we decide to put that
 code in sdhci driver.

Sounds good.  Please forget about this patch and consider the new
series instead.

https://lkml.org/lkml/2014/4/17/653
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] mmc: sdhci: Use supplies in common mmc_host struct

[Tim Kryger]

Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/host/sdhci.c  |   71 -
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..16fba66 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1429,6 +1429,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
 static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host->mmc;
unsigned long flags;
int vdd_bit = -1;
u8 ctrl;
@@ -1437,8 +1438,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host->flags & SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(>lock, flags);
-   if (host->vmmc && ios->power_mode == MMC_POWER_OFF)
-   mmc_regulator_set_ocr(host->mmc, host->vmmc, 0);
+   if (mmc->supply.vmmc && ios->power_mode == MMC_POWER_OFF)
+   mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, 0);
return;
}
 
@@ -1463,9 +1464,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios->vdd);
 
-   if (host->vmmc && vdd_bit != -1) {
+   if (mmc->supply.vmmc && vdd_bit != -1) {
spin_unlock_irqrestore(>lock, flags);
-   mmc_regulator_set_ocr(host->mmc, host->vmmc, vdd_bit);
+   mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd_bit);
spin_lock_irqsave(>lock, flags);
}
 
@@ -1742,6 +1743,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
 static int sdhci_do_start_signal_voltage_switch(struct sdhci_host *host,
struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host->mmc;
u16 ctrl;
int ret;
 
@@ -1760,8 +1762,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl &= ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc, 270, 
360);
+   if (mmc->supply.vqmmc) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc, 270,
+   360);
if (ret) {
pr_warning("%s: Switching to 3.3V signalling 
voltage "
" failed\n", 
mmc_hostname(host->mmc));
@@ -1781,8 +1784,8 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc,
+   if (mmc->supply.vqmmc) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc,
170, 195);
if (ret) {
pr_warning("%s: Switching to 1.8V signalling 
voltage "
@@ -1811,8 +1814,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (host->vqmmc) {
-   ret = regulator_set_voltage(host->vqmmc, 110, 
130);
+   if (mmc->supply.vqmmc) {
+   ret = regulator_set_voltage(mmc->supply.vqmmc, 110,
+   130);
if (ret) {
pr_warning("%s: Switching to 1.2V signalling 
voltage "
" failed\n", 
mmc_hostname(host->mmc));
@@ -2976,24 +2980,24 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->caps |= MMC_CAP_NEEDS_POLL;
 
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-   host->vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
-   if (IS_ERR_OR_NULL(host->vqmmc)) {
-   if (PTR_ERR(host->vqmmc) < 0) {
+   mmc->supply.vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
+   if (IS_ERR_OR_NULL(mmc->supply.vqmmc)) {
+   if (PTR_ERR(mmc->supply.vqmmc) < 0) {
pr_info("%s: no vqmmc regulator found\n",
mmc_ho

[PATCH 0/2] SDHCI should use more common MMC structs and functions

[Tim Kryger]

This series updates SDHCI to use the common regulator infrastructure that mmc
core provides.

Tim Kryger (2):
  mmc: sdhci: Use supplies in common mmc_host struct
  mmc: sdhci: Use common mmc_regulator_get_supply

 drivers/mmc/host/sdhci.c  |   96 +
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 35 insertions(+), 64 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] mmc: sdhci: Use common mmc_regulator_get_supply

[Tim Kryger]

Replace some buggy code with a call to mmc_regulator_get_supply.

When external regulator provides VDD, ocr_avail is set directly based on
the supported voltage range.  This allows for the use of regulators that
can't provide exactly 1.8v, 3.0v, or 3.3v.  Commit cec2e21 had attempted
to address this by relaxing the range checks in the SDHCI driver but it
set the capabilities as an intermediate step which meant ocr_avail could
get bits set for unsupported voltages.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/host/sdhci.c |   67 +-
 1 file changed, 18 insertions(+), 49 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 16fba66..2d081d8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1438,7 +1438,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host->flags & SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(>lock, flags);
-   if (mmc->supply.vmmc && ios->power_mode == MMC_POWER_OFF)
+   if (!IS_ERR(mmc->supply.vmmc) &&
+   ios->power_mode == MMC_POWER_OFF)
mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, 0);
return;
}
@@ -1464,7 +1465,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios->vdd);
 
-   if (mmc->supply.vmmc && vdd_bit != -1) {
+   if (!IS_ERR(mmc->supply.vmmc) && vdd_bit != -1) {
spin_unlock_irqrestore(>lock, flags);
mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd_bit);
spin_lock_irqsave(>lock, flags);
@@ -1762,7 +1763,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl &= ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (mmc->supply.vqmmc) {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_set_voltage(mmc->supply.vqmmc, 270,
360);
if (ret) {
@@ -1784,7 +1785,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (mmc->supply.vqmmc) {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_set_voltage(mmc->supply.vqmmc,
170, 195);
if (ret) {
@@ -1814,7 +1815,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (mmc->supply.vqmmc) {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_set_voltage(mmc->supply.vqmmc, 110,
130);
if (ret) {
@@ -2979,15 +2980,12 @@ int sdhci_add_host(struct sdhci_host *host)
!(host->mmc->caps & MMC_CAP_NONREMOVABLE))
mmc->caps |= MMC_CAP_NEEDS_POLL;
 
+   /* If there are external regulators, get them */
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-   mmc->supply.vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
-   if (IS_ERR_OR_NULL(mmc->supply.vqmmc)) {
-   if (PTR_ERR(mmc->supply.vqmmc) < 0) {
-   pr_info("%s: no vqmmc regulator found\n",
-   mmc_hostname(mmc));
-   mmc->supply.vqmmc = NULL;
-   }
-   } else {
+   if (!IS_ERR(mmc->supply.vqmmc)) {
ret = regulator_enable(mmc->supply.vqmmc);
if (!regulator_is_supported_voltage(mmc->supply.vqmmc, 170,
195))
@@ -3058,34 +3056,6 @@ int sdhci_add_host(struct sdhci_host *host)
 
ocr_avail = 0;
 
-   mmc->supply.vmmc = regulator_get_optional(mmc_dev(mmc), "vmmc");
-   if (IS_ERR_OR_NULL(mmc->supply.vmmc)) {
-   if (PTR_ERR(mmc->supply.vmmc) < 0) {
-   pr_info("%s: no vmmc regulator found\n",
-   mmc_hostname(mmc));
-   mmc->supply.vmmc = NULL;
-   }
-   }
-
-#ifdef CONFIG_REGULATOR
-   /*
-* Voltage range check makes sense only if regulator reports
-* any voltage value.
-*/
-   if (mmc->supply.vmmc && regulator_

[PATCH] mmc: core: Improve support for deferred regulators

[Tim Kryger]

It is important that callers of mmc_regulator_get_supply know if either
vmmc or vqmmc are present but not yet available.  To support this need,
modify this function to return zero except when either of the regulator
get operations fail with -EPROBE_DEFER.  Current callers don't check the
return value and may continue to use IS_ERR on the vmmc/vqmmc values to
determine if those regulators are available.  Furthermore, since all of
these callers are capable of dealing with absent regulators, switch over
to use the non-optional variety of the regulator get call.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/core/core.c |   27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..095eef0 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1313,21 +1313,28 @@ EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
 int mmc_regulator_get_supply(struct mmc_host *mmc)
 {
struct device *dev = mmc_dev(mmc);
-   struct regulator *supply;
int ret;
 
-   supply = devm_regulator_get(dev, "vmmc");
-   mmc->supply.vmmc = supply;
+   mmc->supply.vmmc = devm_regulator_get_optional(dev, "vmmc");
mmc->supply.vqmmc = devm_regulator_get_optional(dev, "vqmmc");
 
-   if (IS_ERR(supply))
-   return PTR_ERR(supply);
+   if (IS_ERR(mmc->supply.vmmc)) {
+   if (PTR_ERR(mmc->supply.vmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, "No vmmc regulator found\n");
+   } else {
+   ret = mmc_regulator_get_ocrmask(mmc->supply.vmmc);
+   if (ret > 0)
+   mmc->ocr_avail = ret;
+   else
+   dev_warn(dev, "Failed getting OCR mask: %d\n", ret);
+   }
 
-   ret = mmc_regulator_get_ocrmask(supply);
-   if (ret > 0)
-   mmc->ocr_avail = ret;
-   else
-   dev_warn(mmc_dev(mmc), "Failed getting OCR mask: %d\n", ret);
+   if (IS_ERR(mmc->supply.vqmmc)) {
+   if (PTR_ERR(mmc->supply.vqmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, "No vqmmc regulator found\n");
+   }
 
return 0;
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: core: Return error in get optional stub

[Tim Kryger]

Drivers that call regulator_get_optional are tolerant to the absence of
that regulator.  By modifying the value returned from the stub function
to match that seen when a regulator isn't present, callers can wrap the
regulator logic with an IS_ERR based conditional even if they happen to
call regulator_is_supported_voltage.  This improves efficiency as well
as eliminates the possibility for a very subtle bug.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
---

This change was proposed here: https://lkml.org/lkml/2014/4/16/627

 include/linux/regulator/consumer.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index e530681..1a4a8c1 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -258,14 +258,14 @@ regulator_get_exclusive(struct device *dev, const char 
*id)
 static inline struct regulator *__must_check
 regulator_get_optional(struct device *dev, const char *id)
 {
-   return NULL;
+   return ERR_PTR(-ENODEV);
 }
 
 
 static inline struct regulator *__must_check
 devm_regulator_get_optional(struct device *dev, const char *id)
 {
-   return NULL;
+   return ERR_PTR(-ENODEV);
 }
 
 static inline void regulator_put(struct regulator *regulator)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: core: Return error in get optional stub

[Tim Kryger]

Drivers that call regulator_get_optional are tolerant to the absence of
that regulator.  By modifying the value returned from the stub function
to match that seen when a regulator isn't present, callers can wrap the
regulator logic with an IS_ERR based conditional even if they happen to
call regulator_is_supported_voltage.  This improves efficiency as well
as eliminates the possibility for a very subtle bug.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
---

This change was proposed here: https://lkml.org/lkml/2014/4/16/627

 include/linux/regulator/consumer.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index e530681..1a4a8c1 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -258,14 +258,14 @@ regulator_get_exclusive(struct device *dev, const char 
*id)
 static inline struct regulator *__must_check
 regulator_get_optional(struct device *dev, const char *id)
 {
-   return NULL;
+   return ERR_PTR(-ENODEV);
 }
 
 
 static inline struct regulator *__must_check
 devm_regulator_get_optional(struct device *dev, const char *id)
 {
-   return NULL;
+   return ERR_PTR(-ENODEV);
 }
 
 static inline void regulator_put(struct regulator *regulator)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: core: Improve support for deferred regulators

[Tim Kryger]

It is important that callers of mmc_regulator_get_supply know if either
vmmc or vqmmc are present but not yet available.  To support this need,
modify this function to return zero except when either of the regulator
get operations fail with -EPROBE_DEFER.  Current callers don't check the
return value and may continue to use IS_ERR on the vmmc/vqmmc values to
determine if those regulators are available.  Furthermore, since all of
these callers are capable of dealing with absent regulators, switch over
to use the non-optional variety of the regulator get call.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/mmc/core/core.c |   27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index acbc3f2..095eef0 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1313,21 +1313,28 @@ EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
 int mmc_regulator_get_supply(struct mmc_host *mmc)
 {
struct device *dev = mmc_dev(mmc);
-   struct regulator *supply;
int ret;
 
-   supply = devm_regulator_get(dev, vmmc);
-   mmc-supply.vmmc = supply;
+   mmc-supply.vmmc = devm_regulator_get_optional(dev, vmmc);
mmc-supply.vqmmc = devm_regulator_get_optional(dev, vqmmc);
 
-   if (IS_ERR(supply))
-   return PTR_ERR(supply);
+   if (IS_ERR(mmc-supply.vmmc)) {
+   if (PTR_ERR(mmc-supply.vmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, No vmmc regulator found\n);
+   } else {
+   ret = mmc_regulator_get_ocrmask(mmc-supply.vmmc);
+   if (ret  0)
+   mmc-ocr_avail = ret;
+   else
+   dev_warn(dev, Failed getting OCR mask: %d\n, ret);
+   }
 
-   ret = mmc_regulator_get_ocrmask(supply);
-   if (ret  0)
-   mmc-ocr_avail = ret;
-   else
-   dev_warn(mmc_dev(mmc), Failed getting OCR mask: %d\n, ret);
+   if (IS_ERR(mmc-supply.vqmmc)) {
+   if (PTR_ERR(mmc-supply.vqmmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_info(dev, No vqmmc regulator found\n);
+   }
 
return 0;
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] mmc: sdhci: Use common mmc_regulator_get_supply

[Tim Kryger]

Replace some buggy code with a call to mmc_regulator_get_supply.

When external regulator provides VDD, ocr_avail is set directly based on
the supported voltage range.  This allows for the use of regulators that
can't provide exactly 1.8v, 3.0v, or 3.3v.  Commit cec2e21 had attempted
to address this by relaxing the range checks in the SDHCI driver but it
set the capabilities as an intermediate step which meant ocr_avail could
get bits set for unsupported voltages.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/mmc/host/sdhci.c |   67 +-
 1 file changed, 18 insertions(+), 49 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 16fba66..2d081d8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1438,7 +1438,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host-flags  SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(host-lock, flags);
-   if (mmc-supply.vmmc  ios-power_mode == MMC_POWER_OFF)
+   if (!IS_ERR(mmc-supply.vmmc) 
+   ios-power_mode == MMC_POWER_OFF)
mmc_regulator_set_ocr(host-mmc, mmc-supply.vmmc, 0);
return;
}
@@ -1464,7 +1465,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios-vdd);
 
-   if (mmc-supply.vmmc  vdd_bit != -1) {
+   if (!IS_ERR(mmc-supply.vmmc)  vdd_bit != -1) {
spin_unlock_irqrestore(host-lock, flags);
mmc_regulator_set_ocr(host-mmc, mmc-supply.vmmc, vdd_bit);
spin_lock_irqsave(host-lock, flags);
@@ -1762,7 +1763,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl = ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (mmc-supply.vqmmc) {
+   if (!IS_ERR(mmc-supply.vqmmc)) {
ret = regulator_set_voltage(mmc-supply.vqmmc, 270,
360);
if (ret) {
@@ -1784,7 +1785,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (mmc-supply.vqmmc) {
+   if (!IS_ERR(mmc-supply.vqmmc)) {
ret = regulator_set_voltage(mmc-supply.vqmmc,
170, 195);
if (ret) {
@@ -1814,7 +1815,7 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (mmc-supply.vqmmc) {
+   if (!IS_ERR(mmc-supply.vqmmc)) {
ret = regulator_set_voltage(mmc-supply.vqmmc, 110,
130);
if (ret) {
@@ -2979,15 +2980,12 @@ int sdhci_add_host(struct sdhci_host *host)
!(host-mmc-caps  MMC_CAP_NONREMOVABLE))
mmc-caps |= MMC_CAP_NEEDS_POLL;
 
+   /* If there are external regulators, get them */
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-   mmc-supply.vqmmc = regulator_get_optional(mmc_dev(mmc), vqmmc);
-   if (IS_ERR_OR_NULL(mmc-supply.vqmmc)) {
-   if (PTR_ERR(mmc-supply.vqmmc)  0) {
-   pr_info(%s: no vqmmc regulator found\n,
-   mmc_hostname(mmc));
-   mmc-supply.vqmmc = NULL;
-   }
-   } else {
+   if (!IS_ERR(mmc-supply.vqmmc)) {
ret = regulator_enable(mmc-supply.vqmmc);
if (!regulator_is_supported_voltage(mmc-supply.vqmmc, 170,
195))
@@ -3058,34 +3056,6 @@ int sdhci_add_host(struct sdhci_host *host)
 
ocr_avail = 0;
 
-   mmc-supply.vmmc = regulator_get_optional(mmc_dev(mmc), vmmc);
-   if (IS_ERR_OR_NULL(mmc-supply.vmmc)) {
-   if (PTR_ERR(mmc-supply.vmmc)  0) {
-   pr_info(%s: no vmmc regulator found\n,
-   mmc_hostname(mmc));
-   mmc-supply.vmmc = NULL;
-   }
-   }
-
-#ifdef CONFIG_REGULATOR
-   /*
-* Voltage range check makes sense only if regulator reports
-* any voltage value.
-*/
-   if (mmc-supply.vmmc  regulator_get_voltage(mmc-supply.vmmc)  0) {
-   ret = regulator_is_supported_voltage(mmc-supply.vmmc, 270,
-   360);
-   if ((ret = 0) || (!(caps[0]  SDHCI_CAN_VDD_330)))
-   caps[0] = ~SDHCI_CAN_VDD_330

[PATCH 0/2] SDHCI should use more common MMC structs and functions

[Tim Kryger]

This series updates SDHCI to use the common regulator infrastructure that mmc
core provides.

Tim Kryger (2):
  mmc: sdhci: Use supplies in common mmc_host struct
  mmc: sdhci: Use common mmc_regulator_get_supply

 drivers/mmc/host/sdhci.c  |   96 +
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 35 insertions(+), 64 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] mmc: sdhci: Use supplies in common mmc_host struct

[Tim Kryger]

Switch the common SDHCI code over to use mmc_host's regulator pointers
and remove the ones in the sdhci_host structure.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/mmc/host/sdhci.c  |   71 -
 include/linux/mmc/sdhci.h |3 --
 2 files changed, 38 insertions(+), 36 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..16fba66 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1429,6 +1429,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
 static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host-mmc;
unsigned long flags;
int vdd_bit = -1;
u8 ctrl;
@@ -1437,8 +1438,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
 
if (host-flags  SDHCI_DEVICE_DEAD) {
spin_unlock_irqrestore(host-lock, flags);
-   if (host-vmmc  ios-power_mode == MMC_POWER_OFF)
-   mmc_regulator_set_ocr(host-mmc, host-vmmc, 0);
+   if (mmc-supply.vmmc  ios-power_mode == MMC_POWER_OFF)
+   mmc_regulator_set_ocr(host-mmc, mmc-supply.vmmc, 0);
return;
}
 
@@ -1463,9 +1464,9 @@ static void sdhci_do_set_ios(struct sdhci_host *host, 
struct mmc_ios *ios)
else
vdd_bit = sdhci_set_power(host, ios-vdd);
 
-   if (host-vmmc  vdd_bit != -1) {
+   if (mmc-supply.vmmc  vdd_bit != -1) {
spin_unlock_irqrestore(host-lock, flags);
-   mmc_regulator_set_ocr(host-mmc, host-vmmc, vdd_bit);
+   mmc_regulator_set_ocr(host-mmc, mmc-supply.vmmc, vdd_bit);
spin_lock_irqsave(host-lock, flags);
}
 
@@ -1742,6 +1743,7 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, 
int enable)
 static int sdhci_do_start_signal_voltage_switch(struct sdhci_host *host,
struct mmc_ios *ios)
 {
+   struct mmc_host *mmc = host-mmc;
u16 ctrl;
int ret;
 
@@ -1760,8 +1762,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
ctrl = ~SDHCI_CTRL_VDD_180;
sdhci_writew(host, ctrl, SDHCI_HOST_CONTROL2);
 
-   if (host-vqmmc) {
-   ret = regulator_set_voltage(host-vqmmc, 270, 
360);
+   if (mmc-supply.vqmmc) {
+   ret = regulator_set_voltage(mmc-supply.vqmmc, 270,
+   360);
if (ret) {
pr_warning(%s: Switching to 3.3V signalling 
voltage 
 failed\n, 
mmc_hostname(host-mmc));
@@ -1781,8 +1784,8 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_180:
-   if (host-vqmmc) {
-   ret = regulator_set_voltage(host-vqmmc,
+   if (mmc-supply.vqmmc) {
+   ret = regulator_set_voltage(mmc-supply.vqmmc,
170, 195);
if (ret) {
pr_warning(%s: Switching to 1.8V signalling 
voltage 
@@ -1811,8 +1814,9 @@ static int sdhci_do_start_signal_voltage_switch(struct 
sdhci_host *host,
 
return -EAGAIN;
case MMC_SIGNAL_VOLTAGE_120:
-   if (host-vqmmc) {
-   ret = regulator_set_voltage(host-vqmmc, 110, 
130);
+   if (mmc-supply.vqmmc) {
+   ret = regulator_set_voltage(mmc-supply.vqmmc, 110,
+   130);
if (ret) {
pr_warning(%s: Switching to 1.2V signalling 
voltage 
 failed\n, 
mmc_hostname(host-mmc));
@@ -2976,24 +2980,24 @@ int sdhci_add_host(struct sdhci_host *host)
mmc-caps |= MMC_CAP_NEEDS_POLL;
 
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
-   host-vqmmc = regulator_get_optional(mmc_dev(mmc), vqmmc);
-   if (IS_ERR_OR_NULL(host-vqmmc)) {
-   if (PTR_ERR(host-vqmmc)  0) {
+   mmc-supply.vqmmc = regulator_get_optional(mmc_dev(mmc), vqmmc);
+   if (IS_ERR_OR_NULL(mmc-supply.vqmmc)) {
+   if (PTR_ERR(mmc-supply.vqmmc)  0) {
pr_info(%s: no vqmmc regulator found\n,
mmc_hostname(mmc));
-   host-vqmmc = NULL;
+   mmc-supply.vqmmc = NULL;
}
} else {
-   ret = regulator_enable(host-vqmmc);
-   if (!regulator_is_supported_voltage(host-vqmmc, 170

Re: [PATCH 3/4] mmc: sdhci: defer probing on regulator_get_optional() failures

[Tim Kryger]

On Mon, Apr 14, 2014 at 6:42 PM, Andrew Bresticker
 wrote:
> If regulator_get_optional() returns EPROBE_DEFER, it indicates
> that the regulator may show up later (e.g. the DT property is
> present but the corresponding regulator may not have probed).
> Instead of continuing without the regulator, return EPROBE_DEFER
> from sdhci_add_host().  Also, fix regulator leaks in the error
> paths in sdhci_add_host().
>
> Signed-off-by: Andrew Bresticker 
> ---
>  drivers/mmc/host/sdhci.c | 19 ---
>  1 file changed, 16 insertions(+), 3 deletions(-)

This appears to be an improvement on Mike Looijmans patch:

https://lkml.org/lkml/2014/4/7/34

The regulator_put() calls are appropriate but I wonder if we should
take this a step farther.  Ulf is sure to point out that
mmc_regulator_get_supply() can be used to get regulators (though it
does stuff the pointers in host->mmc->supply.vmmc/vqmmc instead of
host->vmmc/vqmmc).  However, that function doesn't put back the
reference to vmmc if the request for vqmmc returns EPROBE_DEFER.  If
it did, it believe it could be used here to simplify the error
handling as all the regulator checks would happen up front.  What do
you think?

-Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

On Fri, Apr 11, 2014 at 1:15 AM, Ulf Hansson  wrote:

> I have seen some patches around lately touching the code for handling
> the regulators (vcc and vccq) in sdhci.

Was it this patch you were thinking of or something else?

http://www.spinics.net/lists/linux-mmc/msg25640.html

> A few times I have suggested to switch to use the
> mmc_regulator_get_supply() API to simplify and consolidate code. Could
> you please have a look at that?

This function will solve my problem but it also suggests that SDHCI
drivers should use the vmmc/vqmmc pointers in the mmc_host struct
rather than the ones in the sdhci_host struct.

Is this your intent?  Do you want to see the regulator pointers in the
sdhci_host struct removed once all drivers are modified to use the
mmc_host ones?

-Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

On Fri, Apr 11, 2014 at 1:15 AM, Ulf Hansson ulf.hans...@linaro.org wrote:

 I have seen some patches around lately touching the code for handling
 the regulators (vcc and vccq) in sdhci.

Was it this patch you were thinking of or something else?

http://www.spinics.net/lists/linux-mmc/msg25640.html

 A few times I have suggested to switch to use the
 mmc_regulator_get_supply() API to simplify and consolidate code. Could
 you please have a look at that?

This function will solve my problem but it also suggests that SDHCI
drivers should use the vmmc/vqmmc pointers in the mmc_host struct
rather than the ones in the sdhci_host struct.

Is this your intent?  Do you want to see the regulator pointers in the
sdhci_host struct removed once all drivers are modified to use the
mmc_host ones?

-Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] mmc: sdhci: defer probing on regulator_get_optional() failures

[Tim Kryger]

On Mon, Apr 14, 2014 at 6:42 PM, Andrew Bresticker
abres...@chromium.org wrote:
 If regulator_get_optional() returns EPROBE_DEFER, it indicates
 that the regulator may show up later (e.g. the DT property is
 present but the corresponding regulator may not have probed).
 Instead of continuing without the regulator, return EPROBE_DEFER
 from sdhci_add_host().  Also, fix regulator leaks in the error
 paths in sdhci_add_host().

 Signed-off-by: Andrew Bresticker abres...@chromium.org
 ---
  drivers/mmc/host/sdhci.c | 19 ---
  1 file changed, 16 insertions(+), 3 deletions(-)

This appears to be an improvement on Mike Looijmans patch:

https://lkml.org/lkml/2014/4/7/34

The regulator_put() calls are appropriate but I wonder if we should
take this a step farther.  Ulf is sure to point out that
mmc_regulator_get_supply() can be used to get regulators (though it
does stuff the pointers in host-mmc-supply.vmmc/vqmmc instead of
host-vmmc/vqmmc).  However, that function doesn't put back the
reference to vmmc if the request for vqmmc returns EPROBE_DEFER.  If
it did, it believe it could be used here to simplify the error
handling as all the regulator checks would happen up front.  What do
you think?

-Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

On Fri, Apr 11, 2014 at 1:15 AM, Ulf Hansson  wrote:
> On 11 April 2014 01:31, Tim Kryger  wrote:

>> +static unsigned int sdhci_get_ocr_avail_from_vmmc(struct sdhci_host *host)
>> +{
>> +   unsigned int ocr_avail = 0;
>> +   struct regulator *vmmc = host->vmmc;
>> +
>> +   if (regulator_is_supported_voltage(vmmc, 165, 195) > 0)
>> +   ocr_avail |= MMC_VDD_165_195;
>> +
>> +   if (regulator_is_supported_voltage(vmmc, 290, 300) > 0)
>> +   ocr_avail |= MMC_VDD_29_30;
>> +
>> +   if (regulator_is_supported_voltage(vmmc, 300, 310) > 0)
>> +   ocr_avail |= MMC_VDD_30_31;
>> +
>> +   if (regulator_is_supported_voltage(vmmc, 320, 330) > 0)
>> +   ocr_avail |= MMC_VDD_32_33;
>> +
>> +   if (regulator_is_supported_voltage(vmmc, 330, 340) > 0)
>> +   ocr_avail |= MMC_VDD_33_34;
>> +
>> +   return ocr_avail;
>> +}
>> +
>
> There is an API called mmc_regulator_get_ocrmask() for this.

Great.  Thanks for pointing this out.


>> +   ocr_avail = sdhci_get_ocr_avail_from_vmmc(host);
>> +   } else {
>> +   if (caps[0] & SDHCI_CAN_VDD_330)
>> +   ocr_avail |= MMC_VDD_32_33 | MMC_VDD_33_34;
>> +   if (caps[0] & SDHCI_CAN_VDD_300)
>> +   ocr_avail |= MMC_VDD_29_30 | MMC_VDD_30_31;
>> +   if (caps[0] & SDHCI_CAN_VDD_180)
>> +   ocr_avail |= MMC_VDD_165_195;
>> +   }
>> +
>> +   if (host->ocr_mask)
>> +   ocr_avail = host->ocr_mask;
>> +
>> +   mmc->ocr_avail = ocr_avail;
>> +   mmc->ocr_avail_sdio = ocr_avail;
>> +   if (host->ocr_avail_sdio)
>> +   mmc->ocr_avail_sdio &= host->ocr_avail_sdio;
>> +   mmc->ocr_avail_sd = ocr_avail;
>> +   if (host->ocr_avail_sd)
>> +   mmc->ocr_avail_sd &= host->ocr_avail_sd;
>> +   else /* normal SD controllers don't support 1.8V */
>> +   mmc->ocr_avail_sd &= ~MMC_VDD_165_195;
>> +   mmc->ocr_avail_mmc = ocr_avail;
>> +   if (host->ocr_avail_mmc)
>> +   mmc->ocr_avail_mmc &= host->ocr_avail_mmc;
>> +
>> +   if (mmc->ocr_avail == 0) {
>> +   pr_err("%s: Hardware doesn't report any support voltages.\n",
>> +  mmc_hostname(mmc));
>> +   return -ENODEV;
>> +   }
>
> I have not fully understand why you have different ocr masks depending
> on what card you initialize. Is that really supported by the
> controller?

Would you mind clarifying your question?  I'm not sure what you are
after.  Also this logic is mostly unchanged, I have simply moved it up
earlier in the function to keep all the ocr parts together.

> I have seen some patches around lately touching the code for handling
> the regulators (vcc and vccq) in sdhci.
>
> A few times I have suggested to switch to use the
> mmc_regulator_get_supply() API to simplify and consolidate code. Could
> you please have a look at that?

Sure, I'll take a look.  Thanks for the helpful comments.

-Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

On Fri, Apr 11, 2014 at 1:15 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 11 April 2014 01:31, Tim Kryger tim.kry...@linaro.org wrote:

 +static unsigned int sdhci_get_ocr_avail_from_vmmc(struct sdhci_host *host)
 +{
 +   unsigned int ocr_avail = 0;
 +   struct regulator *vmmc = host-vmmc;
 +
 +   if (regulator_is_supported_voltage(vmmc, 165, 195)  0)
 +   ocr_avail |= MMC_VDD_165_195;
 +
 +   if (regulator_is_supported_voltage(vmmc, 290, 300)  0)
 +   ocr_avail |= MMC_VDD_29_30;
 +
 +   if (regulator_is_supported_voltage(vmmc, 300, 310)  0)
 +   ocr_avail |= MMC_VDD_30_31;
 +
 +   if (regulator_is_supported_voltage(vmmc, 320, 330)  0)
 +   ocr_avail |= MMC_VDD_32_33;
 +
 +   if (regulator_is_supported_voltage(vmmc, 330, 340)  0)
 +   ocr_avail |= MMC_VDD_33_34;
 +
 +   return ocr_avail;
 +}
 +

 There is an API called mmc_regulator_get_ocrmask() for this.

Great.  Thanks for pointing this out.


 +   ocr_avail = sdhci_get_ocr_avail_from_vmmc(host);
 +   } else {
 +   if (caps[0]  SDHCI_CAN_VDD_330)
 +   ocr_avail |= MMC_VDD_32_33 | MMC_VDD_33_34;
 +   if (caps[0]  SDHCI_CAN_VDD_300)
 +   ocr_avail |= MMC_VDD_29_30 | MMC_VDD_30_31;
 +   if (caps[0]  SDHCI_CAN_VDD_180)
 +   ocr_avail |= MMC_VDD_165_195;
 +   }
 +
 +   if (host-ocr_mask)
 +   ocr_avail = host-ocr_mask;
 +
 +   mmc-ocr_avail = ocr_avail;
 +   mmc-ocr_avail_sdio = ocr_avail;
 +   if (host-ocr_avail_sdio)
 +   mmc-ocr_avail_sdio = host-ocr_avail_sdio;
 +   mmc-ocr_avail_sd = ocr_avail;
 +   if (host-ocr_avail_sd)
 +   mmc-ocr_avail_sd = host-ocr_avail_sd;
 +   else /* normal SD controllers don't support 1.8V */
 +   mmc-ocr_avail_sd = ~MMC_VDD_165_195;
 +   mmc-ocr_avail_mmc = ocr_avail;
 +   if (host-ocr_avail_mmc)
 +   mmc-ocr_avail_mmc = host-ocr_avail_mmc;
 +
 +   if (mmc-ocr_avail == 0) {
 +   pr_err(%s: Hardware doesn't report any support voltages.\n,
 +  mmc_hostname(mmc));
 +   return -ENODEV;
 +   }

 I have not fully understand why you have different ocr masks depending
 on what card you initialize. Is that really supported by the
 controller?

Would you mind clarifying your question?  I'm not sure what you are
after.  Also this logic is mostly unchanged, I have simply moved it up
earlier in the function to keep all the ocr parts together.

 I have seen some patches around lately touching the code for handling
 the regulators (vcc and vccq) in sdhci.

 A few times I have suggested to switch to use the
 mmc_regulator_get_supply() API to simplify and consolidate code. Could
 you please have a look at that?

Sure, I'll take a look.  Thanks for the helpful comments.

-Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] gpio: bcm-kona: Add irq_set_wake method

[Tim Kryger]

If a consumer of a GPIO-based IRQ identifies itself as wanting to
have the capability to wake up the system through that interrupt,
update the flags to keep that interrupt enabled in suspend.

Signed-off-by: Tim Kryger 
---
 drivers/gpio/gpio-bcm-kona.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index 3f6b33c..b0e0971 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define BCM_GPIO_PASSWD0x00a5a501
 #define GPIO_PER_BANK  32
@@ -340,6 +341,23 @@ static void bcm_kona_gpio_irq_ack(struct irq_data *d)
spin_unlock_irqrestore(_gpio->lock, flags);
 }
 
+#ifdef CONFIG_SUSPEND
+static int bcm_kona_gpio_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+
+   struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+
+   if (on)
+   desc->action->flags |= IRQF_NO_SUSPEND;
+   else
+   desc->action->flags &= ~IRQF_NO_SUSPEND;
+
+   return 0;
+}
+#else
+#define bcm_kona_gpio_irq_set_wake NULL
+#endif
+
 static void bcm_kona_gpio_irq_mask(struct irq_data *d)
 {
struct bcm_kona_gpio *kona_gpio;
@@ -494,6 +512,7 @@ static struct irq_chip bcm_gpio_irq_chip = {
.irq_set_type = bcm_kona_gpio_irq_set_type,
.irq_request_resources = bcm_kona_gpio_irq_reqres,
.irq_release_resources = bcm_kona_gpio_irq_relres,
+   .irq_set_wake = bcm_kona_gpio_irq_set_wake,
 };
 
 static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

When an external regulator provides VDD, set ocr_avail directly based on
the supported voltage range.  This allows for the use of regulators that
can't provide exactly 1.8v, 3.0v, or 3.3v and ensures that ocr_avil bits
are only set for supported voltage ranges.  Commit cec2e21 had attempted
to relax the range checks but because it relied on setting capabilities
as an intermediate step, ocr_avail could easily get a bit set that the
host couldn't support.

Signed-off-by: Tim Kryger 
---
 drivers/mmc/host/sdhci.c |  107 +-
 1 file changed, 58 insertions(+), 49 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..4d56fbe 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2769,6 +2769,29 @@ struct sdhci_host *sdhci_alloc_host(struct device *dev,
 
 EXPORT_SYMBOL_GPL(sdhci_alloc_host);
 
+static unsigned int sdhci_get_ocr_avail_from_vmmc(struct sdhci_host *host)
+{
+   unsigned int ocr_avail = 0;
+   struct regulator *vmmc = host->vmmc;
+
+   if (regulator_is_supported_voltage(vmmc, 165, 195) > 0)
+   ocr_avail |= MMC_VDD_165_195;
+
+   if (regulator_is_supported_voltage(vmmc, 290, 300) > 0)
+   ocr_avail |= MMC_VDD_29_30;
+
+   if (regulator_is_supported_voltage(vmmc, 300, 310) > 0)
+   ocr_avail |= MMC_VDD_30_31;
+
+   if (regulator_is_supported_voltage(vmmc, 320, 330) > 0)
+   ocr_avail |= MMC_VDD_32_33;
+
+   if (regulator_is_supported_voltage(vmmc, 330, 340) > 0)
+   ocr_avail |= MMC_VDD_33_34;
+
+   return ocr_avail;
+}
+
 int sdhci_add_host(struct sdhci_host *host)
 {
struct mmc_host *mmc;
@@ -3063,24 +3086,39 @@ int sdhci_add_host(struct sdhci_host *host)
}
}
 
-#ifdef CONFIG_REGULATOR
-   /*
-* Voltage range check makes sense only if regulator reports
-* any voltage value.
-*/
+   /* If using external regulator, check supported voltage ranges */
if (host->vmmc && regulator_get_voltage(host->vmmc) > 0) {
-   ret = regulator_is_supported_voltage(host->vmmc, 270,
-   360);
-   if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330)))
-   caps[0] &= ~SDHCI_CAN_VDD_330;
-   if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_300)))
-   caps[0] &= ~SDHCI_CAN_VDD_300;
-   ret = regulator_is_supported_voltage(host->vmmc, 170,
-   195);
-   if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_180)))
-   caps[0] &= ~SDHCI_CAN_VDD_180;
-   }
-#endif /* CONFIG_REGULATOR */
+   ocr_avail = sdhci_get_ocr_avail_from_vmmc(host);
+   } else {
+   if (caps[0] & SDHCI_CAN_VDD_330)
+   ocr_avail |= MMC_VDD_32_33 | MMC_VDD_33_34;
+   if (caps[0] & SDHCI_CAN_VDD_300)
+   ocr_avail |= MMC_VDD_29_30 | MMC_VDD_30_31;
+   if (caps[0] & SDHCI_CAN_VDD_180)
+   ocr_avail |= MMC_VDD_165_195;
+   }
+
+   if (host->ocr_mask)
+   ocr_avail = host->ocr_mask;
+
+   mmc->ocr_avail = ocr_avail;
+   mmc->ocr_avail_sdio = ocr_avail;
+   if (host->ocr_avail_sdio)
+   mmc->ocr_avail_sdio &= host->ocr_avail_sdio;
+   mmc->ocr_avail_sd = ocr_avail;
+   if (host->ocr_avail_sd)
+   mmc->ocr_avail_sd &= host->ocr_avail_sd;
+   else /* normal SD controllers don't support 1.8V */
+   mmc->ocr_avail_sd &= ~MMC_VDD_165_195;
+   mmc->ocr_avail_mmc = ocr_avail;
+   if (host->ocr_avail_mmc)
+   mmc->ocr_avail_mmc &= host->ocr_avail_mmc;
+
+   if (mmc->ocr_avail == 0) {
+   pr_err("%s: Hardware doesn't report any support voltages.\n",
+  mmc_hostname(mmc));
+   return -ENODEV;
+   }
 
/*
 * According to SD Host Controller spec v3.00, if the Host System
@@ -3106,52 +3144,23 @@ int sdhci_add_host(struct sdhci_host *host)
}
}
 
-   if (caps[0] & SDHCI_CAN_VDD_330) {
-   ocr_avail |= MMC_VDD_32_33 | MMC_VDD_33_34;
-
+   if (ocr_avail & (MMC_VDD_32_33 | MMC_VDD_33_34))
mmc->max_current_330 = ((max_current_caps &
   SDHCI_MAX_CURRENT_330_MASK) >>
   SDHCI_MAX_CURRENT_330_SHIFT) *
   SDHCI_MAX_CURRENT_MULTIPLIER;
-   }
-   if (caps[0] & SDHCI_CAN_VDD_300) {
-   ocr_avail |= MMC_VDD_29_30 | MMC_VDD_30_31;
 
+   if (ocr_avail & (MMC_VDD_29_30 | MMC_VDD_30_3

[PATCH] regulator: bcm590xx: Set n_voltages for linear reg

[Tim Kryger]

Fix the macro used to define linear range regulators to include the
number of voltages.

Signed-off-by: Tim Kryger 
---
 drivers/regulator/bcm590xx-regulator.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/bcm590xx-regulator.c 
b/drivers/regulator/bcm590xx-regulator.c
index ab08ca7..c3750c5 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -123,6 +123,7 @@ struct bcm590xx_info {
 #define BCM590XX_REG_RANGES(_name, _ranges) \
{ \
.name = #_name, \
+   .n_voltages = 64, \
.n_linear_ranges = ARRAY_SIZE(_ranges), \
.linear_ranges = _ranges, \
}
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: bcm590xx: Set n_voltages for linear reg

[Tim Kryger]

Fix the macro used to define linear range regulators to include the
number of voltages.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/regulator/bcm590xx-regulator.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/bcm590xx-regulator.c 
b/drivers/regulator/bcm590xx-regulator.c
index ab08ca7..c3750c5 100644
--- a/drivers/regulator/bcm590xx-regulator.c
+++ b/drivers/regulator/bcm590xx-regulator.c
@@ -123,6 +123,7 @@ struct bcm590xx_info {
 #define BCM590XX_REG_RANGES(_name, _ranges) \
{ \
.name = #_name, \
+   .n_voltages = 64, \
.n_linear_ranges = ARRAY_SIZE(_ranges), \
.linear_ranges = _ranges, \
}
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mmc: sdhci: Set ocr_avail directly based on vmmc

[Tim Kryger]

When an external regulator provides VDD, set ocr_avail directly based on
the supported voltage range.  This allows for the use of regulators that
can't provide exactly 1.8v, 3.0v, or 3.3v and ensures that ocr_avil bits
are only set for supported voltage ranges.  Commit cec2e21 had attempted
to relax the range checks but because it relied on setting capabilities
as an intermediate step, ocr_avail could easily get a bit set that the
host couldn't support.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/mmc/host/sdhci.c |  107 +-
 1 file changed, 58 insertions(+), 49 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9a79fc4..4d56fbe 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2769,6 +2769,29 @@ struct sdhci_host *sdhci_alloc_host(struct device *dev,
 
 EXPORT_SYMBOL_GPL(sdhci_alloc_host);
 
+static unsigned int sdhci_get_ocr_avail_from_vmmc(struct sdhci_host *host)
+{
+   unsigned int ocr_avail = 0;
+   struct regulator *vmmc = host-vmmc;
+
+   if (regulator_is_supported_voltage(vmmc, 165, 195)  0)
+   ocr_avail |= MMC_VDD_165_195;
+
+   if (regulator_is_supported_voltage(vmmc, 290, 300)  0)
+   ocr_avail |= MMC_VDD_29_30;
+
+   if (regulator_is_supported_voltage(vmmc, 300, 310)  0)
+   ocr_avail |= MMC_VDD_30_31;
+
+   if (regulator_is_supported_voltage(vmmc, 320, 330)  0)
+   ocr_avail |= MMC_VDD_32_33;
+
+   if (regulator_is_supported_voltage(vmmc, 330, 340)  0)
+   ocr_avail |= MMC_VDD_33_34;
+
+   return ocr_avail;
+}
+
 int sdhci_add_host(struct sdhci_host *host)
 {
struct mmc_host *mmc;
@@ -3063,24 +3086,39 @@ int sdhci_add_host(struct sdhci_host *host)
}
}
 
-#ifdef CONFIG_REGULATOR
-   /*
-* Voltage range check makes sense only if regulator reports
-* any voltage value.
-*/
+   /* If using external regulator, check supported voltage ranges */
if (host-vmmc  regulator_get_voltage(host-vmmc)  0) {
-   ret = regulator_is_supported_voltage(host-vmmc, 270,
-   360);
-   if ((ret = 0) || (!(caps[0]  SDHCI_CAN_VDD_330)))
-   caps[0] = ~SDHCI_CAN_VDD_330;
-   if ((ret = 0) || (!(caps[0]  SDHCI_CAN_VDD_300)))
-   caps[0] = ~SDHCI_CAN_VDD_300;
-   ret = regulator_is_supported_voltage(host-vmmc, 170,
-   195);
-   if ((ret = 0) || (!(caps[0]  SDHCI_CAN_VDD_180)))
-   caps[0] = ~SDHCI_CAN_VDD_180;
-   }
-#endif /* CONFIG_REGULATOR */
+   ocr_avail = sdhci_get_ocr_avail_from_vmmc(host);
+   } else {
+   if (caps[0]  SDHCI_CAN_VDD_330)
+   ocr_avail |= MMC_VDD_32_33 | MMC_VDD_33_34;
+   if (caps[0]  SDHCI_CAN_VDD_300)
+   ocr_avail |= MMC_VDD_29_30 | MMC_VDD_30_31;
+   if (caps[0]  SDHCI_CAN_VDD_180)
+   ocr_avail |= MMC_VDD_165_195;
+   }
+
+   if (host-ocr_mask)
+   ocr_avail = host-ocr_mask;
+
+   mmc-ocr_avail = ocr_avail;
+   mmc-ocr_avail_sdio = ocr_avail;
+   if (host-ocr_avail_sdio)
+   mmc-ocr_avail_sdio = host-ocr_avail_sdio;
+   mmc-ocr_avail_sd = ocr_avail;
+   if (host-ocr_avail_sd)
+   mmc-ocr_avail_sd = host-ocr_avail_sd;
+   else /* normal SD controllers don't support 1.8V */
+   mmc-ocr_avail_sd = ~MMC_VDD_165_195;
+   mmc-ocr_avail_mmc = ocr_avail;
+   if (host-ocr_avail_mmc)
+   mmc-ocr_avail_mmc = host-ocr_avail_mmc;
+
+   if (mmc-ocr_avail == 0) {
+   pr_err(%s: Hardware doesn't report any support voltages.\n,
+  mmc_hostname(mmc));
+   return -ENODEV;
+   }
 
/*
 * According to SD Host Controller spec v3.00, if the Host System
@@ -3106,52 +3144,23 @@ int sdhci_add_host(struct sdhci_host *host)
}
}
 
-   if (caps[0]  SDHCI_CAN_VDD_330) {
-   ocr_avail |= MMC_VDD_32_33 | MMC_VDD_33_34;
-
+   if (ocr_avail  (MMC_VDD_32_33 | MMC_VDD_33_34))
mmc-max_current_330 = ((max_current_caps 
   SDHCI_MAX_CURRENT_330_MASK) 
   SDHCI_MAX_CURRENT_330_SHIFT) *
   SDHCI_MAX_CURRENT_MULTIPLIER;
-   }
-   if (caps[0]  SDHCI_CAN_VDD_300) {
-   ocr_avail |= MMC_VDD_29_30 | MMC_VDD_30_31;
 
+   if (ocr_avail  (MMC_VDD_29_30 | MMC_VDD_30_31))
mmc-max_current_300 = ((max_current_caps 
   SDHCI_MAX_CURRENT_300_MASK) 
   SDHCI_MAX_CURRENT_300_SHIFT

[PATCH] gpio: bcm-kona: Add irq_set_wake method

[Tim Kryger]

If a consumer of a GPIO-based IRQ identifies itself as wanting to
have the capability to wake up the system through that interrupt,
update the flags to keep that interrupt enabled in suspend.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
---
 drivers/gpio/gpio-bcm-kona.c |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpio/gpio-bcm-kona.c b/drivers/gpio/gpio-bcm-kona.c
index 3f6b33c..b0e0971 100644
--- a/drivers/gpio/gpio-bcm-kona.c
+++ b/drivers/gpio/gpio-bcm-kona.c
@@ -20,6 +20,7 @@
 #include linux/module.h
 #include linux/irqdomain.h
 #include linux/irqchip/chained_irq.h
+#include linux/interrupt.h
 
 #define BCM_GPIO_PASSWD0x00a5a501
 #define GPIO_PER_BANK  32
@@ -340,6 +341,23 @@ static void bcm_kona_gpio_irq_ack(struct irq_data *d)
spin_unlock_irqrestore(kona_gpio-lock, flags);
 }
 
+#ifdef CONFIG_SUSPEND
+static int bcm_kona_gpio_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+
+   struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+
+   if (on)
+   desc-action-flags |= IRQF_NO_SUSPEND;
+   else
+   desc-action-flags = ~IRQF_NO_SUSPEND;
+
+   return 0;
+}
+#else
+#define bcm_kona_gpio_irq_set_wake NULL
+#endif
+
 static void bcm_kona_gpio_irq_mask(struct irq_data *d)
 {
struct bcm_kona_gpio *kona_gpio;
@@ -494,6 +512,7 @@ static struct irq_chip bcm_gpio_irq_chip = {
.irq_set_type = bcm_kona_gpio_irq_set_type,
.irq_request_resources = bcm_kona_gpio_irq_reqres,
.irq_release_resources = bcm_kona_gpio_irq_relres,
+   .irq_set_wake = bcm_kona_gpio_irq_set_wake,
 };
 
 static struct __initconst of_device_id bcm_kona_gpio_of_match[] = {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

This series introduces the driver for the Kona PWM controller found in
Broadcom mobile SoCs like bcm281xx and updates the device tree and the
defconfig to enable use of this hardware on the bcm28155 AP board.

Changes since v4:
  - Added in real polarity support
  - Labeled trigger bits as such rather than use the name from hw docs
  - Listed unsual hardware characteristics at the top of the file
  - Removed default from Kconfig and update defconfig accordingly
  - Always use unsigned int for temporary register values

Changes since v3:
  - Removed polarity support for now
  - Cleaned up whitespace issues, shortened some variable names
  - Use container_of instead of dev_get_drvdata to get private data
  - Removed workaround for PWM framework bug
  - Reworded some binding documentation

Changes since v2:
  - SoC DTS file updated to use real clock's phandle + specifier
  - Toggle smooth mode off during apply so new settings take immediately

Changes since v1:
  - Fixed up macros to be clearer and more complete
  - Corrected spelling and punctuation mistakes
  - Added support for polarity
  - Made peripheral clock use more efficient
  - Made prescale and duty computation clearer
  - Moved Makefile addition to keep alphabetical
  - Split complex lines into multiple steps

Dependencies:
The "ARM: dts: Declare the PWM for bcm11351 (bcm281xx)" patch depends
upon "ARM: dts: bcm281xx: define real clocks" which is queued up in
for-next of arm-soc. See https://lkml.org/lkml/2014/2/14/451

Tim Kryger (5):
  Documentation: dt: Add Kona PWM binding
  pwm: kona: Introduce Kona PWM controller support
  ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
  ARM: dts: Enable the PWM for bcm28155 AP board
  ARM: bcm_defconfig: Enable PWM and Backlight

 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 ++
 arch/arm/boot/dts/bcm11351.dtsi|8 +
 arch/arm/boot/dts/bcm28155-ap.dts  |4 +
 arch/arm/configs/bcm_defconfig |3 +
 drivers/pwm/Kconfig|9 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 7 files changed, 365 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 3/5] ARM: dts: Declare the PWM for bcm11351 (bcm281xx)

[Tim Kryger]

Add the device tree node for the PWM on bcm11351 SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm11351.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 64d069b..6b05ae6 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -193,6 +193,14 @@
status = "disabled";
};
 
+   pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xcc>;
+   clocks = <_ccu BCM281XX_SLAVE_CCU_PWM>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
clocks {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

Add the binding description for the Kona PWM controller found on Broadcom's
mobile SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000..8eae9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+
+This controller has 6 channels.
+
+Required Properties :
+- compatible: should contain "brcm,kona-pwm"
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+
+Example:
+
+pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xc4>;
+   clocks = <_clk>;
+   #pwm-cells = <3>;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 4/5] ARM: dts: Enable the PWM for bcm28155 AP board

[Tim Kryger]

Mark the PWM as enabled on the bcm28155 AP board.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm28155-ap.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
b/arch/arm/boot/dts/bcm28155-ap.dts
index 5ff2382..37c72eb 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -66,6 +66,10 @@
status = "okay";
};
 
+   pwm: pwm@3e01a000 {
+   status = "okay";
+   };
+
usbotg: usb@3f12 {
status = "okay";
};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 5/5] ARM: bcm_defconfig: Enable PWM and Backlight

[Tim Kryger]

Enable PWM drivers and the PWM-based backlight driver.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/configs/bcm_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 3b2b7bd..593df57 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -88,6 +88,7 @@ CONFIG_FB=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
@@ -101,6 +102,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_PWM=y
+CONFIG_PWM_BCM_KONA=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

Add support for the six-channel Kona PWM controller found on Broadcom
mobile SoCs like bcm281xx.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 drivers/pwm/Kconfig|9 ++
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 22f2f28..777d87dd 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,15 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.
 
+config PWM_BCM_KONA
+   tristate "Kona PWM support"
+   depends on ARCH_BCM_MOBILE
+   help
+ Generic PWM framework driver for Broadcom Kona PWM block.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm-kona.
+
 config PWM_BFIN
tristate "Blackfin PWM support"
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index d8906ec..7413090 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_IMX)  += pwm-imx.o
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
new file mode 100644
index 000..ee8a59d
--- /dev/null
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * The Kona PWM has some unusual characteristics.  Here are the main points.
+ *
+ * 1) There is no disable bit and the hardware docs advise programming a zero
+ *duty to achieve output equivalent to that of a normal disable operation.
+ *
+ * 2) Changes to prescale, duty, period, and polarity do not take effect until
+ *a subsequent rising edge of the trigger bit.
+ *
+ * 3) If the smooth bit and trigger bit are both low, the output is a constant
+ *high signal.  Otherwise, the earlier waveform continues to be output.
+ *
+ * 4) If the smooth bit is set on the rising edge of the trigger bit, output
+ *will transition to the new settings on a period boundary (which could be
+ *seconds away).  If the smooth bit is clear, new settings will be applied
+ *as soon as possible (the hardware always has a 400ns delay).
+ *
+ * 5) When the external clock that feeds the PWM is disabled, output is pegged
+ *high or low depending on its state at that exact instant.
+ */
+
+#define PWM_CONTROL_OFFSET (0x)
+#define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan))
+#define PWM_CONTROL_TYPE_SHIFT(chan)   (16 + (chan))
+#define PWM_CONTROL_POLARITY_SHIFT(chan)   (8 + (chan))
+#define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan)
+
+#define PRESCALE_OFFSET(0x0004)
+#define PRESCALE_SHIFT(chan)   ((chan) << 2)
+#define PRESCALE_MASK(chan)(0x7 << PRESCALE_SHIFT(chan))
+#define PRESCALE_MIN   (0x)
+#define PRESCALE_MAX   (0x0007)
+
+#define PERIOD_COUNT_OFFSET(chan)  (0x0008 + ((chan) << 3))
+#define PERIOD_COUNT_MIN   (0x0002)
+#define PERIOD_COUNT_MAX   (0x00ff)
+
+#define DUTY_CYCLE_HIGH_OFFSET(chan)   (0x000c + ((chan) << 3))
+#define DUTY_CYCLE_HIGH_MIN(0x)
+#define DUTY_CYCLE_HIGH_MAX(0x00ff)
+
+struct kona_pwmc {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip)
+{
+   return container_of(_chip, struct kona_pwmc, chip);
+}
+
+static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
+{
+   unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
+
+   /* Clear trigger bit b

Re: [rfc]pwm: add BCM2835 PWM driver

[Tim Kryger]

On Tue, Apr 8, 2014 at 6:27 PM, Stephen Warren  wrote:
> On 04/08/2014 05:02 PM, Tim Kryger wrote:
>> On Thu, Apr 3, 2014 at 6:44 AM, Bart Tanghe  
>> wrote:
>>> need some recommendation
>>> the memory mapped io registers of the bcm2835 pwm hardware are spreaded
>>> over the memory mapped io
>>> gpio config 0x2024 - clk config 0x201010A0 - pwm configuration 
>>> 0x2020C000
>>> to handle this, I've used the base address of the memory mapped io
>>> so I can use positive offsets
>>
>> So the registers for this PWM are located in three distinct memory regions?
> ...
>>> +struct bcm2835_pwm_chip {
>>> +   struct pwm_chip chip;
>>> +   struct device *dev;
>>> +   int channel;
>>> +   void __iomem *mmio;
>>
>> One pointer isn't going to be enough.  You need three.
>>
>> I suggest renaming the first and adding two more:
>>
>> void __iomem *base_pwm;
>> void __iomem *base_clk;
>> void __iomem *base_alt;
>
> Sorry, I forgot about this patch. One comment here; the PWM driver can't
> touch the clock or alt registers; those should be owned by the clock
> driver, and the driver for whatever alt is (pinmux - don't recall what
> it's touching there).

Absolutely.  If these registers are owned by other drivers, go through them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rfc]pwm: add BCM2835 PWM driver

[Tim Kryger]

On Tue, Apr 8, 2014 at 6:27 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 04/08/2014 05:02 PM, Tim Kryger wrote:
 On Thu, Apr 3, 2014 at 6:44 AM, Bart Tanghe bart.tan...@thomasmore.be 
 wrote:
 need some recommendation
 the memory mapped io registers of the bcm2835 pwm hardware are spreaded
 over the memory mapped io
 gpio config 0x2024 - clk config 0x201010A0 - pwm configuration 
 0x2020C000
 to handle this, I've used the base address of the memory mapped io
 so I can use positive offsets

 So the registers for this PWM are located in three distinct memory regions?
 ...
 +struct bcm2835_pwm_chip {
 +   struct pwm_chip chip;
 +   struct device *dev;
 +   int channel;
 +   void __iomem *mmio;

 One pointer isn't going to be enough.  You need three.

 I suggest renaming the first and adding two more:

 void __iomem *base_pwm;
 void __iomem *base_clk;
 void __iomem *base_alt;

 Sorry, I forgot about this patch. One comment here; the PWM driver can't
 touch the clock or alt registers; those should be owned by the clock
 driver, and the driver for whatever alt is (pinmux - don't recall what
 it's touching there).

Absolutely.  If these registers are owned by other drivers, go through them.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 2/5] pwm: kona: Introduce Kona PWM controller support

[Tim Kryger]

Add support for the six-channel Kona PWM controller found on Broadcom
mobile SoCs like bcm281xx.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 drivers/pwm/Kconfig|9 ++
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 3 files changed, 329 insertions(+)
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 22f2f28..777d87dd 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,15 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.
 
+config PWM_BCM_KONA
+   tristate Kona PWM support
+   depends on ARCH_BCM_MOBILE
+   help
+ Generic PWM framework driver for Broadcom Kona PWM block.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm-kona.
+
 config PWM_BFIN
tristate Blackfin PWM support
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index d8906ec..7413090 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM_KONA) += pwm-bcm-kona.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_IMX)  += pwm-imx.o
diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
new file mode 100644
index 000..ee8a59d
--- /dev/null
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -0,0 +1,319 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/math64.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pwm.h
+#include linux/slab.h
+#include linux/types.h
+
+/*
+ * The Kona PWM has some unusual characteristics.  Here are the main points.
+ *
+ * 1) There is no disable bit and the hardware docs advise programming a zero
+ *duty to achieve output equivalent to that of a normal disable operation.
+ *
+ * 2) Changes to prescale, duty, period, and polarity do not take effect until
+ *a subsequent rising edge of the trigger bit.
+ *
+ * 3) If the smooth bit and trigger bit are both low, the output is a constant
+ *high signal.  Otherwise, the earlier waveform continues to be output.
+ *
+ * 4) If the smooth bit is set on the rising edge of the trigger bit, output
+ *will transition to the new settings on a period boundary (which could be
+ *seconds away).  If the smooth bit is clear, new settings will be applied
+ *as soon as possible (the hardware always has a 400ns delay).
+ *
+ * 5) When the external clock that feeds the PWM is disabled, output is pegged
+ *high or low depending on its state at that exact instant.
+ */
+
+#define PWM_CONTROL_OFFSET (0x)
+#define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan))
+#define PWM_CONTROL_TYPE_SHIFT(chan)   (16 + (chan))
+#define PWM_CONTROL_POLARITY_SHIFT(chan)   (8 + (chan))
+#define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan)
+
+#define PRESCALE_OFFSET(0x0004)
+#define PRESCALE_SHIFT(chan)   ((chan)  2)
+#define PRESCALE_MASK(chan)(0x7  PRESCALE_SHIFT(chan))
+#define PRESCALE_MIN   (0x)
+#define PRESCALE_MAX   (0x0007)
+
+#define PERIOD_COUNT_OFFSET(chan)  (0x0008 + ((chan)  3))
+#define PERIOD_COUNT_MIN   (0x0002)
+#define PERIOD_COUNT_MAX   (0x00ff)
+
+#define DUTY_CYCLE_HIGH_OFFSET(chan)   (0x000c + ((chan)  3))
+#define DUTY_CYCLE_HIGH_MIN(0x)
+#define DUTY_CYCLE_HIGH_MAX(0x00ff)
+
+struct kona_pwmc {
+   struct pwm_chip chip;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip)
+{
+   return container_of(_chip, struct kona_pwmc, chip);
+}
+
+static void kona_pwmc_apply_settings

[RESEND PATCH v5 5/5] ARM: bcm_defconfig: Enable PWM and Backlight

[Tim Kryger]

Enable PWM drivers and the PWM-based backlight driver.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/configs/bcm_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 3b2b7bd..593df57 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -88,6 +88,7 @@ CONFIG_FB=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
@@ -101,6 +102,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_PWM=y
+CONFIG_PWM_BCM_KONA=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 4/5] ARM: dts: Enable the PWM for bcm28155 AP board

[Tim Kryger]

Mark the PWM as enabled on the bcm28155 AP board.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/boot/dts/bcm28155-ap.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
b/arch/arm/boot/dts/bcm28155-ap.dts
index 5ff2382..37c72eb 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -66,6 +66,10 @@
status = okay;
};
 
+   pwm: pwm@3e01a000 {
+   status = okay;
+   };
+
usbotg: usb@3f12 {
status = okay;
};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

Add the binding description for the Kona PWM controller found on Broadcom's
mobile SoCs.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000..8eae9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+
+This controller has 6 channels.
+
+Required Properties :
+- compatible: should contain brcm,kona-pwm
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+
+Example:
+
+pwm: pwm@3e01a000 {
+   compatible = brcm,bcm11351-pwm, brcm,kona-pwm;
+   reg = 0x3e01a000 0xc4;
+   clocks = pwm_clk;
+   #pwm-cells = 3;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 0/5] Add Broadcom Kona PWM Support

[Tim Kryger]

This series introduces the driver for the Kona PWM controller found in
Broadcom mobile SoCs like bcm281xx and updates the device tree and the
defconfig to enable use of this hardware on the bcm28155 AP board.

Changes since v4:
  - Added in real polarity support
  - Labeled trigger bits as such rather than use the name from hw docs
  - Listed unsual hardware characteristics at the top of the file
  - Removed default from Kconfig and update defconfig accordingly
  - Always use unsigned int for temporary register values

Changes since v3:
  - Removed polarity support for now
  - Cleaned up whitespace issues, shortened some variable names
  - Use container_of instead of dev_get_drvdata to get private data
  - Removed workaround for PWM framework bug
  - Reworded some binding documentation

Changes since v2:
  - SoC DTS file updated to use real clock's phandle + specifier
  - Toggle smooth mode off during apply so new settings take immediately

Changes since v1:
  - Fixed up macros to be clearer and more complete
  - Corrected spelling and punctuation mistakes
  - Added support for polarity
  - Made peripheral clock use more efficient
  - Made prescale and duty computation clearer
  - Moved Makefile addition to keep alphabetical
  - Split complex lines into multiple steps

Dependencies:
The ARM: dts: Declare the PWM for bcm11351 (bcm281xx) patch depends
upon ARM: dts: bcm281xx: define real clocks which is queued up in
for-next of arm-soc. See https://lkml.org/lkml/2014/2/14/451

Tim Kryger (5):
  Documentation: dt: Add Kona PWM binding
  pwm: kona: Introduce Kona PWM controller support
  ARM: dts: Declare the PWM for bcm11351 (bcm281xx)
  ARM: dts: Enable the PWM for bcm28155 AP board
  ARM: bcm_defconfig: Enable PWM and Backlight

 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 ++
 arch/arm/boot/dts/bcm11351.dtsi|8 +
 arch/arm/boot/dts/bcm28155-ap.dts  |4 +
 arch/arm/configs/bcm_defconfig |3 +
 drivers/pwm/Kconfig|9 +
 drivers/pwm/Makefile   |1 +
 drivers/pwm/pwm-bcm-kona.c |  319 
 7 files changed, 365 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
 create mode 100644 drivers/pwm/pwm-bcm-kona.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 3/5] ARM: dts: Declare the PWM for bcm11351 (bcm281xx)

[Tim Kryger]

Add the device tree node for the PWM on bcm11351 SoCs.

Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Alex Elder el...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
---
 arch/arm/boot/dts/bcm11351.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 64d069b..6b05ae6 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -193,6 +193,14 @@
status = disabled;
};
 
+   pwm: pwm@3e01a000 {
+   compatible = brcm,bcm11351-pwm, brcm,kona-pwm;
+   reg = 0x3e01a000 0xcc;
+   clocks = slave_ccu BCM281XX_SLAVE_CCU_PWM;
+   #pwm-cells = 3;
+   status = disabled;
+   };
+
clocks {
#address-cells = 1;
#size-cells = 1;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rfc]pwm: add BCM2835 PWM driver

[Tim Kryger]

On Thu, Apr 3, 2014 at 6:44 AM, Bart Tanghe  wrote:
> need some recommendation
> the memory mapped io registers of the bcm2835 pwm hardware are spreaded
> over the memory mapped io
> gpio config 0x2024 - clk config 0x201010A0 - pwm configuration 0x2020C000
> to handle this, I've used the base address of the memory mapped io
> so I can use positive offsets

So the registers for this PWM are located in three distinct memory regions?

Just define those three regions in your platform data or device tree.

> +/*mmio regiser mapping*/
> +#define OFFSET_PWM 0x0020C000

You won't need this guy.

> +#define DUTY   0x14
> +#define PERIOD 0x10
> +#define CHANNEL0x10
> +
> +#define OFFSET_CLK 0x001010A0

Also unnecessary.

> +#define DIV0x04
> +
> +#define OFFSET_ALT 0x0024

This can go too.

> +
> +/*Value defines*/
> +/*pwm clock configuration*/
> +#define PWMCLK_CNTL_OFF (0x5A00 | (1 << 5))
> +#define PWMCLK_CNTL_ON (0x5A00 | 0x11)
> +
> +#define PWM_ENABLE 0x0001
> +#define PWM_POLARITY   0x0010
> +/*+-1MHz pwm clock*/
> +#define PWMCLK_DIV (0x5A00 | (19 << 12))
> +/*ALT5 mask gpio18*/
> +#define ALTOR  0x0200
> +#define ALTAND 0xFAFF
> +/*pwm configuration*/
> +#define MASK_CTL_PWM   0x00FF
> +#define CTL_PWM0x0081
> +
> +#define DRIVER_AUTHOR "Bart Tanghe "
> +#define DRIVER_DESC   "A bcm2835 pwm driver - raspberry pi development 
> platform\
> +- only gpio 18 channel0 available"
> +
> +unsigned long *ptrPWM;
> +unsigned long *ptrPERIOD;
> +unsigned long *ptrDUTY;
> +unsigned long *ptrCLK;
> +unsigned long *ptrALT;
> +unsigned long *ptrDIV;

You don't need any of these pointers and they most certainly should
not be globals.

> +
> +struct bcm2835_pwm_chip {
> +   struct pwm_chip chip;
> +   struct device *dev;
> +   int channel;
> +   void __iomem *mmio;

One pointer isn't going to be enough.  You need three.

I suggest renaming the first and adding two more:

void __iomem *base_pwm;
void __iomem *base_clk;
void __iomem *base_alt;

> +};
> +
> +static inline struct bcm2835_pwm_chip *to_bcm2835_pwm_chip(
> +struct pwm_chip *chip){
> +   return container_of(chip, struct bcm2835_pwm_chip, chip);
> +}
> +
> +static int bcm2835_pwm_config(struct pwm_chip *chip,
> +struct pwm_device *pwm, int duty_ns, int period_ns){

Please align arguments on subsequent lines with those on the first line.

> +
> +   struct bcm2835_pwm_chip *pc;
> +
> +   pc = container_of(chip, struct bcm2835_pwm_chip, chip);

You defined to_bcm2835_pwm_chip but aren't using it here.  Why?

> +
> +   iowrite32(duty_ns/1000, ptrDUTY);
> +   iowrite32(period_ns/1000, ptrPERIOD);
> +
> +   #ifdef DEBUG
> +   printk(KERN_DEBUG "period %x\n", (unsigned int)ptrPERIOD);
> +   printk(KERN_DEBUG "duty %x\n", (unsigned int)ptrDUTY);
> +   #endif
> +
> +   return 0;
> +}
> +
> +static int bcm2835_pwm_enable(struct pwm_chip *chip,
> +struct pwm_device *pwm){

Again, please line up arguments on subsequent lines with those on the first.

This applies to pretty much all subsequent functions as well.

> +   struct bcm2835_pwm_chip *pc;
> +
> +   pc = container_of(chip, struct bcm2835_pwm_chip, chip);
> +
> +   /*TODO: channel 1 enable*/
> +   #ifdef DEBUG
> +   printk(KERN_DEBUG "pwm label: %s\n", pwm->label);
> +   printk(KERN_DEBUG "pwm hwpwm: %d\n", pwm->hwpwm);
> +   printk(KERN_DEBUG "pwm pwm: %d\n", pwm->pwm);
> +   #endif
> +
> +   iowrite32(ioread32(ptrPWM) | PWM_ENABLE, ptrPWM);
> +   #ifdef DEBUG
> +   printk(KERN_DEBUG "pwm: %x\n", ioread32(ptrPWM));
> +   #endif
> +   return 0;
> +}
> +
> +static void bcm2835_pwm_disable(struct pwm_chip *chip,
> +   struct pwm_device *pwm)
> +{
> +   struct bcm2835_pwm_chip *pc;
> +
> +   pc = to_bcm2835_pwm_chip(chip);
> +
> +   #ifdef DEBUG
> +   printk(KERN_DEBUG "pwm label: %s\n", pwm->label);
> +   printk(KERN_DEBUG "pwm hwpwm: %d\n", pwm->hwpwm);
> +   printk(KERN_DEBUG "pwm pwm: %d\n", pwm->pwm);
> +   #endif
> +
> +   iowrite32(ioread32(ptrPWM) & ~PWM_ENABLE, ptrPWM);
> +}
> +
> +static int bcm2835_set_polarity(struct pwm_chip *chip, struct pwm_device 
> *pwm,
> +enum pwm_polarity polarity)
> +{
> +   if (polarity == PWM_POLARITY_NORMAL)
> +   iowrite32((ioread32(ptrPWM) & ~PWM_POLARITY), ptrPWM);
> +   else if (polarity == PWM_POLARITY_INVERSED)
> +   iowrite32((ioread32(ptrPWM) | PWM_POLARITY), ptrPWM);
> +
> +   return 0;
> +}
> +
> +static const struct pwm_ops bcm2835_pwm_ops = {
> +   .config = bcm2835_pwm_config,
> +   .enable = bcm2835_pwm_enable,
> +   .disable = bcm2835_pwm_disable,
> +   .set_polarity = bcm2835_set_polarity,
> +   .owner = 

Re: [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional

[Tim Kryger]

On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann  
wrote:
> Thierry Reding wrote:

>> No. You cannot emulate polarity inversion in software.
>>
> Why not?
>
> duty_ns = period_ns - duty_ns;

Since I made the same mistake, I will pass along the pointer Thierry gave me.

In include/linux/pwm.h the second difference for an inverted signal is
described.

/**
 * enum pwm_polarity - polarity of a PWM signal
 * @PWM_POLARITY_NORMAL: a high signal for the duration of the duty-
 * cycle, followed by a low signal for the remainder of the pulse
 * period
 * @PWM_POLARITY_INVERSED: a low signal for the duration of the duty-
 * cycle, followed by a high signal for the remainder of the pulse
 * period
 */
enum pwm_polarity {
PWM_POLARITY_NORMAL,
PWM_POLARITY_INVERSED,
};

Of course, I suspect not all PWM hardware respects this definition of
inverted output.

Either way, hacking the duty in software certainly would get the
high/low order wrong.

-Tim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 1/3] pwm: make the PWM_POLARITY flag in DTB optional

[Tim Kryger]

On Mon, Apr 7, 2014 at 10:02 PM, Lothar Waßmann l...@karo-electronics.de 
wrote:
 Thierry Reding wrote:

 No. You cannot emulate polarity inversion in software.

 Why not?

 duty_ns = period_ns - duty_ns;

Since I made the same mistake, I will pass along the pointer Thierry gave me.

In include/linux/pwm.h the second difference for an inverted signal is
described.

/**
 * enum pwm_polarity - polarity of a PWM signal
 * @PWM_POLARITY_NORMAL: a high signal for the duration of the duty-
 * cycle, followed by a low signal for the remainder of the pulse
 * period
 * @PWM_POLARITY_INVERSED: a low signal for the duration of the duty-
 * cycle, followed by a high signal for the remainder of the pulse
 * period
 */
enum pwm_polarity {
PWM_POLARITY_NORMAL,
PWM_POLARITY_INVERSED,
};

Of course, I suspect not all PWM hardware respects this definition of
inverted output.

Either way, hacking the duty in software certainly would get the
high/low order wrong.

-Tim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rfc]pwm: add BCM2835 PWM driver

[Tim Kryger]

On Thu, Apr 3, 2014 at 6:44 AM, Bart Tanghe bart.tan...@thomasmore.be wrote:
 need some recommendation
 the memory mapped io registers of the bcm2835 pwm hardware are spreaded
 over the memory mapped io
 gpio config 0x2024 - clk config 0x201010A0 - pwm configuration 0x2020C000
 to handle this, I've used the base address of the memory mapped io
 so I can use positive offsets

So the registers for this PWM are located in three distinct memory regions?

Just define those three regions in your platform data or device tree.

 +/*mmio regiser mapping*/
 +#define OFFSET_PWM 0x0020C000

You won't need this guy.

 +#define DUTY   0x14
 +#define PERIOD 0x10
 +#define CHANNEL0x10
 +
 +#define OFFSET_CLK 0x001010A0

Also unnecessary.

 +#define DIV0x04
 +
 +#define OFFSET_ALT 0x0024

This can go too.

 +
 +/*Value defines*/
 +/*pwm clock configuration*/
 +#define PWMCLK_CNTL_OFF (0x5A00 | (1  5))
 +#define PWMCLK_CNTL_ON (0x5A00 | 0x11)
 +
 +#define PWM_ENABLE 0x0001
 +#define PWM_POLARITY   0x0010
 +/*+-1MHz pwm clock*/
 +#define PWMCLK_DIV (0x5A00 | (19  12))
 +/*ALT5 mask gpio18*/
 +#define ALTOR  0x0200
 +#define ALTAND 0xFAFF
 +/*pwm configuration*/
 +#define MASK_CTL_PWM   0x00FF
 +#define CTL_PWM0x0081
 +
 +#define DRIVER_AUTHOR Bart Tanghe bart.tan...@thomasmore.be
 +#define DRIVER_DESC   A bcm2835 pwm driver - raspberry pi development 
 platform\
 +- only gpio 18 channel0 available
 +
 +unsigned long *ptrPWM;
 +unsigned long *ptrPERIOD;
 +unsigned long *ptrDUTY;
 +unsigned long *ptrCLK;
 +unsigned long *ptrALT;
 +unsigned long *ptrDIV;

You don't need any of these pointers and they most certainly should
not be globals.

 +
 +struct bcm2835_pwm_chip {
 +   struct pwm_chip chip;
 +   struct device *dev;
 +   int channel;
 +   void __iomem *mmio;

One pointer isn't going to be enough.  You need three.

I suggest renaming the first and adding two more:

void __iomem *base_pwm;
void __iomem *base_clk;
void __iomem *base_alt;

 +};
 +
 +static inline struct bcm2835_pwm_chip *to_bcm2835_pwm_chip(
 +struct pwm_chip *chip){
 +   return container_of(chip, struct bcm2835_pwm_chip, chip);
 +}
 +
 +static int bcm2835_pwm_config(struct pwm_chip *chip,
 +struct pwm_device *pwm, int duty_ns, int period_ns){

Please align arguments on subsequent lines with those on the first line.

 +
 +   struct bcm2835_pwm_chip *pc;
 +
 +   pc = container_of(chip, struct bcm2835_pwm_chip, chip);

You defined to_bcm2835_pwm_chip but aren't using it here.  Why?

 +
 +   iowrite32(duty_ns/1000, ptrDUTY);
 +   iowrite32(period_ns/1000, ptrPERIOD);
 +
 +   #ifdef DEBUG
 +   printk(KERN_DEBUG period %x\n, (unsigned int)ptrPERIOD);
 +   printk(KERN_DEBUG duty %x\n, (unsigned int)ptrDUTY);
 +   #endif
 +
 +   return 0;
 +}
 +
 +static int bcm2835_pwm_enable(struct pwm_chip *chip,
 +struct pwm_device *pwm){

Again, please line up arguments on subsequent lines with those on the first.

This applies to pretty much all subsequent functions as well.

 +   struct bcm2835_pwm_chip *pc;
 +
 +   pc = container_of(chip, struct bcm2835_pwm_chip, chip);
 +
 +   /*TODO: channel 1 enable*/
 +   #ifdef DEBUG
 +   printk(KERN_DEBUG pwm label: %s\n, pwm-label);
 +   printk(KERN_DEBUG pwm hwpwm: %d\n, pwm-hwpwm);
 +   printk(KERN_DEBUG pwm pwm: %d\n, pwm-pwm);
 +   #endif
 +
 +   iowrite32(ioread32(ptrPWM) | PWM_ENABLE, ptrPWM);
 +   #ifdef DEBUG
 +   printk(KERN_DEBUG pwm: %x\n, ioread32(ptrPWM));
 +   #endif
 +   return 0;
 +}
 +
 +static void bcm2835_pwm_disable(struct pwm_chip *chip,
 +   struct pwm_device *pwm)
 +{
 +   struct bcm2835_pwm_chip *pc;
 +
 +   pc = to_bcm2835_pwm_chip(chip);
 +
 +   #ifdef DEBUG
 +   printk(KERN_DEBUG pwm label: %s\n, pwm-label);
 +   printk(KERN_DEBUG pwm hwpwm: %d\n, pwm-hwpwm);
 +   printk(KERN_DEBUG pwm pwm: %d\n, pwm-pwm);
 +   #endif
 +
 +   iowrite32(ioread32(ptrPWM)  ~PWM_ENABLE, ptrPWM);
 +}
 +
 +static int bcm2835_set_polarity(struct pwm_chip *chip, struct pwm_device 
 *pwm,
 +enum pwm_polarity polarity)
 +{
 +   if (polarity == PWM_POLARITY_NORMAL)
 +   iowrite32((ioread32(ptrPWM)  ~PWM_POLARITY), ptrPWM);
 +   else if (polarity == PWM_POLARITY_INVERSED)
 +   iowrite32((ioread32(ptrPWM) | PWM_POLARITY), ptrPWM);
 +
 +   return 0;
 +}
 +
 +static const struct pwm_ops bcm2835_pwm_ops = {
 +   .config = bcm2835_pwm_config,
 +   .enable = bcm2835_pwm_enable,
 +   .disable = bcm2835_pwm_disable,
 +   .set_polarity = bcm2835_set_polarity,
 +   .owner = THIS_MODULE,
 +};
 +
 +static int bcm2835_pwm_probe(struct platform_device *pdev)
 +{
 +   struct 

Re: [PATCH 2/5] ARM: add SMP support for Broadcom mobile SoCs

[Tim Kryger]

On Thu, Apr 3, 2014 at 7:18 PM, Alex Elder  wrote:

> diff --git a/arch/arm/mach-bcm/platsmp.c b/arch/arm/mach-bcm/platsmp.c
> new file mode 100644
> index 000..46a64f2
> --- /dev/null
> +++ b/arch/arm/mach-bcm/platsmp.c

> +/* Size of mapped Cortex A9 SCU address space */
> +#define SCU_SIZE   0x58

> +/*
> + * Enable the Cortex A9 Snoop Control Unit
> + *
> + * By the time this is called we already know there are multiple
> + * cores present.  We assume we're running on a Cortex A9 processor,
> + * so any trouble getting the base address register or getting the
> + * SCU base is a problem.
> + *
> + * Return 0 if successful or an error code otherwise.
> + */
> +static int __init scu_a9_enable(void)
> +{
> +   unsigned long config_base;
> +   void __iomem *scu_base;
> +
> +   if (!scu_a9_has_base()) {
> +   pr_err("no configuration base address register!\n");
> +   return -ENXIO;
> +   }
> +
> +   /* Config base address register value is zero for uniprocessor */
> +   config_base = scu_a9_get_base();
> +   if (!config_base) {
> +   pr_err("hardware reports only one core; disabling SMP\n");
> +   return -ENOENT;
> +   }
> +
> +   scu_base = ioremap((phys_addr_t)config_base, SCU_SIZE);
> +   if (!scu_base) {
> +   pr_err("failed to remap config base (%lu/%u) for SCU\n",
> +   config_base, SCU_SIZE);
> +   return -ENOMEM;
> +   }
> +
> +   scu_enable(scu_base);
> +
> +   iounmap(scu_base);  /* That's the last we'll need of this */
> +
> +   return 0;
> +}

This function seems useful for Cortex A9 MPCore in general.

While you gave it a generic name, you put it in a Broadcom file.

Is there a better location for this code?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] ARM: add SMP support for Broadcom mobile SoCs

[Tim Kryger]

On Thu, Apr 3, 2014 at 7:18 PM, Alex Elder el...@linaro.org wrote:

 diff --git a/arch/arm/mach-bcm/platsmp.c b/arch/arm/mach-bcm/platsmp.c
 new file mode 100644
 index 000..46a64f2
 --- /dev/null
 +++ b/arch/arm/mach-bcm/platsmp.c

 +/* Size of mapped Cortex A9 SCU address space */
 +#define SCU_SIZE   0x58

 +/*
 + * Enable the Cortex A9 Snoop Control Unit
 + *
 + * By the time this is called we already know there are multiple
 + * cores present.  We assume we're running on a Cortex A9 processor,
 + * so any trouble getting the base address register or getting the
 + * SCU base is a problem.
 + *
 + * Return 0 if successful or an error code otherwise.
 + */
 +static int __init scu_a9_enable(void)
 +{
 +   unsigned long config_base;
 +   void __iomem *scu_base;
 +
 +   if (!scu_a9_has_base()) {
 +   pr_err(no configuration base address register!\n);
 +   return -ENXIO;
 +   }
 +
 +   /* Config base address register value is zero for uniprocessor */
 +   config_base = scu_a9_get_base();
 +   if (!config_base) {
 +   pr_err(hardware reports only one core; disabling SMP\n);
 +   return -ENOENT;
 +   }
 +
 +   scu_base = ioremap((phys_addr_t)config_base, SCU_SIZE);
 +   if (!scu_base) {
 +   pr_err(failed to remap config base (%lu/%u) for SCU\n,
 +   config_base, SCU_SIZE);
 +   return -ENOMEM;
 +   }
 +
 +   scu_enable(scu_base);
 +
 +   iounmap(scu_base);  /* That's the last we'll need of this */
 +
 +   return 0;
 +}

This function seems useful for Cortex A9 MPCore in general.

While you gave it a generic name, you put it in a Broadcom file.

Is there a better location for this code?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 4/5] ARM: dts: Enable the PWM for bcm28155 AP board

[Tim Kryger]

Mark the PWM as enabled on the bcm28155 AP board.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm28155-ap.dts |4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
b/arch/arm/boot/dts/bcm28155-ap.dts
index 5ff2382..37c72eb 100644
--- a/arch/arm/boot/dts/bcm28155-ap.dts
+++ b/arch/arm/boot/dts/bcm28155-ap.dts
@@ -66,6 +66,10 @@
status = "okay";
};
 
+   pwm: pwm@3e01a000 {
+   status = "okay";
+   };
+
usbotg: usb@3f12 {
status = "okay";
};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 1/5] Documentation: dt: Add Kona PWM binding

[Tim Kryger]

Add the binding description for the Kona PWM controller found on Broadcom's
mobile SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 .../devicetree/bindings/pwm/bcm-kona-pwm.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000..8eae9fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+
+This controller has 6 channels.
+
+Required Properties :
+- compatible: should contain "brcm,kona-pwm"
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+
+Example:
+
+pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xc4>;
+   clocks = <_clk>;
+   #pwm-cells = <3>;
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 5/5] ARM: bcm_defconfig: Enable PWM and Backlight

[Tim Kryger]

Enable PWM drivers and the PWM-based backlight driver.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/configs/bcm_defconfig |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
index 3b2b7bd..593df57 100644
--- a/arch/arm/configs/bcm_defconfig
+++ b/arch/arm/configs/bcm_defconfig
@@ -88,6 +88,7 @@ CONFIG_FB=y
 CONFIG_BACKLIGHT_LCD_SUPPORT=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_PWM=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_UNSAFE_RESUME=y
@@ -101,6 +102,8 @@ CONFIG_LEDS_TRIGGERS=y
 CONFIG_LEDS_TRIGGER_TIMER=y
 CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_PWM=y
+CONFIG_PWM_BCM_KONA=y
 CONFIG_EXT4_FS=y
 CONFIG_EXT4_FS_POSIX_ACL=y
 CONFIG_EXT4_FS_SECURITY=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RESEND PATCH v5 3/5] ARM: dts: Declare the PWM for bcm11351 (bcm281xx)

[Tim Kryger]

Add the device tree node for the PWM on bcm11351 SoCs.

Signed-off-by: Tim Kryger 
Reviewed-by: Alex Elder 
Reviewed-by: Markus Mayer 
---
 arch/arm/boot/dts/bcm11351.dtsi |8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
index 64d069b..6b05ae6 100644
--- a/arch/arm/boot/dts/bcm11351.dtsi
+++ b/arch/arm/boot/dts/bcm11351.dtsi
@@ -193,6 +193,14 @@
status = "disabled";
};
 
+   pwm: pwm@3e01a000 {
+   compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+   reg = <0x3e01a000 0xcc>;
+   clocks = <_ccu BCM281XX_SLAVE_CCU_PWM>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
clocks {
#address-cells = <1>;
#size-cells = <1>;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/