Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 19 September 2016 01:16 PM, Peter Chen wrote:

On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:


On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:

[...]


We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

Why 2 separate approach for same problem ?
And I see this as possible duplication of code/functionality :)

How the new kernel compatibles old dts? If we do not need to
consider this problem, the mmc can try to use power sequence library
too in future.

I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?

yeah, thats right.

So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.

What I am trying to propose here is,

Lets have power-sequence framework (similar to V1 of this series),
with,

pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
   here is, all future code should be using this new
   binding, so that we can deprecate the
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
  complex in nature.

Then the respective drivers can add their drivers (if needed) based on
complexity.

comments ??

The key point here is DT maintainer (Rob) doesn't agree with adding new node
for power sequence at dts.



Hmmm.
We haven't heard from Rob lately especially after introduction of complex
usecases. I hope he would revisit on above proposal.

Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 19 September 2016 01:16 PM, Peter Chen wrote:

On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:


On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:

[...]


We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

Why 2 separate approach for same problem ?
And I see this as possible duplication of code/functionality :)

How the new kernel compatibles old dts? If we do not need to
consider this problem, the mmc can try to use power sequence library
too in future.

I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?

yeah, thats right.

So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.

What I am trying to propose here is,

Lets have power-sequence framework (similar to V1 of this series),
with,

pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
   here is, all future code should be using this new
   binding, so that we can deprecate the
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
  complex in nature.

Then the respective drivers can add their drivers (if needed) based on
complexity.

comments ??

The key point here is DT maintainer (Rob) doesn't agree with adding new node
for power sequence at dts.



Hmmm.
We haven't heard from Rob lately especially after introduction of complex
usecases. I hope he would revisit on above proposal.

Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:

[...]


We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

Why 2 separate approach for same problem ?
And I see this as possible duplication of code/functionality :)

How the new kernel compatibles old dts? If we do not need to
consider this problem, the mmc can try to use power sequence library
too in future.


I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?


yeah, thats right.

So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.

What I am trying to propose here is,

Lets have power-sequence framework (similar to V1 of this series),
with,

pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
  here is, all future code should be using this new
  binding, so that we can deprecate the 
drivers/mmc/core/pwrseq

pwrseq_arche: The usecase which I am dealing with today, which is more
 complex in nature.

Then the respective drivers can add their drivers (if needed) based on
complexity.

comments ??


MMC Power Seq :
  It is based on platform_device/platform_driver approach,

We recently converted MMC to this. It's has a clear benefit as you can
rely on the behaviour from the driver core and PM core. So, it simply
avoids duplication of code.


Agreed.


USB Power seq :
  We are trying to propose library approach, with compatible string match.

We should try to have one approach.



   - Lets also add suspend/resume callback to struct pwrseq


Why suspend/resume can't do at related driver's suspend/resume API?

Nope...
The pwrseq library would have taken ownership of resources, so
related driver cannot suspend the device. Again it is architecture
specific, but we should have provision to handle this.

The system I am dealing with today, does need suspend/resume
callback. To be precise, suspend is close to off state for some devices
or
they could enter standby or different low power state, but to do that,
we need same resource as used for ON/OFF functionality.


Ok, I will have API for suspend/resume. You can implement it at your own
library or generic one.

As stated, using a platform device + driver would simplify this, as
you wouldn't need an API but only a driver. I guess.


Exactly.

Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:

[...]


We had an agreement that keep mmc's pwrseq framework unchanging.
Unless Ulf and rob both agree to change.

Why 2 separate approach for same problem ?
And I see this as possible duplication of code/functionality :)

How the new kernel compatibles old dts? If we do not need to
consider this problem, the mmc can try to use power sequence library
too in future.


I think we should attempt to get both MMC and USB power seq
come on one agreement, so that it can be reused.

That would be nice. Although, to do that you would have to allow some
DT bindings to be deprecated in the new generic power seq bindings, as
otherwise you would break existing DTBs.

I guess that is what Rob was objecting to!?


yeah, thats right.

So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.

What I am trying to propose here is,

Lets have power-sequence framework (similar to V1 of this series),
with,

pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
  here is, all future code should be using this new
  binding, so that we can deprecate the 
drivers/mmc/core/pwrseq

pwrseq_arche: The usecase which I am dealing with today, which is more
 complex in nature.

Then the respective drivers can add their drivers (if needed) based on
complexity.

comments ??


MMC Power Seq :
  It is based on platform_device/platform_driver approach,

We recently converted MMC to this. It's has a clear benefit as you can
rely on the behaviour from the driver core and PM core. So, it simply
avoids duplication of code.


Agreed.


USB Power seq :
  We are trying to propose library approach, with compatible string match.

We should try to have one approach.



   - Lets also add suspend/resume callback to struct pwrseq


Why suspend/resume can't do at related driver's suspend/resume API?

Nope...
The pwrseq library would have taken ownership of resources, so
related driver cannot suspend the device. Again it is architecture
specific, but we should have provision to handle this.

The system I am dealing with today, does need suspend/resume
callback. To be precise, suspend is close to off state for some devices
or
they could enter standby or different low power state, but to do that,
we need same resource as used for ON/OFF functionality.


Ok, I will have API for suspend/resume. You can implement it at your own
library or generic one.

As stated, using a platform device + driver would simplify this, as
you wouldn't need an API but only a driver. I guess.


Exactly.

Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

a

On Friday 02 September 2016 06:40 AM, Peter Chen wrote:

On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:


On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:

On Monday 29 August 2016 04:40 PM, Peter Chen wrote:

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:

veOn Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1]http://www.spinics.net/lists/linux-usb/msg142755.html
[2]http://www.spinics.net/lists/linux-usb/msg143106.html
[3]http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the
generic library
implementation in this patch series is not going to solve many of
the custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


   Host
|
V
USB port

|
V
   USB HUB device (May need custom on/off seq)
|
V
   =
  | |
  V V
  Device-1   Device-2
(Needs special power   (Needs special power
  on/off sequence.   on/off sequence.
  Also may need custom   Also, may need custom
  sequence for   sequence for
  suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
   in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.


Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.


Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

  - How DTS looks like now ?? Can you put example here ?

The dts is the same with current version.

How would consumer driver get the power sequence ?
You must point to right power sequence driver.
For example, in the above example, Device-1, should
get handle to pwrseq-1, and Device-2 to pwrseq-2.

According to compatible string at device's of_node, we will have a list

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

a

On Friday 02 September 2016 06:40 AM, Peter Chen wrote:

On Wed, Aug 31, 2016 at 10:28:20PM +0530, Vaibhav Hiremath wrote:


On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:

On Monday 29 August 2016 04:40 PM, Peter Chen wrote:

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:

veOn Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1]http://www.spinics.net/lists/linux-usb/msg142755.html
[2]http://www.spinics.net/lists/linux-usb/msg143106.html
[3]http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the
generic library
implementation in this patch series is not going to solve many of
the custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


   Host
|
V
USB port

|
V
   USB HUB device (May need custom on/off seq)
|
V
   =
  | |
  V V
  Device-1   Device-2
(Needs special power   (Needs special power
  on/off sequence.   on/off sequence.
  Also may need custom   Also, may need custom
  sequence for   sequence for
  suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
   in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.


Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.


Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

  - How DTS looks like now ?? Can you put example here ?

The dts is the same with current version.

How would consumer driver get the power sequence ?
You must point to right power sequence driver.
For example, in the above example, Device-1, should
get handle to pwrseq-1, and Device-2 to pwrseq-2.

According to compatible string at device's of_node, we will have a list

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Friday 02 September 2016 06:30 AM, Peter Chen wrote:

On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:


On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen <peter.c...@nxp.com>
Acked-by: Philipp Zabel <p.za...@pengutronix.de>
Acked-by: Rob Herring <r...@kernel.org>
---
  .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
  1 file changed, 48 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";

So I assume, with our recent discussion and the change
we are proposing, the library would have some knowledge
about this compatible string, right?

Yes


what I was asking on other email was, how are you connecting
multiple power sequence libraries to their respective consumers ?


The consumers has its of_node, then it can find related power sequence
library according to compatible string.



Exactly. Thats what I was referring and wanted to confirm.

Thanks,
Vaibhav


--
Thanks,
Vaibhav

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Friday 02 September 2016 06:30 AM, Peter Chen wrote:

On Thu, Sep 01, 2016 at 01:33:22PM +0530, Vaibhav Hiremath wrote:


On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
  .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
  1 file changed, 48 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";

So I assume, with our recent discussion and the change
we are proposing, the library would have some knowledge
about this compatible string, right?

Yes


what I was asking on other email was, how are you connecting
multiple power sequence libraries to their respective consumers ?


The consumers has its of_node, then it can find related power sequence
library according to compatible string.



Exactly. Thats what I was referring and wanted to confirm.

Thanks,
Vaibhav


--
Thanks,
Vaibhav

Re: [PATCH v6 2/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover regulator and pinctrl
in future. The host driver calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
Reviewed-by: Matthias Kaehlcke 
Tested-by: Matthias Kaehlcke 
---
  MAINTAINERS   |   9 ++
  drivers/power/Kconfig |   1 +
  drivers/power/Makefile|   1 +
  drivers/power/pwrseq/Kconfig  |  20 
  drivers/power/pwrseq/Makefile |   2 +
  drivers/power/pwrseq/core.c   |  62 +
  drivers/power/pwrseq/pwrseq_generic.c | 168 ++
  include/linux/power/pwrseq.h  |  47 ++
  8 files changed, 310 insertions(+)
  create mode 100644 drivers/power/pwrseq/Kconfig
  create mode 100644 drivers/power/pwrseq/Makefile
  create mode 100644 drivers/power/pwrseq/core.c
  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
  create mode 100644 include/linux/power/pwrseq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ae6c84..407254b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9283,6 +9283,15 @@ F:   include/linux/pm_*
  F:include/linux/powercap.h
  F:drivers/powercap/
  
+POWER SEQUENCE LIBRARY

+M: Peter Chen 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/power/pwrseq/
+F: drivers/power/pwrseq/
+F: include/linux/power/pwrseq.h/
+
  POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
  M:Sebastian Reichel 
  M:Dmitry Eremin-Solenikov 
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
  
  source "drivers/power/reset/Kconfig"

  source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o
  obj-$(CONFIG_POWER_RESET) += reset/
  obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
  obj-$(CONFIG_AXP288_CHARGER)  += axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)   += pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+config POWER_SEQUENCE
+   bool
+
+menu "Power Sequence Support"
+
+config PWRSEQ_GENERIC
+   bool "Generic power sequence control"
+   depends on OF
+   select POWER_SEQUENCE
+   help
+ It is used for drivers which needs to do power sequence
+ (eg, turn on clock, toggle reset gpio) before the related
+ devices can be found by hardware. This generic one can be
+ used for common power sequence control.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 000..dcf96c4
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,62 @@
+/*
+ * core.c  power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this 

Re: [PATCH v6 2/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.

This power sequence is hard to be described at device tree and handled by
related host driver, so we have created a common power sequence
library to cover this requirement. The core code has supplied
some common helpers for host driver, and individual power sequence
libraries handle kinds of power sequence for devices.

pwrseq_generic is intended for general purpose of power sequence, which
handles gpios and clocks currently, and can cover regulator and pinctrl
in future. The host driver calls pwrseq_alloc_generic to create
an generic pwrseq instance.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
Reviewed-by: Matthias Kaehlcke 
Tested-by: Matthias Kaehlcke 
---
  MAINTAINERS   |   9 ++
  drivers/power/Kconfig |   1 +
  drivers/power/Makefile|   1 +
  drivers/power/pwrseq/Kconfig  |  20 
  drivers/power/pwrseq/Makefile |   2 +
  drivers/power/pwrseq/core.c   |  62 +
  drivers/power/pwrseq/pwrseq_generic.c | 168 ++
  include/linux/power/pwrseq.h  |  47 ++
  8 files changed, 310 insertions(+)
  create mode 100644 drivers/power/pwrseq/Kconfig
  create mode 100644 drivers/power/pwrseq/Makefile
  create mode 100644 drivers/power/pwrseq/core.c
  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
  create mode 100644 include/linux/power/pwrseq.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ae6c84..407254b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9283,6 +9283,15 @@ F:   include/linux/pm_*
  F:include/linux/powercap.h
  F:drivers/powercap/
  
+POWER SEQUENCE LIBRARY

+M: Peter Chen 
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/power/pwrseq/
+F: drivers/power/pwrseq/
+F: include/linux/power/pwrseq.h/
+
  POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
  M:Sebastian Reichel 
  M:Dmitry Eremin-Solenikov 
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..f6aa4fd 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -515,3 +515,4 @@ endif # POWER_SUPPLY
  
  source "drivers/power/reset/Kconfig"

  source "drivers/power/avs/Kconfig"
+source "drivers/power/pwrseq/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d..4ed2e12 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)+= tps65217_charger.o
  obj-$(CONFIG_POWER_RESET) += reset/
  obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
  obj-$(CONFIG_AXP288_CHARGER)  += axp288_charger.o
+obj-$(CONFIG_POWER_SEQUENCE)   += pwrseq/
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
new file mode 100644
index 000..188729e
--- /dev/null
+++ b/drivers/power/pwrseq/Kconfig
@@ -0,0 +1,20 @@
+#
+# Power Sequence library
+#
+
+config POWER_SEQUENCE
+   bool
+
+menu "Power Sequence Support"
+
+config PWRSEQ_GENERIC
+   bool "Generic power sequence control"
+   depends on OF
+   select POWER_SEQUENCE
+   help
+ It is used for drivers which needs to do power sequence
+ (eg, turn on clock, toggle reset gpio) before the related
+ devices can be found by hardware. This generic one can be
+ used for common power sequence control.
+
+endmenu
diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
new file mode 100644
index 000..ad82389
--- /dev/null
+++ b/drivers/power/pwrseq/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_POWER_SEQUENCE) += core.o
+obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
new file mode 100644
index 000..dcf96c4
--- /dev/null
+++ b/drivers/power/pwrseq/core.c
@@ -0,0 +1,62 @@
+/*
+ * core.c  power sequence core file
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+
+static DEFINE_MUTEX(pwrseq_list_mutex);
+static LIST_HEAD(pwrseq_list);
+
+int 

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
  .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
  1 file changed, 48 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";


So I assume, with our recent discussion and the change
we are proposing, the library would have some knowledge
about this compatible string, right?

what I was asking on other email was, how are you connecting
multiple power sequence libraries to their respective consumers ?

Thanks,
Vaibhav


+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};


--
Thanks,
Vaibhav

Re: [PATCH v6 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Add binding doc for generic power sequence library.

Signed-off-by: Peter Chen 
Acked-by: Philipp Zabel 
Acked-by: Rob Herring 
---
  .../bindings/power/pwrseq/pwrseq-generic.txt   | 48 ++
  1 file changed, 48 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt 
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
new file mode 100644
index 000..ebf0d47
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
@@ -0,0 +1,48 @@
+The generic power sequence library
+
+Some hard-wired devices (eg USB/MMC) need to do power sequence before
+the device can be enumerated on the bus, the typical power sequence
+like: enable USB PHY clock, toggle reset pin, etc. But current
+Linux device driver lacks of such code to do it, it may cause some
+hard-wired devices works abnormal or can't be recognized by
+controller at all. The power sequence will be done before this device
+can be found at the bus.
+
+The power sequence properties is under the device node.
+
+Optional properties:
+- clocks: the input clocks for device.
+- reset-gpios: Should specify the GPIO for reset.
+- reset-duration-us: the duration in microsecond for assert reset signal.
+
+Below is the example of USB power sequence properties on USB device
+nodes which have two level USB hubs.
+
+ {
+   vbus-supply = <_usb_otg1_vbus>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb_otg1_id>;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   genesys: hub@1 {
+   compatible = "usb5e3,608";
+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_CKO>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
+   reset-duration-us = <10>;
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   asix: ethernet@1 {
+   compatible = "usbb95,1708";


So I assume, with our recent discussion and the change
we are proposing, the library would have some knowledge
about this compatible string, right?

what I was asking on other email was, how are you connecting
multiple power sequence libraries to their respective consumers ?

Thanks,
Vaibhav


+   reg = <1>;
+
+   clocks = < IMX6SX_CLK_IPG>;
+   reset-gpios = < 6 GPIO_ACTIVE_LOW>; /* 
ethernet_rst */
+   reset-duration-us = <15>;
+   };
+   };
+};


--
Thanks,
Vaibhav

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then it will do power
on sequence at hub's probe for all devices under this hub
(includes root hub).

At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
---
  drivers/usb/core/Makefile |   1 +
  drivers/usb/core/hub.c|  12 --
  drivers/usb/core/hub.h|  12 ++
  drivers/usb/core/pwrseq.c | 100 ++
  4 files changed, 122 insertions(+), 3 deletions(-)
  create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..39f2149 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
  
  usbcore-$(CONFIG_PCI)		+= hcd-pci.o

  usbcore-$(CONFIG_ACPI)+= usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
  
  obj-$(CONFIG_USB)		+= usbcore.o

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
  
+	hub_pwrseq_off(hub);

mutex_lock(_port_peer_mutex);
  
  	/* Avoid races with recursively_mark_NOTATTACHED() */

@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
  
  	desc = intf->cur_altsetting;

hdev = interface_to_usbdev(intf);
@@ -1839,6 +1841,7 @@ descriptor_error:
INIT_DELAYED_WORK(>leds, led_work);
INIT_DELAYED_WORK(>init_work, NULL);
INIT_WORK(>events, hub_event);
+   INIT_LIST_HEAD(>pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
  
@@ -1852,11 +1855,14 @@ descriptor_error:

if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
  
-	if (hub_configure(hub, endpoint) >= 0)

-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
  
  	hub_disconnect(intf);

-   return -ENODEV;
+   return ret;
  }
  
  static int

diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node list */
  };
  
  /**

@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct 
usb_hub *hub,
  {
return hub_port_debounce(hub, port1, false);
  }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 000..837fe66
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,100 @@
+/*
+ * pwrseq.cUSB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+   struct pwrseq *pwrseq;
+   struct list_head 

Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some hard-wired USB devices
works abnormal or can't be recognized by controller at all.

In this patch, it calls power sequence library APIs to finish
the power sequence events. At first, it calls pwrseq_alloc_generic
to create a generic power sequence instance, then it will do power
on sequence at hub's probe for all devices under this hub
(includes root hub).

At hub_disconnect, it will do power off sequence which is at powered
on list.

Signed-off-by: Peter Chen 
Tested-by Joshua Clayton 
---
  drivers/usb/core/Makefile |   1 +
  drivers/usb/core/hub.c|  12 --
  drivers/usb/core/hub.h|  12 ++
  drivers/usb/core/pwrseq.c | 100 ++
  4 files changed, 122 insertions(+), 3 deletions(-)
  create mode 100644 drivers/usb/core/pwrseq.c

diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
index 9780877..39f2149 100644
--- a/drivers/usb/core/Makefile
+++ b/drivers/usb/core/Makefile
@@ -9,5 +9,6 @@ usbcore-y += port.o of.o
  
  usbcore-$(CONFIG_PCI)		+= hcd-pci.o

  usbcore-$(CONFIG_ACPI)+= usb-acpi.o
+usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
  
  obj-$(CONFIG_USB)		+= usbcore.o

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index bee1351..a346a8b 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
hub->error = 0;
hub_quiesce(hub, HUB_DISCONNECT);
  
+	hub_pwrseq_off(hub);

mutex_lock(_port_peer_mutex);
  
  	/* Avoid races with recursively_mark_NOTATTACHED() */

@@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const 
struct usb_device_id *id)
struct usb_endpoint_descriptor *endpoint;
struct usb_device *hdev;
struct usb_hub *hub;
+   int ret = -ENODEV;
  
  	desc = intf->cur_altsetting;

hdev = interface_to_usbdev(intf);
@@ -1839,6 +1841,7 @@ descriptor_error:
INIT_DELAYED_WORK(>leds, led_work);
INIT_DELAYED_WORK(>init_work, NULL);
INIT_WORK(>events, hub_event);
+   INIT_LIST_HEAD(>pwrseq_on_list);
usb_get_intf(intf);
usb_get_dev(hdev);
  
@@ -1852,11 +1855,14 @@ descriptor_error:

if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
hub->quirk_check_port_auto_suspend = 1;
  
-	if (hub_configure(hub, endpoint) >= 0)

-   return 0;
+   if (hub_configure(hub, endpoint) >= 0) {
+   ret = hub_pwrseq_on(hub);
+   if (!ret)
+   return 0;
+   }
  
  	hub_disconnect(intf);

-   return -ENODEV;
+   return ret;
  }
  
  static int

diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e..9473f6f 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -78,6 +78,7 @@ struct usb_hub {
struct delayed_work init_work;
struct work_struct  events;
struct usb_port **ports;
+   struct list_headpwrseq_on_list; /* powered pwrseq node list */
  };
  
  /**

@@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct 
usb_hub *hub,
  {
return hub_port_debounce(hub, port1, false);
  }
+
+#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
+int hub_pwrseq_on(struct usb_hub *hub);
+void hub_pwrseq_off(struct usb_hub *hub);
+#else
+static inline int hub_pwrseq_on(struct usb_hub *hub)
+{
+   return 0;
+}
+static inline void hub_pwrseq_off(struct usb_hub *hub) {}
+#endif /* CONFIG_PWRSEQ_GENERIC */
diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
new file mode 100644
index 000..837fe66
--- /dev/null
+++ b/drivers/usb/core/pwrseq.c
@@ -0,0 +1,100 @@
+/*
+ * pwrseq.cUSB device power sequence management
+ *
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Author: Peter Chen 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hub.h"
+
+struct usb_pwrseq_node {
+   struct pwrseq *pwrseq;
+   struct list_head list;
+};
+
+static int hub_of_pwrseq_on(struct device_node *np, 

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:


On Monday 29 August 2016 04:40 PM, Peter Chen wrote:

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1]http://www.spinics.net/lists/linux-usb/msg142755.html
[2]http://www.spinics.net/lists/linux-usb/msg143106.html
[3]http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the
generic library
implementation in this patch series is not going to solve many of
the custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


   Host
|
V
USB port

|
V
   USB HUB device (May need custom on/off seq)
|
V
   =
  | |
  V V
  Device-1   Device-2
(Needs special power   (Needs special power
  on/off sequence.   on/off sequence.
  Also may need custom   Also, may need custom
  sequence for   sequence for
  suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
   in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.


Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.


Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

  - How DTS looks like now ?? Can you put example here ?

The dts is the same with current version.


How would consumer driver get the power sequence ?
You must point to right power sequence driver.
For example, in the above example, Device-1, should
get handle to pwrseq-1, and Device-2 to pwrseq-2.


  - Should we merge MMC power sequence in next series ?
We also can take this as an incremental change, to avoid further
delay :)

We had an agreement that keep mmc's pwrseq framework

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Wednesday 31 August 2016 03:22 PM, Peter Chen wrote:

On Wed, Aug 31, 2016 at 01:46:30PM +0530, Vaibhav Hiremath wrote:


On Monday 29 August 2016 04:40 PM, Peter Chen wrote:

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1]http://www.spinics.net/lists/linux-usb/msg142755.html
[2]http://www.spinics.net/lists/linux-usb/msg143106.html
[3]http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the
generic library
implementation in this patch series is not going to solve many of
the custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


   Host
|
V
USB port

|
V
   USB HUB device (May need custom on/off seq)
|
V
   =
  | |
  V V
  Device-1   Device-2
(Needs special power   (Needs special power
  on/off sequence.   on/off sequence.
  Also may need custom   Also, may need custom
  sequence for   sequence for
  suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
   in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.


Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.


Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

  - How DTS looks like now ?? Can you put example here ?

The dts is the same with current version.


How would consumer driver get the power sequence ?
You must point to right power sequence driver.
For example, in the above example, Device-1, should
get handle to pwrseq-1, and Device-2 to pwrseq-2.


  - Should we merge MMC power sequence in next series ?
We also can take this as an incremental change, to avoid further
delay :)

We had an agreement that keep mmc's pwrseq framework

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 29 August 2016 04:40 PM, Peter Chen wrote:

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1]http://www.spinics.net/lists/linux-usb/msg142755.html
[2]http://www.spinics.net/lists/linux-usb/msg143106.html
[3]http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the
generic library
implementation in this patch series is not going to solve many of
the custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


   Host
|
V
USB port

|
V
   USB HUB device (May need custom on/off seq)
|
V
   =
  | |
  V V
  Device-1   Device-2
(Needs special power   (Needs special power
  on/off sequence.   on/off sequence.
  Also may need custom   Also, may need custom
  sequence for   sequence for
  suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
   in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.


Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.



Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

 - How DTS looks like now ?? Can you put example here ?
 - Should we merge MMC power sequence in next series ?
   We also can take this as an incremental change, to avoid further
   delay :)
 - Lets also add suspend/resume callback to struct pwrseq


There are some comments I have on the patches,
I will respond directly on respective patches, it would be useful
for next series.


And Sorry for delayed response.

--
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 29 August 2016 04:40 PM, Peter Chen wrote:

On Wed, Aug 24, 2016 at 04:53:35PM +0800, Peter Chen wrote:

On Tue, Aug 23, 2016 at 04:02:48PM +0530, Vaibhav Hiremath wrote:

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1]http://www.spinics.net/lists/linux-usb/msg142755.html
[2]http://www.spinics.net/lists/linux-usb/msg143106.html
[3]http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the
generic library
implementation in this patch series is not going to solve many of
the custom
requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy
hooks/path)
to enable that ?

Let me bring in the use case I am dealing with,


   Host
|
V
USB port

|
V
   USB HUB device (May need custom on/off seq)
|
V
   =
  | |
  V V
  Device-1   Device-2
(Needs special power   (Needs special power
  on/off sequence.   on/off sequence.
  Also may need custom   Also, may need custom
  sequence for   sequence for
  suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
   in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Rob, it seems generic power sequence can't cover all cases.
Without information from DT, we can't know which power sequence
for which device.


Vaibhav, do you agree that I create pwrseq library list using postcore_initcall
for each library, and choose pwrseq library according to compatible
string first, if there is no compatible string for this library, just
use generic pwrseq library.



Lets hear from MMC folks. Ulf, do you agree on approach
for pwr seq ??


With above approach, I kind of agree on it, but I have couple
of comments,

 - How DTS looks like now ?? Can you put example here ?
 - Should we merge MMC power sequence in next series ?
   We also can take this as an incremental change, to avoid further
   delay :)
 - Lets also add suspend/resume callback to struct pwrseq


There are some comments I have on the patches,
I will respond directly on respective patches, it would be useful
for next series.


And Sorry for delayed response.

--
Thanks,
Vaibhav

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the generic 
library
implementation in this patch series is not going to solve many of the 
custom

requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy 
hooks/path)

to enable that ?

Let me bring in the use case I am dealing with,


  Host
   |
   V
   USB port

   |
   V
  USB HUB device (May need custom on/off seq)
   |
   V
  =
 | |
 V V
 Device-1   Device-2
(Needs special power   (Needs special power
 on/off sequence.   on/off sequence.
 Also may need custom   Also, may need custom
 sequence for   sequence for
 suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
  in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Thanks,
Vaibhav




Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
   the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support multiple input clocks [Patch 2/6]
- Add Rob Herring's ack for DT changes
- Add Joshua Clayton's Tested-by

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
   at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
   add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
   

Re: [PATCH v6 0/8] power: add power sequence library

[Vaibhav Hiremath]

On Monday 15 August 2016 02:43 PM, Peter Chen wrote:

Hi all,

This is a follow-up for my last power sequence framework patch set [1].
According to Rob Herring and Ulf Hansson's comments[2], I use a generic
power sequence library for parsing the power sequence elements on DT,
and implement generic power sequence on library. The host driver
can allocate power sequence instance, and calls pwrseq APIs accordingly.

In future, if there are special power sequence requirements, the special
power sequence library can be created.

This patch set is tested on i.mx6 sabresx evk using a dts change, I use
two hot-plug devices to simulate this use case, the related binding
change is updated at patch [1/6], The udoo board changes were tested
using my last power sequence patch set.[3]

Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
need to power on itself before it can be found by ULPI bus.

[1] http://www.spinics.net/lists/linux-usb/msg142755.html
[2] http://www.spinics.net/lists/linux-usb/msg143106.html
[3] http://www.spinics.net/lists/linux-usb/msg142815.html

(Please ignore my response on V2)

Sorry being so late in the discussion...

If I am not missing anything, then I am afraid to say that the generic 
library
implementation in this patch series is not going to solve many of the 
custom

requirement of power on, off, etc...
I know you mentioned about adding another library when we come
across such platforms, but should we not keep provision (or easy 
hooks/path)

to enable that ?

Let me bring in the use case I am dealing with,


  Host
   |
   V
   USB port

   |
   V
  USB HUB device (May need custom on/off seq)
   |
   V
  =
 | |
 V V
 Device-1   Device-2
(Needs special power   (Needs special power
 on/off sequence.   on/off sequence.
 Also may need custom   Also, may need custom
 sequence for   sequence for
 suspend/resume)suspend/resume)


Note: Both Devices are connected to HUB via HSIC and may differ
  in terms of functionality, features they support.

In the above case, both Device-1 and Device-2, need separate
power on/off sequence. So generic library currently we have in this
patch series is not going to satisfy the need here.

I looked at all 6 revisions of this patch-series, went through the
review comments, and looked at MMC power sequence code;
what I can say here is, we need something similar to
MMC power sequence here, where every device can have its own
power sequence (if needed).

I know Rob is not in favor of creating platform device for
this, and I understand his comment.
If not platform device, but atleast we need mechanism to
connect each device back to its of_node and its respective
driver/library fns. For example, the Devices may support different
boot modes, and platform driver needs to make sure that
the right sequence is followed for booting.

Peter, My apologies for taking you back again on this series.
I am OK, if you wish to address this in incremental addition,
but my point is, we know that the current generic way is not
enough for us, so I think we should try to fix it in initial phase only.


Thanks,
Vaibhav




Changes for v6:
- Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
- Change chipidea core of_node assignment for coming user. (patch [5/6])
- Applies Joshua Clayton's three dts changes for two boards,
   the USB device's reg has only #address-cells, but without #size-cells.

Changes for v5:
- Delete pwrseq_register/pwrseq_unregister, which is useless currently
- Fix the linker error when the pwrseq user is compiled as module

Changes for v4:
- Create the patch on next-20160722
- Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
- Using more friendly wait method for reset gpio [Patch 2/6]
- Support multiple input clocks [Patch 2/6]
- Add Rob Herring's ack for DT changes
- Add Joshua Clayton's Tested-by

Changes for v3:
- Delete "power-sequence" property at binding-doc, and change related code
   at both library and user code.
- Change binding-doc example node name with Rob's comments
- of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
   add additional code request gpio with proper gpio flags
- Add Philipp Zabel's Ack and MAINTAINER's entry

Changes for v2:
- Delete "pwrseq" prefix and clock-names for properties at dt binding
- Should use structure not but its pointer for kzalloc
- Since chipidea core has no of_node, let core's of_node equals glue
   

Re: [PATCH] USB: core: of: Check device_node before parsing in usb_of_get_child_node()

[Vaibhav Hiremath]

On Monday 15 August 2016 06:33 PM, Peter Chen wrote:

On Mon, Aug 15, 2016 at 11:31:10AM -0700, Vaibhav Hiremath wrote:

In case of HUB devices connected to USB ports, we may not have DT
node representing it inside USB, and when devices connected to hub
gets enumerated, call to usb_of_get_child_node() leads to NULL pointer
dereference.

In the usecase we have, where EHCI port is connected to USB HUB
device, and downward ports of HUB are connected to further USB
devices. When those devices gets enumerated, in order,
  1. USB HUB ->
-> Call to usb_of_get_child_node() is OK, as
parent->dev.of_node is pointing to host node.
  2. Devices connected to downward port of USB HUB
-> Call to usb_of_get_child_node() leads to NULL
pointer dereference as parent->dev.of_node = NULL,
as USB HUB DTS node may be empty.

Fix this NULL pointer dereference by adding check for pointer
device_node inside usb_of_get_child_node() fn.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
Testing: I have build tested it against mainline.

  drivers/usb/core/of.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index 2289700..dc667a3 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -34,6 +34,9 @@ struct device_node *usb_of_get_child_node(struct device_node 
*parent,
struct device_node *node;
u32 port;
  
+	if (!parent)

+   return NULL;
+
for_each_child_of_node(parent, node) {
if (!of_property_read_u32(node, "reg", )) {
if (port == portnum)

I am afraid I can't reproduce it, would you please show me your dump
when null pointer dereference occurs? From what I find the
__of_get_next_child checks null pointer for parent node.



Peter,
You are right, __of_get_next_child is taking care of this.

When I observed this issue with my setup [1], I only looked at changes in
the mainline for of.c and core/usb.c, did not see the anything.

Anyways, for the record, we do not need this patch. Instead I need to 
backport

below commit from mainline to my kernel base.

commit 43cb43678705e39b175b325f17938295996aefc7
Author: Florian Fainelli <f.faine...@gmail.com>
Date:   Wed May 28 10:39:02 2014 -0700

of: handle NULL node in next_child iterators

Add an early check for the node argument in __of_get_next_child and
of_get_next_available_child() to avoid dereferencing a NULL node 
pointer

a few lines after.


[1] Also I missed to mention about my kernel version, I am based on very
ancient kernel version (3.10). Do not ask me why, it is something out of my
control :)

--
Thanks,
Vaibhav

Re: [PATCH] USB: core: of: Check device_node before parsing in usb_of_get_child_node()

[Vaibhav Hiremath]

On Monday 15 August 2016 06:33 PM, Peter Chen wrote:

On Mon, Aug 15, 2016 at 11:31:10AM -0700, Vaibhav Hiremath wrote:

In case of HUB devices connected to USB ports, we may not have DT
node representing it inside USB, and when devices connected to hub
gets enumerated, call to usb_of_get_child_node() leads to NULL pointer
dereference.

In the usecase we have, where EHCI port is connected to USB HUB
device, and downward ports of HUB are connected to further USB
devices. When those devices gets enumerated, in order,
  1. USB HUB ->
-> Call to usb_of_get_child_node() is OK, as
parent->dev.of_node is pointing to host node.
  2. Devices connected to downward port of USB HUB
-> Call to usb_of_get_child_node() leads to NULL
pointer dereference as parent->dev.of_node = NULL,
as USB HUB DTS node may be empty.

Fix this NULL pointer dereference by adding check for pointer
device_node inside usb_of_get_child_node() fn.

Signed-off-by: Vaibhav Hiremath 
---
Testing: I have build tested it against mainline.

  drivers/usb/core/of.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index 2289700..dc667a3 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -34,6 +34,9 @@ struct device_node *usb_of_get_child_node(struct device_node 
*parent,
struct device_node *node;
u32 port;
  
+	if (!parent)

+   return NULL;
+
for_each_child_of_node(parent, node) {
if (!of_property_read_u32(node, "reg", )) {
if (port == portnum)

I am afraid I can't reproduce it, would you please show me your dump
when null pointer dereference occurs? From what I find the
__of_get_next_child checks null pointer for parent node.



Peter,
You are right, __of_get_next_child is taking care of this.

When I observed this issue with my setup [1], I only looked at changes in
the mainline for of.c and core/usb.c, did not see the anything.

Anyways, for the record, we do not need this patch. Instead I need to 
backport

below commit from mainline to my kernel base.

commit 43cb43678705e39b175b325f17938295996aefc7
Author: Florian Fainelli 
Date:   Wed May 28 10:39:02 2014 -0700

of: handle NULL node in next_child iterators

Add an early check for the node argument in __of_get_next_child and
of_get_next_available_child() to avoid dereferencing a NULL node 
pointer

a few lines after.


[1] Also I missed to mention about my kernel version, I am based on very
ancient kernel version (3.10). Do not ask me why, it is something out of my
control :)

--
Thanks,
Vaibhav

Re: [PATCH] USB: core: of: Check device_node before parsing in usb_of_get_child_node()

[Vaibhav Hiremath]

On Monday 15 August 2016 11:41 AM, Greg KH wrote:

On Mon, Aug 15, 2016 at 11:31:10AM -0700, Vaibhav Hiremath wrote:

In case of HUB devices connected to USB ports, we may not have DT
node representing it inside USB, and when devices connected to hub
gets enumerated, call to usb_of_get_child_node() leads to NULL pointer
dereference.

Really?  That seems messed up.


unfortunately yes :)


In the usecase we have, where EHCI port is connected to USB HUB
device, and downward ports of HUB are connected to further USB
devices. When those devices gets enumerated, in order,
  1. USB HUB ->
-> Call to usb_of_get_child_node() is OK, as
parent->dev.of_node is pointing to host node.
  2. Devices connected to downward port of USB HUB
-> Call to usb_of_get_child_node() leads to NULL
pointer dereference as parent->dev.of_node = NULL,
as USB HUB DTS node may be empty.

Why is the hub DTS empty?  Shouldn't that be the fix here?


Because HUB can be enumerated dynamically and one possible
reason could be you don't need to do anything to bring up HUB.
May be one of following could be the reason -

 1. HUB automatically comes up on power ON, and USB host enumerates it.
   There is no control path for HUB

 2. HUB has different control path, in our case it is over I2C.
   So HUB configuration and bringup happens as part of I2C client driver.



So you may not need DTS for HUB as a child node inside USB host.
What I am trying to say here is,


_ehci {
...

status = "ok";
};

This would enumerate HUB first, and then devices connected to HUB, right?
So this will lead to kernel crash.



Reference DTS with HUB and downward devices -

_ehci {
status = "ok";

usb_hub: usb_hub {
compatible = "usb";
reg = <1>;

usb_dev: usb_dev {
compatible = "usb";
reg = <1>;

...
};
   };
};


Thanks,
Vaibhav

Re: [PATCH] USB: core: of: Check device_node before parsing in usb_of_get_child_node()

[Vaibhav Hiremath]

On Monday 15 August 2016 11:41 AM, Greg KH wrote:

On Mon, Aug 15, 2016 at 11:31:10AM -0700, Vaibhav Hiremath wrote:

In case of HUB devices connected to USB ports, we may not have DT
node representing it inside USB, and when devices connected to hub
gets enumerated, call to usb_of_get_child_node() leads to NULL pointer
dereference.

Really?  That seems messed up.


unfortunately yes :)


In the usecase we have, where EHCI port is connected to USB HUB
device, and downward ports of HUB are connected to further USB
devices. When those devices gets enumerated, in order,
  1. USB HUB ->
-> Call to usb_of_get_child_node() is OK, as
parent->dev.of_node is pointing to host node.
  2. Devices connected to downward port of USB HUB
-> Call to usb_of_get_child_node() leads to NULL
pointer dereference as parent->dev.of_node = NULL,
as USB HUB DTS node may be empty.

Why is the hub DTS empty?  Shouldn't that be the fix here?


Because HUB can be enumerated dynamically and one possible
reason could be you don't need to do anything to bring up HUB.
May be one of following could be the reason -

 1. HUB automatically comes up on power ON, and USB host enumerates it.
   There is no control path for HUB

 2. HUB has different control path, in our case it is over I2C.
   So HUB configuration and bringup happens as part of I2C client driver.



So you may not need DTS for HUB as a child node inside USB host.
What I am trying to say here is,


_ehci {
...

status = "ok";
};

This would enumerate HUB first, and then devices connected to HUB, right?
So this will lead to kernel crash.



Reference DTS with HUB and downward devices -

_ehci {
status = "ok";

usb_hub: usb_hub {
compatible = "usb";
reg = <1>;

usb_dev: usb_dev {
compatible = "usb";
reg = <1>;

...
};
   };
};


Thanks,
Vaibhav

[PATCH] USB: core: of: Check device_node before parsing in usb_of_get_child_node()

[Vaibhav Hiremath]

In case of HUB devices connected to USB ports, we may not have DT
node representing it inside USB, and when devices connected to hub
gets enumerated, call to usb_of_get_child_node() leads to NULL pointer
dereference.

In the usecase we have, where EHCI port is connected to USB HUB
device, and downward ports of HUB are connected to further USB
devices. When those devices gets enumerated, in order,
 1. USB HUB ->
-> Call to usb_of_get_child_node() is OK, as
parent->dev.of_node is pointing to host node.
 2. Devices connected to downward port of USB HUB
-> Call to usb_of_get_child_node() leads to NULL
pointer dereference as parent->dev.of_node = NULL,
as USB HUB DTS node may be empty.

Fix this NULL pointer dereference by adding check for pointer
device_node inside usb_of_get_child_node() fn.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
Testing: I have build tested it against mainline.

 drivers/usb/core/of.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index 2289700..dc667a3 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -34,6 +34,9 @@ struct device_node *usb_of_get_child_node(struct device_node 
*parent,
struct device_node *node;
u32 port;
 
+   if (!parent)
+   return NULL;
+
for_each_child_of_node(parent, node) {
if (!of_property_read_u32(node, "reg", )) {
if (port == portnum)
-- 
2.7.4

[PATCH] USB: core: of: Check device_node before parsing in usb_of_get_child_node()

[Vaibhav Hiremath]

In case of HUB devices connected to USB ports, we may not have DT
node representing it inside USB, and when devices connected to hub
gets enumerated, call to usb_of_get_child_node() leads to NULL pointer
dereference.

In the usecase we have, where EHCI port is connected to USB HUB
device, and downward ports of HUB are connected to further USB
devices. When those devices gets enumerated, in order,
 1. USB HUB ->
-> Call to usb_of_get_child_node() is OK, as
parent->dev.of_node is pointing to host node.
 2. Devices connected to downward port of USB HUB
-> Call to usb_of_get_child_node() leads to NULL
pointer dereference as parent->dev.of_node = NULL,
as USB HUB DTS node may be empty.

Fix this NULL pointer dereference by adding check for pointer
device_node inside usb_of_get_child_node() fn.

Signed-off-by: Vaibhav Hiremath 
---
Testing: I have build tested it against mainline.

 drivers/usb/core/of.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c
index 2289700..dc667a3 100644
--- a/drivers/usb/core/of.c
+++ b/drivers/usb/core/of.c
@@ -34,6 +34,9 @@ struct device_node *usb_of_get_child_node(struct device_node 
*parent,
struct device_node *node;
u32 port;
 
+   if (!parent)
+   return NULL;
+
for_each_child_of_node(parent, node) {
if (!of_property_read_u32(node, "reg", )) {
if (port == portnum)
-- 
2.7.4

Re: [RFD] Sharing GPIOs for input (buttons) and output (LEDs)

[Vaibhav Hiremath]

On Thursday 17 March 2016 03:48 PM, Linus Walleij wrote:

On Mon, Feb 22, 2016 at 1:14 PM, Geert Uytterhoeven
 wrote:


On the Renesas Salvator-X development board, 3 GPIO pins are connected to both
push buttons and LEDs.


Not exactly related to buttons and leds,
but recently I came across another usecase of shared gpio,

Say, for example, we have multiple external I2C peripheral which share
interrupt line over gpio (ofcourse irq line is muxed onto single gpio).

Now in kernel I would have multiple instances of driver supporting each
peripheral but gpio can not be shared for registering irq.

Do you suggest MFD driver for such simple usecases ? Should gpiolib
support SHARED gpios, and gpiolib can define all the policies over
configuration (input only, what about conflicts, bidirectional mode?)

Thanks,
Vaibhav



   - If the GPIO is configured for output, it can control the LED,
   - If the GPIO is configured for input, the push button status can be
 read. Note that the LED is on if the push button is not pressed; it is
 turned off while holding the button.


Have you asked the hardware engineer who did this construction
what s/he was thinking? And I mean seriously: what was the
usecase? Did they really design the LEDs to be used to flicker
with or just as an indication as to whether the button was being
pushed or not?

Your approach seems dedicated to use it for both usecases (also
as a stand-alone heartbeat or whatever) but was that really
intended?


 keyboard {
 compatible = "gpio-keys";

 key-a {
 gpios = < 11 GPIO_ACTIVE_LOW>;
 label = "SW20";
 wakeup-source;
 linux,code = ;
 };
 key-b {
 gpios = < 12 GPIO_ACTIVE_LOW>;
 label = "SW21";
 wakeup-source;
 linux,code = ;
 };
 key-c {
 gpios = < 13 GPIO_ACTIVE_LOW>;
 label = "SW22";
 wakeup-source;
 linux,code = ;
 };
 };


I suspect that in this usecase, the GPIO should be flagged
GPIO_OPEN_DRAIN rather than GPIO_ACTIVE_LOW,
as the construction with the LED draws current fron the line.


There exist device tree bindings for LEDs connected to GPIOs, and the
following also works:

 leds {
 compatible = "gpio-leds";

 led4 {
 gpios = < 11 GPIO_ACTIVE_HIGH>;
 label = "LED4";
 };
 led5 {
 gpios = < 12 GPIO_ACTIVE_HIGH>;
 label = "LED5";
 };
 led6 {
 gpios = < 13 GPIO_ACTIVE_HIGH>;
 label = "LED6";
 };
 };


OK


If a GPIO is found busy during initialization, and if it's already in
use by the other half of the driver, the driver switches to a special
"polled-key-and-LED" mode. I.e. during polling, it does:
   - Save the GPIO output state,
   - Switch the GPIO to input mode,
   - Wait 5 ms (else it will read the old output state, depending on
 e.g. hardware capacitance),
   - Read the GPIO input state,
   - Switch the GPIO to output mode,
   - Restore the GPIO output state.

And it works, the LEDs can be controlled, and the push button states can
be read!


Why go to such troubles of switching the line from output to
input to read it?

Especially when a line is OPEN_DRAIN it should be perfectly legal
to read it's value even if it is set as output, but AFAICT that is
always working no matter whether the line is set as output.


However, due to the 5 ms delay, there's a visible flickering of LEDs
that are supposed to be turned off (remember, when the GPIO is
configured for input and the button is not pressed, the LED is lit).

If we go this route, adding support for non-polled GPIOs (if the GPIO is
not shared with an LED) and wake-up should be doable.


I think this actually implies OPEN_DRAIN and if you flag it as such
the core should be happy using it as input and output at the same
time.

If the hardware has a problem with reading the value from a line
that is set to output, it needs a workaround hack in the driver to
support reading and output line, *NOT* changes to gpiolib,
because the lib assumes this is always possible, i.e. it will
call the driver .get() callback no matter what.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFD] Sharing GPIOs for input (buttons) and output (LEDs)

[Vaibhav Hiremath]

On Thursday 17 March 2016 03:48 PM, Linus Walleij wrote:

On Mon, Feb 22, 2016 at 1:14 PM, Geert Uytterhoeven
 wrote:


On the Renesas Salvator-X development board, 3 GPIO pins are connected to both
push buttons and LEDs.


Not exactly related to buttons and leds,
but recently I came across another usecase of shared gpio,

Say, for example, we have multiple external I2C peripheral which share
interrupt line over gpio (ofcourse irq line is muxed onto single gpio).

Now in kernel I would have multiple instances of driver supporting each
peripheral but gpio can not be shared for registering irq.

Do you suggest MFD driver for such simple usecases ? Should gpiolib
support SHARED gpios, and gpiolib can define all the policies over
configuration (input only, what about conflicts, bidirectional mode?)

Thanks,
Vaibhav



   - If the GPIO is configured for output, it can control the LED,
   - If the GPIO is configured for input, the push button status can be
 read. Note that the LED is on if the push button is not pressed; it is
 turned off while holding the button.


Have you asked the hardware engineer who did this construction
what s/he was thinking? And I mean seriously: what was the
usecase? Did they really design the LEDs to be used to flicker
with or just as an indication as to whether the button was being
pushed or not?

Your approach seems dedicated to use it for both usecases (also
as a stand-alone heartbeat or whatever) but was that really
intended?


 keyboard {
 compatible = "gpio-keys";

 key-a {
 gpios = < 11 GPIO_ACTIVE_LOW>;
 label = "SW20";
 wakeup-source;
 linux,code = ;
 };
 key-b {
 gpios = < 12 GPIO_ACTIVE_LOW>;
 label = "SW21";
 wakeup-source;
 linux,code = ;
 };
 key-c {
 gpios = < 13 GPIO_ACTIVE_LOW>;
 label = "SW22";
 wakeup-source;
 linux,code = ;
 };
 };


I suspect that in this usecase, the GPIO should be flagged
GPIO_OPEN_DRAIN rather than GPIO_ACTIVE_LOW,
as the construction with the LED draws current fron the line.


There exist device tree bindings for LEDs connected to GPIOs, and the
following also works:

 leds {
 compatible = "gpio-leds";

 led4 {
 gpios = < 11 GPIO_ACTIVE_HIGH>;
 label = "LED4";
 };
 led5 {
 gpios = < 12 GPIO_ACTIVE_HIGH>;
 label = "LED5";
 };
 led6 {
 gpios = < 13 GPIO_ACTIVE_HIGH>;
 label = "LED6";
 };
 };


OK


If a GPIO is found busy during initialization, and if it's already in
use by the other half of the driver, the driver switches to a special
"polled-key-and-LED" mode. I.e. during polling, it does:
   - Save the GPIO output state,
   - Switch the GPIO to input mode,
   - Wait 5 ms (else it will read the old output state, depending on
 e.g. hardware capacitance),
   - Read the GPIO input state,
   - Switch the GPIO to output mode,
   - Restore the GPIO output state.

And it works, the LEDs can be controlled, and the push button states can
be read!


Why go to such troubles of switching the line from output to
input to read it?

Especially when a line is OPEN_DRAIN it should be perfectly legal
to read it's value even if it is set as output, but AFAICT that is
always working no matter whether the line is set as output.


However, due to the 5 ms delay, there's a visible flickering of LEDs
that are supposed to be turned off (remember, when the GPIO is
configured for input and the button is not pressed, the LED is lit).

If we go this route, adding support for non-polled GPIOs (if the GPIO is
not shared with an LED) and wake-up should be doable.


I think this actually implies OPEN_DRAIN and if you flag it as such
the core should be happy using it as input and output at the same
time.

If the hardware has a problem with reading the value from a line
that is set to output, it needs a workaround hack in the driver to
support reading and output line, *NOT* changes to gpiolib,
because the lib assumes this is always possible, i.e. it will
call the driver .get() callback no matter what.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH-v2 0/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

On Tuesday 15 September 2015 05:58 PM, Ulf Hansson wrote:

On 7 September 2015 at 13:31, Vaibhav Hiremath
 wrote:

Trivial patch-series, which fixes the tabbing issue in the driver,
uses the BIT macro for bit fields and prints notice on -EPROBE_DEFER
in sdhci_add_host() function on regulator unavailability.

V1 => V2

  - Fixed all comments from Joe, mostly alignment changes
  - Separated BIT macro usage patch into new one.
  - changed error to kernel notice for EPROBE_DEFER in sdhci_add_host()

Note: This patch-series should get merged before another series -

[PATCH-v2 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

Vaibhav Hiremath (3):
   mmc: sdhci-pxav3: Fix tabbing issue
   mmc: sdhci-pxav3: Use BIT macro for bit field definitions
   mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn

  drivers/mmc/host/sdhci-pxav3.c | 46 +-
  drivers/mmc/host/sdhci.c   |  5 -
  2 files changed, 27 insertions(+), 24 deletions(-)

--
1.9.1



Hi Vaibhav,

FYI, I won't be picking up any of these patches. Primarily because I
don't think they improves the code and other people also seems to
agree to that.

Regarding patch1 and similar patches which deals with only fixing
checkpatch warnings/errors. In most cases I don't like such changes,
as they makes it harder to use "git blame" when you want to find out
which commit that introduced a change.




Honestly, I also agree with you.
But recently I have been told to do these changed to get my
main/feature changes accepted :)

No issues, I am OK to drop them.
These are just beautification changes and as you rightly
said it makes 'git blame' difficult to find original change commit.


Thanks,
Vaibhav
--
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 0/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

On Tuesday 15 September 2015 05:58 PM, Ulf Hansson wrote:

On 7 September 2015 at 13:31, Vaibhav Hiremath
<vaibhav.hirem...@linaro.org> wrote:

Trivial patch-series, which fixes the tabbing issue in the driver,
uses the BIT macro for bit fields and prints notice on -EPROBE_DEFER
in sdhci_add_host() function on regulator unavailability.

V1 => V2

  - Fixed all comments from Joe, mostly alignment changes
  - Separated BIT macro usage patch into new one.
  - changed error to kernel notice for EPROBE_DEFER in sdhci_add_host()

Note: This patch-series should get merged before another series -

[PATCH-v2 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

Vaibhav Hiremath (3):
   mmc: sdhci-pxav3: Fix tabbing issue
   mmc: sdhci-pxav3: Use BIT macro for bit field definitions
   mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn

  drivers/mmc/host/sdhci-pxav3.c | 46 +-
  drivers/mmc/host/sdhci.c   |  5 -
  2 files changed, 27 insertions(+), 24 deletions(-)

--
1.9.1



Hi Vaibhav,

FYI, I won't be picking up any of these patches. Primarily because I
don't think they improves the code and other people also seems to
agree to that.

Regarding patch1 and similar patches which deals with only fixing
checkpatch warnings/errors. In most cases I don't like such changes,
as they makes it harder to use "git blame" when you want to find out
which commit that introduced a change.




Honestly, I also agree with you.
But recently I have been told to do these changed to get my
main/feature changes accepted :)

No issues, I am OK to drop them.
These are just beautification changes and as you rightly
said it makes 'git blame' difficult to find original change commit.


Thanks,
Vaibhav
--
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 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

[Vaibhav Hiremath]

On Monday 14 September 2015 06:11 PM, Vaibhav Hiremath wrote:



On Monday 14 September 2015 04:04 PM, Ulf Hansson wrote:

On 14 September 2015 at 11:42, Vaibhav Hiremath
 wrote:



On Monday 14 September 2015 03:00 PM, Ulf Hansson wrote:


[...]



Could this be implemented by regulator API? From patch set 3/3, the
pxa1928
voltage_switch hook is to operate the IO pad registers, this
seems not
belong
to the SDHC IP core.



Not quite sure whether regulator would be right fit for this.




   From the patche[3/3], this can be achieved by abstracting the
IO PAD
as
regulators
then, we may not need to touch the core sdhci.c. But I'm not sure
whether
this
is the good solution or not.




Exactly...


sdhci Maintainers and experts may have better
suggestions.



Thats is the reason I stamped it as a RFC :)



[...]

  From an mmc core perspective it would be preferred if you implement
this as a regulator (vqmmc).

Especially since we will soon have an API for how to set the I/O
voltages - and the intelligence within that API is not something we
would like to implement for each and every host driver.
https://lkml.org/lkml/2015/8/31/367




I would still consider this as a regulator specific and may not address
the IO configuration within the SoC which are module specific.
The API regulator_set_voltage_triplet() will not have intelligence to
differentiate whether the call is coming from MMC or somewhere else.

Note that, the IO pad voltage configuration which I am referring to is
MMC specific and applicable only when pad is configured in MMC mode. So
technically it is not simply common pad voltage configuration.


And I am still not sure regulator framework would be right fit for
this. Pinctrl would have been right fit, but...since I saw f_sdh30
driver is already doing this, which is easy fit; so adopted the same.


Pinctrl would work as well, or perhaps a combination of both pinctrl
and a regulator.



Not sure, how I can propagate "call coming from MMC/SD" to both
regulator and pinctrl.
Probably pinctrl would already know, but then it doesn't know the
voltage settings.

Let me spend some time, but atleast at this point I am not sure.





On the side note,
Lets park this patch aside, till I get back with better option.

It would be nice if you could review other patches, let them notget
blocked due to this.


Thanks,
Vaibhav
--
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 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

[Vaibhav Hiremath]

On Monday 14 September 2015 04:04 PM, Ulf Hansson wrote:

On 14 September 2015 at 11:42, Vaibhav Hiremath
 wrote:



On Monday 14 September 2015 03:00 PM, Ulf Hansson wrote:


[...]



Could this be implemented by regulator API? From patch set 3/3, the
pxa1928
voltage_switch hook is to operate the IO pad registers, this seems not
belong
to the SDHC IP core.



Not quite sure whether regulator would be right fit for this.




   From the patche[3/3], this can be achieved by abstracting the IO PAD
as
regulators
then, we may not need to touch the core sdhci.c. But I'm not sure
whether
this
is the good solution or not.




Exactly...


sdhci Maintainers and experts may have better
suggestions.



Thats is the reason I stamped it as a RFC :)



[...]

  From an mmc core perspective it would be preferred if you implement
this as a regulator (vqmmc).

Especially since we will soon have an API for how to set the I/O
voltages - and the intelligence within that API is not something we
would like to implement for each and every host driver.
https://lkml.org/lkml/2015/8/31/367




I would still consider this as a regulator specific and may not address
the IO configuration within the SoC which are module specific.
The API regulator_set_voltage_triplet() will not have intelligence to
differentiate whether the call is coming from MMC or somewhere else.

Note that, the IO pad voltage configuration which I am referring to is
MMC specific and applicable only when pad is configured in MMC mode. So
technically it is not simply common pad voltage configuration.


And I am still not sure regulator framework would be right fit for
this. Pinctrl would have been right fit, but...since I saw f_sdh30
driver is already doing this, which is easy fit; so adopted the same.


Pinctrl would work as well, or perhaps a combination of both pinctrl
and a regulator.



Not sure, how I can propagate "call coming from MMC/SD" to both
regulator and pinctrl.
Probably pinctrl would already know, but then it doesn't know the
voltage settings.

Let me spend some time, but atleast at this point I am not sure.



What I don't like is the solution you have suggested in patch3.



As I said, that was easy fit into existing implementation. :)
f_sdh30 already does something similar.

Thanks,
Vaibhav
--
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 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

[Vaibhav Hiremath]

On Monday 14 September 2015 03:00 PM, Ulf Hansson wrote:

[...]



Could this be implemented by regulator API? From patch set 3/3, the
pxa1928
voltage_switch hook is to operate the IO pad registers, this seems not
belong
to the SDHC IP core.



Not quite sure whether regulator would be right fit for this.



  From the patche[3/3], this can be achieved by abstracting the IO PAD as
regulators
then, we may not need to touch the core sdhci.c. But I'm not sure whether
this
is the good solution or not.



Exactly...


sdhci Maintainers and experts may have better
suggestions.



Thats is the reason I stamped it as a RFC :)



[...]

 From an mmc core perspective it would be preferred if you implement
this as a regulator (vqmmc).

Especially since we will soon have an API for how to set the I/O
voltages - and the intelligence within that API is not something we
would like to implement for each and every host driver.
https://lkml.org/lkml/2015/8/31/367




I would still consider this as a regulator specific and may not address
the IO configuration within the SoC which are module specific.
The API regulator_set_voltage_triplet() will not have intelligence to
differentiate whether the call is coming from MMC or somewhere else.

Note that, the IO pad voltage configuration which I am referring to is
MMC specific and applicable only when pad is configured in MMC mode. So
technically it is not simply common pad voltage configuration.


And I am still not sure regulator framework would be right fit for
this. Pinctrl would have been right fit, but...since I saw f_sdh30
driver is already doing this, which is easy fit; so adopted the same.

Thanks,
Vaibhav
--
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 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

[Vaibhav Hiremath]

On Monday 14 September 2015 04:04 PM, Ulf Hansson wrote:

On 14 September 2015 at 11:42, Vaibhav Hiremath
<vaibhav.hirem...@linaro.org> wrote:



On Monday 14 September 2015 03:00 PM, Ulf Hansson wrote:


[...]



Could this be implemented by regulator API? From patch set 3/3, the
pxa1928
voltage_switch hook is to operate the IO pad registers, this seems not
belong
to the SDHC IP core.



Not quite sure whether regulator would be right fit for this.




   From the patche[3/3], this can be achieved by abstracting the IO PAD
as
regulators
then, we may not need to touch the core sdhci.c. But I'm not sure
whether
this
is the good solution or not.




Exactly...


sdhci Maintainers and experts may have better
suggestions.



Thats is the reason I stamped it as a RFC :)



[...]

  From an mmc core perspective it would be preferred if you implement
this as a regulator (vqmmc).

Especially since we will soon have an API for how to set the I/O
voltages - and the intelligence within that API is not something we
would like to implement for each and every host driver.
https://lkml.org/lkml/2015/8/31/367




I would still consider this as a regulator specific and may not address
the IO configuration within the SoC which are module specific.
The API regulator_set_voltage_triplet() will not have intelligence to
differentiate whether the call is coming from MMC or somewhere else.

Note that, the IO pad voltage configuration which I am referring to is
MMC specific and applicable only when pad is configured in MMC mode. So
technically it is not simply common pad voltage configuration.


And I am still not sure regulator framework would be right fit for
this. Pinctrl would have been right fit, but...since I saw f_sdh30
driver is already doing this, which is easy fit; so adopted the same.


Pinctrl would work as well, or perhaps a combination of both pinctrl
and a regulator.



Not sure, how I can propagate "call coming from MMC/SD" to both
regulator and pinctrl.
Probably pinctrl would already know, but then it doesn't know the
voltage settings.

Let me spend some time, but atleast at this point I am not sure.



What I don't like is the solution you have suggested in patch3.



As I said, that was easy fit into existing implementation. :)
f_sdh30 already does something similar.

Thanks,
Vaibhav
--
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 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

[Vaibhav Hiremath]

On Monday 14 September 2015 06:11 PM, Vaibhav Hiremath wrote:



On Monday 14 September 2015 04:04 PM, Ulf Hansson wrote:

On 14 September 2015 at 11:42, Vaibhav Hiremath
<vaibhav.hirem...@linaro.org> wrote:



On Monday 14 September 2015 03:00 PM, Ulf Hansson wrote:


[...]



Could this be implemented by regulator API? From patch set 3/3, the
pxa1928
voltage_switch hook is to operate the IO pad registers, this
seems not
belong
to the SDHC IP core.



Not quite sure whether regulator would be right fit for this.




   From the patche[3/3], this can be achieved by abstracting the
IO PAD
as
regulators
then, we may not need to touch the core sdhci.c. But I'm not sure
whether
this
is the good solution or not.




Exactly...


sdhci Maintainers and experts may have better
suggestions.



Thats is the reason I stamped it as a RFC :)



[...]

  From an mmc core perspective it would be preferred if you implement
this as a regulator (vqmmc).

Especially since we will soon have an API for how to set the I/O
voltages - and the intelligence within that API is not something we
would like to implement for each and every host driver.
https://lkml.org/lkml/2015/8/31/367




I would still consider this as a regulator specific and may not address
the IO configuration within the SoC which are module specific.
The API regulator_set_voltage_triplet() will not have intelligence to
differentiate whether the call is coming from MMC or somewhere else.

Note that, the IO pad voltage configuration which I am referring to is
MMC specific and applicable only when pad is configured in MMC mode. So
technically it is not simply common pad voltage configuration.


And I am still not sure regulator framework would be right fit for
this. Pinctrl would have been right fit, but...since I saw f_sdh30
driver is already doing this, which is easy fit; so adopted the same.


Pinctrl would work as well, or perhaps a combination of both pinctrl
and a regulator.



Not sure, how I can propagate "call coming from MMC/SD" to both
regulator and pinctrl.
Probably pinctrl would already know, but then it doesn't know the
voltage settings.

Let me spend some time, but atleast at this point I am not sure.





On the side note,
Lets park this patch aside, till I get back with better option.

It would be nice if you could review other patches, let them notget
blocked due to this.


Thanks,
Vaibhav
--
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 2/3] mmc: sdhci: add host_ops->voltage_switch callback for all other voltages

[Vaibhav Hiremath]

On Monday 14 September 2015 03:00 PM, Ulf Hansson wrote:

[...]



Could this be implemented by regulator API? From patch set 3/3, the
pxa1928
voltage_switch hook is to operate the IO pad registers, this seems not
belong
to the SDHC IP core.



Not quite sure whether regulator would be right fit for this.



  From the patche[3/3], this can be achieved by abstracting the IO PAD as
regulators
then, we may not need to touch the core sdhci.c. But I'm not sure whether
this
is the good solution or not.



Exactly...


sdhci Maintainers and experts may have better
suggestions.



Thats is the reason I stamped it as a RFC :)



[...]

 From an mmc core perspective it would be preferred if you implement
this as a regulator (vqmmc).

Especially since we will soon have an API for how to set the I/O
voltages - and the intelligence within that API is not something we
would like to implement for each and every host driver.
https://lkml.org/lkml/2015/8/31/367




I would still consider this as a regulator specific and may not address
the IO configuration within the SoC which are module specific.
The API regulator_set_voltage_triplet() will not have intelligence to
differentiate whether the call is coming from MMC or somewhere else.

Note that, the IO pad voltage configuration which I am referring to is
MMC specific and applicable only when pad is configured in MMC mode. So
technically it is not simply common pad voltage configuration.


And I am still not sure regulator framework would be right fit for
this. Pinctrl would have been right fit, but...since I saw f_sdh30
driver is already doing this, which is easy fit; so adopted the same.

Thanks,
Vaibhav
--
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-v5 RESEND 3/5] i2c: pxa: Add support for pxa910/988 & new configuration features

[Vaibhav Hiremath]

On Saturday 12 September 2015 12:36 AM, Wolfram Sang wrote:

On Mon, Aug 24, 2015 at 11:29:36AM +0530, Vaibhav Hiremath wrote:

TWSI_ILCR & TWSI_IWCR registers are used to adjust clock rate
of standard & fast mode in pxa910/988; so this patch adds these two new
entries to "struct pxa_reg_layout" and "struct pxa_i2c".

As discussed in the previous patch-series, the idea here is to add standard
DT properties for ilcr and iwcr configuration fields.
In case of Master ilcr is used for low/high time and in case of slave mode
of operation iwcr is used for setup/hold time.


I need to rethink how to describe i2c bus timing parameters in DT in the
next days. But this is planned for 4.4., promised.

One thing I already wonder about this one...


  static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa2xx-i2c",   REGS_PXA2XX },
{ "pxa3xx-pwri2c",REGS_PXA3XX },
{ "ce4100-i2c",   REGS_CE4100 },
+   { "pxa910-i2c",   REGS_PXA910 },
{ },


You add a new platform_id...


@@ -1135,7 +1170,7 @@ static const struct i2c_algorithm i2c_pxa_pio_algorithm = 
{
  static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
-   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA2XX },
+   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
{}


...but change the compatible binding instead of adding a new one?



Yes, because the offset for both REGS_PXA2XX and REGS_PXA910 are same,
and for REGS_PXA2XX we already have compatible entry "mrvl,pxa-i2c".
And the i2c binding documentation, which says,
for platforms using REGS_PXA2XX, they need to provide additional node
"mrvl,pxa-i2c". Which is confusing :)

Also, when I did git-blame on the driver file to see why "mmp-twsi"
entry has been added without anyone really using it. But I did not find
anything meaningful.
So, from the code it was very clear that, "mmp-twsi" and "pxa-i2c" both
are same, its the code which I am adding here brings difference between 
them.


I tried to find datasheet for the platforms using "mmp-twsi", but was
unlucky.


Thanks,
Vaibhav




Thanks,
Vaibhav
--
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-v5 RESEND 2/5] i2c: pxa: enable/disable i2c module across msg xfer

[Vaibhav Hiremath]

On Saturday 12 September 2015 12:23 AM, Wolfram Sang wrote:

On Mon, Aug 24, 2015 at 11:29:35AM +0530, Vaibhav Hiremath wrote:

From: Yi Zhang 

Enable i2c module/unit before transmission and disable when it
finishes.

why?
It's because the i2c bus may be disturbed if the slave device,
typically a touch, powers on.


I am not convinced, "may disturb" is too weak for me. It would need a
way more detailed description of the problem which makes clear that
this mechanism is the only way to go forward.



Hmm, Ok.
Not sure what else I can bring up here.


Can't you use Runtime PM for that?



I haven't tried it though, I can give a try and check.

Thanks,
Vaibhav

--
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-v5 RESEND 2/5] i2c: pxa: enable/disable i2c module across msg xfer

[Vaibhav Hiremath]

On Saturday 12 September 2015 12:23 AM, Wolfram Sang wrote:

On Mon, Aug 24, 2015 at 11:29:35AM +0530, Vaibhav Hiremath wrote:

From: Yi Zhang <yizh...@marvell.com>

Enable i2c module/unit before transmission and disable when it
finishes.

why?
It's because the i2c bus may be disturbed if the slave device,
typically a touch, powers on.


I am not convinced, "may disturb" is too weak for me. It would need a
way more detailed description of the problem which makes clear that
this mechanism is the only way to go forward.



Hmm, Ok.
Not sure what else I can bring up here.


Can't you use Runtime PM for that?



I haven't tried it though, I can give a try and check.

Thanks,
Vaibhav

--
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-v5 RESEND 3/5] i2c: pxa: Add support for pxa910/988 & new configuration features

[Vaibhav Hiremath]

On Saturday 12 September 2015 12:36 AM, Wolfram Sang wrote:

On Mon, Aug 24, 2015 at 11:29:36AM +0530, Vaibhav Hiremath wrote:

TWSI_ILCR & TWSI_IWCR registers are used to adjust clock rate
of standard & fast mode in pxa910/988; so this patch adds these two new
entries to "struct pxa_reg_layout" and "struct pxa_i2c".

As discussed in the previous patch-series, the idea here is to add standard
DT properties for ilcr and iwcr configuration fields.
In case of Master ilcr is used for low/high time and in case of slave mode
of operation iwcr is used for setup/hold time.


I need to rethink how to describe i2c bus timing parameters in DT in the
next days. But this is planned for 4.4., promised.

One thing I already wonder about this one...


  static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa2xx-i2c",   REGS_PXA2XX },
{ "pxa3xx-pwri2c",REGS_PXA3XX },
{ "ce4100-i2c",   REGS_CE4100 },
+   { "pxa910-i2c",   REGS_PXA910 },
{ },


You add a new platform_id...


@@ -1135,7 +1170,7 @@ static const struct i2c_algorithm i2c_pxa_pio_algorithm = 
{
  static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
-   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA2XX },
+   { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
{}


...but change the compatible binding instead of adding a new one?



Yes, because the offset for both REGS_PXA2XX and REGS_PXA910 are same,
and for REGS_PXA2XX we already have compatible entry "mrvl,pxa-i2c".
And the i2c binding documentation, which says,
for platforms using REGS_PXA2XX, they need to provide additional node
"mrvl,pxa-i2c". Which is confusing :)

Also, when I did git-blame on the driver file to see why "mmp-twsi"
entry has been added without anyone really using it. But I did not find
anything meaningful.
So, from the code it was very clear that, "mmp-twsi" and "pxa-i2c" both
are same, its the code which I am adding here brings difference between 
them.


I tried to find datasheet for the platforms using "mmp-twsi", but was
unlucky.


Thanks,
Vaibhav




Thanks,
Vaibhav
--
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 2/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support

[Vaibhav Hiremath]

On Wednesday 09 September 2015 05:19 AM, Rob Herring wrote:

On 09/07/2015 06:18 AM, Vaibhav Hiremath wrote:

With support for pxa1928 family of devices , this patch
updates the binding document with compatible property
of "marvell,pxav3-1928-sdhci".

Signed-off-by: Vaibhav Hiremath 
---
  Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 3d1b449..29edcf5 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 
drivers.

  Required properties:
  - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or
-  "marvell,armada-380-sdhci".
+  "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci".


v3 is implied by pxa1928. So I'd just do "marvell,pxa1928-sdhci" to
better match the chip name.



Ok, No issues.

I followed the existing "armada-380-sdhci" naming style.
Will correct it in next version.


Thanks,
Vaibhav
--
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 2/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support

[Vaibhav Hiremath]

On Wednesday 09 September 2015 05:19 AM, Rob Herring wrote:

On 09/07/2015 06:18 AM, Vaibhav Hiremath wrote:

With support for pxa1928 family of devices , this patch
updates the binding document with compatible property
of "marvell,pxav3-1928-sdhci".

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
  Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 3d1b449..29edcf5 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 
drivers.

  Required properties:
  - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or
-  "marvell,armada-380-sdhci".
+  "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci".


v3 is implied by pxa1928. So I'd just do "marvell,pxa1928-sdhci" to
better match the chip name.



Ok, No issues.

I followed the existing "armada-380-sdhci" naming style.
Will correct it in next version.


Thanks,
Vaibhav
--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 08:12 PM, Linus Walleij wrote:

On Mon, Sep 7, 2015 at 1:18 PM, Vaibhav Hiremath
 wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
   - Default (slow/normal) pin state
   - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Kevin Liu 

(...)

+   pxa->pinctrl = devm_pinctrl_get(dev);
+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");
+   pxa->pins_fast = pinctrl_lookup_state(pxa->pinctrl, "fast");
+   if (IS_ERR(pxa->pins_fast))
+   dev_info(dev, "could not get fast pinstate\n");
+   }


This is exactly how I think it should be used from a pin control
point of view.

If you depended on CONFIG_PM you could use
pinctrl_pm_select_default_state() but for this simple scenario
this is fine.

Reviewed-by: Linus Walleij 
 From a pinctrl point of view.




Thanks for your review.

Linus,

I agree this is how it should be used.
But I still have one small doubt on expectation from
devm_pinctrl_get() function.


If pinctrl properties are not populated in Devicetree node,
then, shouldn't devm_pinctrl_get() return error ?
I followed the code flow, and it seems even if pinctrl properties are
not populated in DT node, the devm_pinctrl_get() returns valid
pointer to "struct pinctrl", isn't this against the expectation of the
call?


Code flow -

devm_pinctrl_get()
...
--> creat_pinctrl()
--> pinctrl_dt_to_map()
...



pinctrl_dt_to_map() iterates for pinctrl-x (x = 0,1,...) and if it
founds the entry then it parses the node. If it doesn't find any
pinctrl property then also it returns 0. and subsequently rreturns
handle to "struct pinctrl" for the device. Why is so?


Thanks,
Vaibhav
--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 03:34 PM, Jisheng Zhang wrote:

On Tue, 8 Sep 2015 15:32:34 +0530
Vaibhav Hiremath  wrote:




On Tuesday 08 September 2015 03:22 PM, Jisheng Zhang wrote:

On Tue, 8 Sep 2015 15:04:41 +0530
Vaibhav Hiremath  wrote:






static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}

+   pxa->pinctrl = devm_pinctrl_get(dev);


could we ignore this for those SDHCI hosts that don't need it?



Again, no need to introduce flags here. This is standard call and
handled properly. So for the platforms not using this, it really should
not matter.
Also, lookup is getting executed only when pinctrl is populated.

So I do not see any need here.


+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");


Why those SDHCI hosts that don't need pinctl setting should got this error?



It won't.


It does. On Marvell Berlin SoCs, I got

[1.07] sdhci-pxav3 f7ab0800.sdhci: could not get default pinstate
[1.08] sdhci-pxav3 f7ab0800.sdhci: could not get fast pinstate





If Host does not need pinctrl, the execution would never reach this
point.
The if condition check would handle it, isn't it?

pxa->pinctrl = devm_pinctrl_get(dev);


It seems this function always succeed...



Not always.
I would succeed only if you have pinctrl defined in DT for this device.


Yes, that's what I thought, but I got

[1.07] sdhci-pxav3 f7ab0800.sdhci: could not get default pinstate
[1.08] sdhci-pxav3 f7ab0800.sdhci: could not get fast pinstate

there's no pinctrl for f7ab0800.sdhci. Am I missing somthing?

Thanks,
Jisheng



And if you have pinctrl defined, isn't it is expected to have "default"
pin state to be always present?
And if answer is yes here, then it is fair to be prompting error for it.


  From another side, we may have default pin in dts, for example: pin muxed 
between
emmc and nandflash. But we don't have fast pinstate, so we at least need the
flag to fast pinstate. Otherwise, in such platforms, we could get something like



That is exactly the reason behind keeping it as dev_info.


[1.00] sdhci-pxav3 f7ab.sdhci: get default pinstate
[1.00] sdhci-pxav3 f7ab.sdhci: could not get fast pinstate




I did some invastigation here on the execution flow,
and you know what, you are right here.

It seems, devm_pinctrl_get() always returns valid pinctrl pointer, even
though the DT property is not populated.

The return value from I did some invastigation () should have been 
treated differently, but it is not. Instead it creates the

"struct pinctrl" and return back to the driver.

I am looping Linus Walleji here, probably he can comment/confirm on
this.


Thanks,
Vaibhav



Thanks,
Vaibhav



--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 03:22 PM, Jisheng Zhang wrote:

On Tue, 8 Sep 2015 15:04:41 +0530
Vaibhav Hiremath  wrote:




On Tuesday 08 September 2015 12:22 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:38 +0530
Vaibhav Hiremath  wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
- Default (slow/normal) pin state
- And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Kevin Liu 
---
   drivers/mmc/host/sdhci-pxav3.c | 45 
+-
   1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
   #include 
   #include 
   #include 
+#include 

   #include "sdhci.h"
   #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
   };

   static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
   }

+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
   static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int 
uhs)
   {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);


return pxav3_select_pinstate(host, uhs);?



Its void function, so don't need it.


Can you please have a look at the function?

static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)



I was referring to pxav3_set_uhs_signaling().
It is void, so what you are suggesting would generate warning.




And could we ignore this call for those SDHCI hosts that don't need it?



I do not want to introduce flags here.
And also, it is already ignored for those who don't need it.

The first thing in the function pxav3_select_pinstate() is


if (IS_ERR(pxa->pinctrl) ||
IS_ERR(pxa->pins_default) ||
IS_ERR(pxa->pins_fast))
return -EINVAL;


So its already handled.


   }

   static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-


why not fix this in patch 3?



Oops. it got missed from my eyes :)
Will fix in next version.


   }

   static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}

+   pxa->pinctrl = devm_pinctrl_get(dev);


could we ignore this for those SDHCI hosts that don't need it?



Again, no need to introduce flags here. This is standard call and
handled properly. So for the platforms not using this, it really should
not matter.
Also, lookup is getting executed only when pinctrl is populated.

So I do not see any need here.


+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");


Why those SDHCI hosts that don't need pinctl setting should got this error?



It won't.


It does. On Marvell Berlin SoCs, I got

[1.07] sdhci-pxav3 f7ab080

Re: [PATCH-v2 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 12:24 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:38 +0530
Vaibhav Hiremath  wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
   - Default (slow/normal) pin state
   - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Kevin Liu 
---
  drivers/mmc/host/sdhci-pxav3.c | 45 +-
  1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "sdhci.h"
  #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
  };

  static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
  }

+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:


Are you sure this IP can support HS400?


+   pinctrl = pxa->pins_fast;



No it does not.

The reason I put it here is,
code under discussion is related to pinctrl configuration, so for all
higher bus speed mode we want to set pins into fast mode.

And from hs400 perspective, I would expect it must get handled much
before than this stage and should not reach here at all.

So this portion of the code is complete in itself.

I hope I clarified your doubt.

Thanks,
Vaibhav
--
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 5/7] mmc: sdhci-pxav3: Fix HS200 mode support

[Vaibhav Hiremath]

On Tuesday 08 September 2015 12:23 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:39 +0530
Vaibhav Hiremath  wrote:


From: Kevin Liu 

IN case of MMC HS200 mode, current code does not enable
SD_CE_ATA_2.MMC_HS200 & SD_CE_ATA_2.MMC_CARD bit configurations.

So this patch updates the above bit fields correctly.

Signed-off-by: Tim Wang 
Signed-off-by: Kevin Liu 
Signed-off-by: Vaibhav Hiremath 
---
Note: Unfortunately I do not have access to any other datasheets
which uses sdhci-pxav3 driver, so quite not sure whether this would
break any existing platform, probably NOT, as I do not see any
references for this change.
If anyone can confirm that would be really great.

  drivers/mmc/host/sdhci-pxav3.c | 17 +
  1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d933f75..6978810 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,8 @@
  #define SD_CE_ATA_1   0x10C

  #define SD_CE_ATA_2   0x10E
+#define  SD_CE_ATA2_HS200_EN   BIT(10)
+#define  SD_CE_ATA2_MMC_MODE   BIT(12)
  #define  SDCE_MISC_INTBIT(2)
  #define  SDCE_MISC_INT_EN BIT(1)

@@ -330,6 +332,17 @@ static int pxav3_select_pinstate(struct sdhci_host *host, 
unsigned int uhs)
return pinctrl_select_state(pxa->pinctrl, pinctrl);
  }

+static int pxav3_select_hs200(struct sdhci_host *host)


I didn't see why we need the return value, make it void would be better?



Fair enough.
Will fix it in next version.


Thanks,
Vaibhav
--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 12:22 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:38 +0530
Vaibhav Hiremath  wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
   - Default (slow/normal) pin state
   - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Kevin Liu 
---
  drivers/mmc/host/sdhci-pxav3.c | 45 +-
  1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "sdhci.h"
  #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
  };

  static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
  }

+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
  static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
  {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);


return pxav3_select_pinstate(host, uhs);?



Its void function, so don't need it.


And could we ignore this call for those SDHCI hosts that don't need it?



I do not want to introduce flags here.
And also, it is already ignored for those who don't need it.

The first thing in the function pxav3_select_pinstate() is


if (IS_ERR(pxa->pinctrl) ||
IS_ERR(pxa->pins_default) ||
IS_ERR(pxa->pins_fast))
return -EINVAL;


So its already handled.


  }

  static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-


why not fix this in patch 3?



Oops. it got missed from my eyes :)
Will fix in next version.


  }

  static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}

+   pxa->pinctrl = devm_pinctrl_get(dev);


could we ignore this for those SDHCI hosts that don't need it?



Again, no need to introduce flags here. This is standard call and
handled properly. So for the platforms not using this, it really should
not matter.
Also, lookup is getting executed only when pinctrl is populated.

So I do not see any need here.


+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");


Why those SDHCI hosts that don't need pinctl setting should got this error?



It won't.

If Host does not need pinctrl, the execution would never reach this
point.
The if condition check would handle it, isn't it?

pxa->pinctrl = devm_pinctrl_get(dev);
if (!IS_ERR(pxa->pinctrl)) {

...

}

So I do not see why is it issue here?


Thanks,
Vaibhav
--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 12:22 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:38 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
   - Default (slow/normal) pin state
   - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
Signed-off-by: Kevin Liu <kl...@marvell.com>
---
  drivers/mmc/host/sdhci-pxav3.c | 45 +-
  1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "sdhci.h"
  #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
  };

  static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
  }

+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
  static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
  {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);


return pxav3_select_pinstate(host, uhs);?



Its void function, so don't need it.


And could we ignore this call for those SDHCI hosts that don't need it?



I do not want to introduce flags here.
And also, it is already ignored for those who don't need it.

The first thing in the function pxav3_select_pinstate() is


if (IS_ERR(pxa->pinctrl) ||
IS_ERR(pxa->pins_default) ||
IS_ERR(pxa->pins_fast))
return -EINVAL;


So its already handled.


  }

  static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-


why not fix this in patch 3?



Oops. it got missed from my eyes :)
Will fix in next version.


  }

  static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}

+   pxa->pinctrl = devm_pinctrl_get(dev);


could we ignore this for those SDHCI hosts that don't need it?



Again, no need to introduce flags here. This is standard call and
handled properly. So for the platforms not using this, it really should
not matter.
Also, lookup is getting executed only when pinctrl is populated.

So I do not see any need here.


+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");


Why those SDHCI hosts that don't need pinctl setting should got this error?



It won't.

If Host does not need pinctrl, the execution would never reach this
point.
The if condition check would handle it, isn't it?

pxa->pinctrl = devm_pinctrl_get(dev);
if (!IS_ERR(pxa->pinctrl)) {

...

}

So I do not see why is it issue here?


Thanks,
Vaibhav
--
To unsubscribe from this list: send the line &q

Re: [PATCH-v2 5/7] mmc: sdhci-pxav3: Fix HS200 mode support

[Vaibhav Hiremath]

On Tuesday 08 September 2015 12:23 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:39 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:


From: Kevin Liu <kl...@marvell.com>

IN case of MMC HS200 mode, current code does not enable
SD_CE_ATA_2.MMC_HS200 & SD_CE_ATA_2.MMC_CARD bit configurations.

So this patch updates the above bit fields correctly.

Signed-off-by: Tim Wang <wan...@marvell.com>
Signed-off-by: Kevin Liu <kl...@marvell.com>
Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
Note: Unfortunately I do not have access to any other datasheets
which uses sdhci-pxav3 driver, so quite not sure whether this would
break any existing platform, probably NOT, as I do not see any
references for this change.
If anyone can confirm that would be really great.

  drivers/mmc/host/sdhci-pxav3.c | 17 +
  1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d933f75..6978810 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,8 @@
  #define SD_CE_ATA_1   0x10C

  #define SD_CE_ATA_2   0x10E
+#define  SD_CE_ATA2_HS200_EN   BIT(10)
+#define  SD_CE_ATA2_MMC_MODE   BIT(12)
  #define  SDCE_MISC_INTBIT(2)
  #define  SDCE_MISC_INT_EN BIT(1)

@@ -330,6 +332,17 @@ static int pxav3_select_pinstate(struct sdhci_host *host, 
unsigned int uhs)
return pinctrl_select_state(pxa->pinctrl, pinctrl);
  }

+static int pxav3_select_hs200(struct sdhci_host *host)


I didn't see why we need the return value, make it void would be better?



Fair enough.
Will fix it in next version.


Thanks,
Vaibhav
--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 03:22 PM, Jisheng Zhang wrote:

On Tue, 8 Sep 2015 15:04:41 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:




On Tuesday 08 September 2015 12:22 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:38 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
- Default (slow/normal) pin state
- And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
Signed-off-by: Kevin Liu <kl...@marvell.com>
---
   drivers/mmc/host/sdhci-pxav3.c | 45 
+-
   1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
   #include 
   #include 
   #include 
+#include 

   #include "sdhci.h"
   #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
   };

   static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
   }

+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
   static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int 
uhs)
   {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);


return pxav3_select_pinstate(host, uhs);?



Its void function, so don't need it.


Can you please have a look at the function?

static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)



I was referring to pxav3_set_uhs_signaling().
It is void, so what you are suggesting would generate warning.




And could we ignore this call for those SDHCI hosts that don't need it?



I do not want to introduce flags here.
And also, it is already ignored for those who don't need it.

The first thing in the function pxav3_select_pinstate() is


if (IS_ERR(pxa->pinctrl) ||
IS_ERR(pxa->pins_default) ||
IS_ERR(pxa->pins_fast))
return -EINVAL;


So its already handled.


   }

   static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-


why not fix this in patch 3?



Oops. it got missed from my eyes :)
Will fix in next version.


   }

   static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}

+   pxa->pinctrl = devm_pinctrl_get(dev);


could we ignore this for those SDHCI hosts that don't need it?



Again, no need to introduce flags here. This is standard call and
handled properly. So for the platforms not using this, it really should
not matter.
Also, lookup is getting executed only when pinctrl is populated.

So I do not see any need here.


+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");


Why those SDHCI hosts that don't

Re: [PATCH-v2 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 03:34 PM, Jisheng Zhang wrote:

On Tue, 8 Sep 2015 15:32:34 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:




On Tuesday 08 September 2015 03:22 PM, Jisheng Zhang wrote:

On Tue, 8 Sep 2015 15:04:41 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:






static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}

+   pxa->pinctrl = devm_pinctrl_get(dev);


could we ignore this for those SDHCI hosts that don't need it?



Again, no need to introduce flags here. This is standard call and
handled properly. So for the platforms not using this, it really should
not matter.
Also, lookup is getting executed only when pinctrl is populated.

So I do not see any need here.


+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");


Why those SDHCI hosts that don't need pinctl setting should got this error?



It won't.


It does. On Marvell Berlin SoCs, I got

[1.07] sdhci-pxav3 f7ab0800.sdhci: could not get default pinstate
[1.08] sdhci-pxav3 f7ab0800.sdhci: could not get fast pinstate





If Host does not need pinctrl, the execution would never reach this
point.
The if condition check would handle it, isn't it?

pxa->pinctrl = devm_pinctrl_get(dev);


It seems this function always succeed...



Not always.
I would succeed only if you have pinctrl defined in DT for this device.


Yes, that's what I thought, but I got

[1.07] sdhci-pxav3 f7ab0800.sdhci: could not get default pinstate
[1.08] sdhci-pxav3 f7ab0800.sdhci: could not get fast pinstate

there's no pinctrl for f7ab0800.sdhci. Am I missing somthing?

Thanks,
Jisheng



And if you have pinctrl defined, isn't it is expected to have "default"
pin state to be always present?
And if answer is yes here, then it is fair to be prompting error for it.


  From another side, we may have default pin in dts, for example: pin muxed 
between
emmc and nandflash. But we don't have fast pinstate, so we at least need the
flag to fast pinstate. Otherwise, in such platforms, we could get something like



That is exactly the reason behind keeping it as dev_info.


[1.00] sdhci-pxav3 f7ab.sdhci: get default pinstate
[1.00] sdhci-pxav3 f7ab.sdhci: could not get fast pinstate




I did some invastigation here on the execution flow,
and you know what, you are right here.

It seems, devm_pinctrl_get() always returns valid pinctrl pointer, even
though the DT property is not populated.

The return value from I did some invastigation () should have been 
treated differently, but it is not. Instead it creates the

"struct pinctrl" and return back to the driver.

I am looping Linus Walleji here, probably he can comment/confirm on
this.


Thanks,
Vaibhav



Thanks,
Vaibhav



--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 12:24 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 16:48:38 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
   - Default (slow/normal) pin state
   - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
Signed-off-by: Kevin Liu <kl...@marvell.com>
---
  drivers/mmc/host/sdhci-pxav3.c | 45 +-
  1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "sdhci.h"
  #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
  };

  static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
  }

+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:


Are you sure this IP can support HS400?


+   pinctrl = pxa->pins_fast;



No it does not.

The reason I put it here is,
code under discussion is related to pinctrl configuration, so for all
higher bus speed mode we want to set pins into fast mode.

And from hs400 perspective, I would expect it must get handled much
before than this stage and should not reach here at all.

So this portion of the code is complete in itself.

I hope I clarified your doubt.

Thanks,
Vaibhav
--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

On Tuesday 08 September 2015 08:12 PM, Linus Walleij wrote:

On Mon, Sep 7, 2015 at 1:18 PM, Vaibhav Hiremath
<vaibhav.hirem...@linaro.org> wrote:


Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
   - Default (slow/normal) pin state
   - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
Signed-off-by: Kevin Liu <kl...@marvell.com>

(...)

+   pxa->pinctrl = devm_pinctrl_get(dev);
+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");
+   pxa->pins_fast = pinctrl_lookup_state(pxa->pinctrl, "fast");
+   if (IS_ERR(pxa->pins_fast))
+   dev_info(dev, "could not get fast pinstate\n");
+   }


This is exactly how I think it should be used from a pin control
point of view.

If you depended on CONFIG_PM you could use
pinctrl_pm_select_default_state() but for this simple scenario
this is fine.

Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
 From a pinctrl point of view.




Thanks for your review.

Linus,

I agree this is how it should be used.
But I still have one small doubt on expectation from
devm_pinctrl_get() function.


If pinctrl properties are not populated in Devicetree node,
then, shouldn't devm_pinctrl_get() return error ?
I followed the code flow, and it seems even if pinctrl properties are
not populated in DT node, the devm_pinctrl_get() returns valid
pointer to "struct pinctrl", isn't this against the expectation of the
call?


Code flow -

devm_pinctrl_get()
...
--> creat_pinctrl()
--> pinctrl_dt_to_map()
...



pinctrl_dt_to_map() iterates for pinctrl-x (x = 0,1,...) and if it
founds the entry then it parses the node. If it doesn't find any
pinctrl property then also it returns 0. and subsequently rreturns
handle to "struct pinctrl" for the device. Why is so?


Thanks,
Vaibhav
--
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 1/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

On Monday 07 September 2015 05:26 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 17:01:09 +0530
Vaibhav Hiremath  wrote:


There were some coding style issues where spaces have been used instead
of tabs, for example, in macro definitions, alignment of function
declarations/definitions, etc...

This patch fixes all such occurrences in the code.

Signed-off-by: Vaibhav Hiremath 
---
  drivers/mmc/host/sdhci-pxav3.c | 46 +-
  1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 946d37f..7a07177 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -39,24 +39,24 @@
  #include "sdhci.h"
  #include "sdhci-pltfm.h"

-#define PXAV3_RPM_DELAY_MS 50
+#define PXAV3_RPM_DELAY_MS 50

-#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define SDCLK_DELAY_SHIFT  9
-#define SDCLK_DELAY_MASK   0x1f
+#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
+#define SDCLK_SEL  0x100
+#define  SDCLK_DELAY_SHIFT 9
+#define  SDCLK_DELAY_MASK  0x1f

-#define SD_CFG_FIFO_PARAM   0x100
-#define SDCFG_GEN_PAD_CLK_ON   (1<<6)
-#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
-#define SDCFG_GEN_PAD_CLK_CNT_SHIFT24
+#define SD_CFG_FIFO_PARAM  0x100
+#define  SDCFG_GEN_PAD_CLK_ON  (1<<6)
+#define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
+#define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24

-#define SD_SPI_MODE  0x108
-#define SD_CE_ATA_1  0x10C
+#define SD_SPI_MODE0x108
+#define SD_CE_ATA_10x10C

-#define SD_CE_ATA_2  0x10E
-#define SDCE_MISC_INT  (1<<2)
-#define SDCE_MISC_INT_EN   (1<<1)
+#define SD_CE_ATA_20x10E
+#define  SDCE_MISC_INT (1<<2)
+#define  SDCE_MISC_INT_EN  (1<<1)

  struct sdhci_pxa {
struct clk *clk_core;
@@ -284,7 +284,7 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 * FE-2946959
 */
if (pxa->sdio3_conf_reg) {
-   u8 reg_val  = readb(pxa->sdio3_conf_reg);
+   u8 reg_val = readb(pxa->sdio3_conf_reg);

if (uhs == MMC_TIMING_UHS_SDR50 ||
uhs == MMC_TIMING_UHS_DDR50) {
@@ -304,20 +304,20 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
  }

  static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock = sdhci_set_clock,
-   .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
-   .get_max_clock = sdhci_pltfm_clk_get_max_clock,
-   .set_bus_width = sdhci_set_bus_width,
-   .reset = pxav3_reset,
-   .set_uhs_signaling = pxav3_set_uhs_signaling,
+   .set_clock  = sdhci_set_clock,
+   .platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
+   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .set_bus_width  = sdhci_set_bus_width,
+   .reset  = pxav3_reset,
+   .set_uhs_signaling  = pxav3_set_uhs_signaling,


IMHO, this is not an improvement, previous style is fine and I saw
such style in kernel here and there



I had received feedback to use above style on different patch-series.
And I also think this looks more clean and readable.

Thanks,
Vaibhav
--
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 3/3] mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn

[Vaibhav Hiremath]

This patch adds kernel notice/message to sdhci_host_add() fn on
-EPROBE_DEFER.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1dbe932..37a5cd5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3130,8 +3130,11 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->caps |= MMC_CAP_NEEDS_POLL;
 
/* If there are external regulators, get them */
-   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER) {
+   pr_notice("%s: regulator supply unavailable, deferring 
probe.\n",
+   mmc_hostname(mmc));
return -EPROBE_DEFER;
+   }
 
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
if (!IS_ERR(mmc->supply.vqmmc)) {
-- 
1.9.1

--
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 1/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

There were some coding style issues where spaces have been used instead
of tabs, for example, in macro definitions, alignment of function
declarations/definitions, etc...

This patch fixes all such occurrences in the code.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 946d37f..7a07177 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -39,24 +39,24 @@
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
 
-#define PXAV3_RPM_DELAY_MS 50
+#define PXAV3_RPM_DELAY_MS 50
 
-#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define SDCLK_DELAY_SHIFT  9
-#define SDCLK_DELAY_MASK   0x1f
+#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
+#define SDCLK_SEL  0x100
+#define  SDCLK_DELAY_SHIFT 9
+#define  SDCLK_DELAY_MASK  0x1f
 
-#define SD_CFG_FIFO_PARAM   0x100
-#define SDCFG_GEN_PAD_CLK_ON   (1<<6)
-#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
-#define SDCFG_GEN_PAD_CLK_CNT_SHIFT24
+#define SD_CFG_FIFO_PARAM  0x100
+#define  SDCFG_GEN_PAD_CLK_ON  (1<<6)
+#define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
+#define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
-#define SD_SPI_MODE  0x108
-#define SD_CE_ATA_1  0x10C
+#define SD_SPI_MODE0x108
+#define SD_CE_ATA_10x10C
 
-#define SD_CE_ATA_2  0x10E
-#define SDCE_MISC_INT  (1<<2)
-#define SDCE_MISC_INT_EN   (1<<1)
+#define SD_CE_ATA_20x10E
+#define  SDCE_MISC_INT (1<<2)
+#define  SDCE_MISC_INT_EN  (1<<1)
 
 struct sdhci_pxa {
struct clk *clk_core;
@@ -284,7 +284,7 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 * FE-2946959
 */
if (pxa->sdio3_conf_reg) {
-   u8 reg_val  = readb(pxa->sdio3_conf_reg);
+   u8 reg_val = readb(pxa->sdio3_conf_reg);
 
if (uhs == MMC_TIMING_UHS_SDR50 ||
uhs == MMC_TIMING_UHS_DDR50) {
@@ -304,20 +304,20 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 }
 
 static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock = sdhci_set_clock,
-   .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
-   .get_max_clock = sdhci_pltfm_clk_get_max_clock,
-   .set_bus_width = sdhci_set_bus_width,
-   .reset = pxav3_reset,
-   .set_uhs_signaling = pxav3_set_uhs_signaling,
+   .set_clock  = sdhci_set_clock,
+   .platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
+   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .set_bus_width  = sdhci_set_bus_width,
+   .reset  = pxav3_reset,
+   .set_uhs_signaling  = pxav3_set_uhs_signaling,
 };
 
 static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
-   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
+   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
| SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC
| SDHCI_QUIRK_32BIT_ADMA_SIZE
| SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
-   .ops = _sdhci_ops,
+   .ops= _sdhci_ops,
 };
 
 #ifdef CONFIG_OF
-- 
1.9.1

--
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 0/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

Trivial patch-series, which fixes the tabbing issue in the driver,
uses the BIT macro for bit fields and prints notice on -EPROBE_DEFER
in sdhci_add_host() function on regulator unavailability.

V1 => V2

 - Fixed all comments from Joe, mostly alignment changes
 - Separated BIT macro usage patch into new one.
 - changed error to kernel notice for EPROBE_DEFER in sdhci_add_host()

Note: This patch-series should get merged before another series -

[PATCH-v2 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

Vaibhav Hiremath (3):
  mmc: sdhci-pxav3: Fix tabbing issue
  mmc: sdhci-pxav3: Use BIT macro for bit field definitions
  mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn

 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 drivers/mmc/host/sdhci.c   |  5 -
 2 files changed, 27 insertions(+), 24 deletions(-)

-- 
1.9.1

--
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 2/3] mmc: sdhci-pxav3: Use BIT macro for bit field definitions

[Vaibhav Hiremath]

Instead of using shift operation use BIT macro for bit field
definitions.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 7a07177..a8a8c94 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -47,7 +47,7 @@
 #define  SDCLK_DELAY_MASK  0x1f
 
 #define SD_CFG_FIFO_PARAM  0x100
-#define  SDCFG_GEN_PAD_CLK_ON  (1<<6)
+#define  SDCFG_GEN_PAD_CLK_ON  BIT(6)
 #define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
 #define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
@@ -55,8 +55,8 @@
 #define SD_CE_ATA_10x10C
 
 #define SD_CE_ATA_20x10E
-#define  SDCE_MISC_INT (1<<2)
-#define  SDCE_MISC_INT_EN  (1<<1)
+#define  SDCE_MISC_INT BIT(2)
+#define  SDCE_MISC_INT_EN  BIT(1)
 
 struct sdhci_pxa {
struct clk *clk_core;
-- 
1.9.1

--
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 1/7] mmc: sdhci-pxav3: Enable pxa1928 device support

[Vaibhav Hiremath]

SDHCI controller present in PXA1928 has few differences as far as
register map is concerned.
For example,

 PXAxxxPXA1928
 =====
 SDCLK_DELAY field   0x10A 0x114
 SDCLK_DELAY mask0x1F  0x3FF
 SDCLK_DELAY shift9  8
 SDCLK_SEL shift  8  2 (SEL1)

So in order to support multi-platform, use sdhci_pxa_regdata structure
as a variant data according to platform.

Note that, there are some more differences, which would be added
as and when respective feature gets added to the driver.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 62 ++
 1 file changed, 51 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 6d4bad4..aecae04 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -42,9 +42,6 @@
 #define PXAV3_RPM_DELAY_MS 50
 
 #define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define  SDCLK_DELAY_SHIFT 9
-#define  SDCLK_DELAY_MASK  0x1f
 
 #define SD_CFG_FIFO_PARAM  0x100
 #define  SDCFG_GEN_PAD_CLK_ON  BIT(6)
@@ -58,11 +55,25 @@
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
+#define SD_RX_CFG_REG  0x114
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
 #define IO_PWR_MMC1_PAD_1V8BIT(2)
 
+struct sdhci_pxa_data {
+   u32 sdclk_delay_reg;
+   u32 sdclk_delay_mask;
+   u8 sdclk_delay_shift;
+   u8 sdclk_sel_mask;
+   u8 sdclk_sel_shift;
+   /*
+* We have few more differences, add them along with their
+* respective feature support
+*/
+};
+
 struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
@@ -70,6 +81,24 @@ struct sdhci_pxa {
void __iomem *sdio3_conf_reg;
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
+   struct sdhci_pxa_data *data;
+};
+
+static struct sdhci_pxa_data pxav3_data_v1 = {
+   .sdclk_delay_reg= SD_CLOCK_BURST_SIZE_SETUP,
+   .sdclk_delay_mask   = 0x1F,
+   .sdclk_delay_shift  = 9,
+   .sdclk_sel_mask = 0x1,
+   .sdclk_sel_shift= 8,
+};
+
+static struct sdhci_pxa_data pxav3_data_v2 = {
+   .sdclk_delay_reg= SD_RX_CFG_REG,
+   .sdclk_delay_mask   = 0x3FF,
+   .sdclk_delay_shift  = 8,
+   /* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
+   .sdclk_sel_mask = 0x3,
+   .sdclk_sel_shift= 2,/* SDCLK_SEL1 */
 };
 
 /*
@@ -183,6 +212,8 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 {
struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
 
sdhci_reset(host, mask);
 
@@ -193,12 +224,14 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 */
if (pdata && 0 != pdata->clk_delay_cycles) {
u16 tmp;
-
-   tmp = readw(host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
-   tmp |= (pdata->clk_delay_cycles & SDCLK_DELAY_MASK)
-   << SDCLK_DELAY_SHIFT;
-   tmp |= SDCLK_SEL;
-   writew(tmp, host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
+   struct sdhci_pxa_data *data = pxa->data;
+
+   tmp = readw(host->ioaddr + data->sdclk_delay_reg);
+   tmp |= (pdata->clk_delay_cycles & 
data->sdclk_delay_mask)
+   << data->sdclk_delay_shift;
+   tmp &= ~(data->sdclk_sel_mask << data->sdclk_sel_shift);
+   tmp |= 1 << data->sdclk_sel_shift;
+   writew(tmp, host->ioaddr + data->sdclk_delay_reg);
}
}
 }
@@ -363,10 +396,16 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
 #ifdef CONFIG_OF
 static const struct of_device_id sdhci_pxav3_of_match[] = {
{
-   .compatible = "mrvl,pxav3-mmc",
+   .compatible = "mrvl,pxav3-mmc",
+   .data   = (void *)_data_v1,
+   },
+   {
+   .compatible = "marvell,armada-380-sdhci",
+   .data   = (void *)_data_v1,
},
{
-   .compatible = "marvel

[PATCH-v2 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
  - Default (slow/normal) pin state
  - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Kevin Liu 
---
 drivers/mmc/host/sdhci-pxav3.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
 };
 
 static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
 }
 
+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);
 }
 
 static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-
 }
 
 static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}
 
+   pxa->pinctrl = devm_pinctrl_get(dev);
+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");
+   pxa->pins_fast = pinctrl_lookup_state(pxa->pinctrl, "fast");
+   if (IS_ERR(pxa->pins_fast))
+   dev_info(dev, "could not get fast pinstate\n");
+   }
+
pm_runtime_get_noresume(>dev);
pm_runtime_set_active(>dev);
pm_runtime_set_autosuspend_delay(>dev, PXAV3_RPM_DELAY_MS);
-- 
1.9.1

--
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 2/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support

[Vaibhav Hiremath]

With support for pxa1928 family of devices , this patch
updates the binding document with compatible property
of "marvell,pxav3-1928-sdhci".

Signed-off-by: Vaibhav Hiremath 
---
 Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 3d1b449..29edcf5 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 
drivers.
 
 Required properties:
 - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or
-  "marvell,armada-380-sdhci".
+  "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci".
 - reg:
   * for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for
 the SDHCI registers.
-- 
1.9.1

--
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 6/7] mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

[Vaibhav Hiremath]

IN case of Marvell 1928 family of devices, the SD_BUS_POWER and
SD_BUS_VLT bits are used internally to gate the clocks, so
we have to set these fields.

Pasting Spec words here,

The  and  fields should be configured
to correct values. These actually do not do the voltage selection
or switch power to the SD card. However these fields are used
internally to gate the clock. So if these fields are set
incorrectly, SD module will not function.

And during my development, I have seen that SD card wouldn't function
without right configuration into these fields.

So this patch adds new quirk (SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER),
which make sure that ->set_power() sets these fields.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pltfm.c | 3 +++
 drivers/mmc/host/sdhci.c   | 3 ++-
 drivers/mmc/host/sdhci.h   | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index a207f5a..5788a8c 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -101,6 +101,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
of_device_is_compatible(np, "fsl,mpc8536-esdhc"))
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
+   if (of_device_is_compatible(np, "marvell,pxav3-1928-sdhci"))
+   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER;
+
clk = of_get_property(np, "clock-frequency", );
if (clk && size == sizeof(*clk) && *clk)
pltfm_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2d58b31..418f381 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1265,7 +1265,8 @@ static void sdhci_set_power(struct sdhci_host *host, 
unsigned char mode,
else
sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
 
-   return;
+   if (!(host->quirks2 | SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER))
+   return;
}
 
if (mode != MMC_POWER_OFF) {
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 9b0e2a8..8802a0c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -409,6 +409,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_SUPPORT_SINGLE(1<<13)
 /* Controller broken with using ACMD23 */
 #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14)
+/* Voltage capabilities of Controller must be set  */
+#define SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER  (1<<15)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
1.9.1

--
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 5/7] mmc: sdhci-pxav3: Fix HS200 mode support

[Vaibhav Hiremath]

From: Kevin Liu 

IN case of MMC HS200 mode, current code does not enable
SD_CE_ATA_2.MMC_HS200 & SD_CE_ATA_2.MMC_CARD bit configurations.

So this patch updates the above bit fields correctly.

Signed-off-by: Tim Wang 
Signed-off-by: Kevin Liu 
Signed-off-by: Vaibhav Hiremath 
---
Note: Unfortunately I do not have access to any other datasheets
which uses sdhci-pxav3 driver, so quite not sure whether this would
break any existing platform, probably NOT, as I do not see any
references for this change.
If anyone can confirm that would be really great.

 drivers/mmc/host/sdhci-pxav3.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d933f75..6978810 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,8 @@
 #define SD_CE_ATA_10x10C
 
 #define SD_CE_ATA_20x10E
+#define  SD_CE_ATA2_HS200_EN   BIT(10)
+#define  SD_CE_ATA2_MMC_MODE   BIT(12)
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
@@ -330,6 +332,17 @@ static int pxav3_select_pinstate(struct sdhci_host *host, 
unsigned int uhs)
return pinctrl_select_state(pxa->pinctrl, pinctrl);
 }
 
+static int pxav3_select_hs200(struct sdhci_host *host)
+{
+   u16 reg = 0;
+
+   reg = sdhci_readw(host, SD_CE_ATA_2);
+   reg |= SD_CE_ATA2_HS200_EN | SD_CE_ATA2_MMC_MODE;
+   sdhci_writew(host, reg, SD_CE_ATA_2);
+
+   return 0;
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -361,6 +374,10 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
case MMC_TIMING_UHS_DDR50:
ctrl_2 |= SDHCI_CTRL_UHS_DDR50 | SDHCI_CTRL_VDD_180;
break;
+   case MMC_TIMING_MMC_HS200:
+   ctrl_2 |= SDHCI_CTRL_UHS_SDR104 | SDHCI_CTRL_VDD_180;
+   pxav3_select_hs200(host);
+   break;
}
 
/*
-- 
1.9.1

--
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 7/7] mmc: sdhci: enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON for pxa1928

[Vaibhav Hiremath]

Card power is dependent on bus power, without that card
wouldn't respond (No CARD_INT). So this patch enables the
quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pltfm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 5788a8c..057190c 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -102,7 +102,8 @@ void sdhci_get_of_property(struct platform_device *pdev)
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
if (of_device_is_compatible(np, "marvell,pxav3-1928-sdhci"))
-   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER;
+   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER |
+   SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON;
 
clk = of_get_property(np, "clock-frequency", );
if (clk && size == sizeof(*clk) && *clk)
-- 
1.9.1

--
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 3/7] mmc: sdhci-pxav3: Add platform specific set_clock ops

[Vaibhav Hiremath]

In case of PXA1928 & family of devices, the TX BUS and internal clock
need to be set as part of ->set_clock() ops, so this patch adds
platform specific ->set_clock() operation.

Note that, in order to not break other platforms, this patch
introduced the flag, which controls whether controller/platform
specific clock configuration needs to be executed.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index aecae04..c2b2b78 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -48,6 +48,10 @@
 #define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
 #define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
+#define SD_FIFO_PARAM  0x104
+#define  INTERNAL_CLK_GATE_CTRLBIT(8)
+#define  INTERNAL_CLK_GATE_ON  BIT(9)
+
 #define SD_SPI_MODE0x108
 #define SD_CE_ATA_10x10C
 
@@ -57,6 +61,9 @@
 
 #define SD_RX_CFG_REG  0x114
 
+#define TX_CFG_REG 0x118
+#define  TX_INTERNAL_SEL_BUS_CLK   BIT(30)
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
@@ -68,6 +75,9 @@ struct sdhci_pxa_data {
u8 sdclk_delay_shift;
u8 sdclk_sel_mask;
u8 sdclk_sel_shift;
+
+   /* set this if platform needs separate clock configuration */
+   bool set_pltfrm_clk;
/*
 * We have few more differences, add them along with their
 * respective feature support
@@ -90,6 +100,7 @@ static struct sdhci_pxa_data pxav3_data_v1 = {
.sdclk_delay_shift  = 9,
.sdclk_sel_mask = 0x1,
.sdclk_sel_shift= 8,
+   .set_pltfrm_clk = false,
 };
 
 static struct sdhci_pxa_data pxav3_data_v2 = {
@@ -99,6 +110,7 @@ static struct sdhci_pxa_data pxav3_data_v2 = {
/* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
.sdclk_sel_mask = 0x3,
.sdclk_sel_shift= 2,/* SDCLK_SEL1 */
+   .set_pltfrm_clk = true,
 };
 
 /*
@@ -375,8 +387,40 @@ static void pxav3_voltage_switch(struct sdhci_host *host,
writel(val, pxa->io_pwr_reg);
 }
 
+static void pxav3_set_tx_clock(struct sdhci_host *host)
+{
+   u32 val;
+
+   val = sdhci_readl(host, TX_CFG_REG);
+   val |= TX_INTERNAL_SEL_BUS_CLK;
+   sdhci_writel(host, val, TX_CFG_REG);
+}
+
+static void pxav3_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+
+   /* We still use common sdhci_set_clock() */
+   sdhci_set_clock(host, clock);
+
+   /* platform/controller specific clock configuration */
+   if (pxa->data->set_pltfrm_clk && clock != 0) {
+   u32 val;
+
+   val = sdhci_readw(host, SD_FIFO_PARAM);
+   /* Internal clock gate ON and CTRL = 0b11 */
+   val |= INTERNAL_CLK_GATE_CTRL | INTERNAL_CLK_GATE_ON;
+   sdhci_writew(host, val, SD_FIFO_PARAM);
+
+   /* TX internal clock selection */
+   pxav3_set_tx_clock(host);
+   }
+
+}
+
 static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock  = sdhci_set_clock,
+   .set_clock  = pxav3_set_clock,
.platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
.get_max_clock  = sdhci_pltfm_clk_get_max_clock,
.set_bus_width  = sdhci_set_bus_width,
-- 
1.9.1

--
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 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

[Vaibhav Hiremath]

PXA1928 SDHCI controller has few differences, for example,

 PXAxxxPXA1928
 =====
 SDCLK_DELAY field   0x10A 0x114
 SDCLK_DELAY mask0x1F  0x3FF
 SDCLK_DELAY shift9  8
 SDCLK_SEL shift  8  2 (SEL1)

So this patch series introduces new compatible device_id
(marvell,pxav3-1928-sdhci), and makes use of .data for handling
such differences.

The series also adds support like,

 - independent ->set_clock() api, as we need to enable internal clock gate
   and TX clock
 - pinctrl configuration based on bus speed.
 - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER
   SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the
   clocks, so it is important to configure them as part of ->set_power()
   More detailed description is written into commit log.
 - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id
 - Enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk for pxa1928 device


V1 => V2:
=
 - Fixed typo issue (residual change remained by mistake)
 - Added new patch updating DT binding document for pxa1928 support
 - Added new patch enabling CARD_ON_NEEDS_BUS_ON for pxa1928 device

Testing:
I have done basic testing on both eMMC and SD card on PXA1928 based
platform.

Note: I tried to made sure that I do not break any other platform, which
used sdhci, except HS200 configuration.·
Unfortunately I do not have access to any other datasheets, where I can
cross check the details on HS200 bit-fields. Probably someone who has
access can confirm [PATCH 4/5], whether it impacts other platforms.

Kevin Liu (1):
  mmc: sdhci-pxav3: Fix HS200 mode support

Vaibhav Hiremath (6):
  mmc: sdhci-pxav3: Enable pxa1928 device support
  mmc: sdhci-pxav3: binding: Add pxa1928 compatible support
  mmc: sdhci-pxav3: Add platform specific set_clock ops
  mmc: sdhci-pxav3: Add pinctl setting according to bus clock
  mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields
  mmc: sdhci: enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON for pxa1928

 .../devicetree/bindings/mmc/sdhci-pxa.txt  |   2 +-
 drivers/mmc/host/sdhci-pltfm.c |   4 +
 drivers/mmc/host/sdhci-pxav3.c | 168 +++--
 drivers/mmc/host/sdhci.c   |   3 +-
 drivers/mmc/host/sdhci.h   |   2 +
 5 files changed, 165 insertions(+), 14 deletions(-)

-- 
1.9.1

--
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/5] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

[Vaibhav Hiremath]

On Friday 04 September 2015 09:02 PM, Vaibhav Hiremath wrote:

PXA1928 SDHCI controller has few differences, for example,

PXAxxxPXA1928
=====
SDCLK_DELAY field   0x10A 0x114
SDCLK_DELAY mask0x1F  0x3FF
SDCLK_DELAY shift9  8
SDCLK_SEL shift  8  2 (SEL1)

So this patch series introduces new compatible device_id
(marvell,pxav3-1928-sdhci), and makes use of .data for handling
such differences.

The series also adds support like,

  - independent ->set_clock() api, as we need to enable internal clock gate
 and TX clock
  - pinctrl configuration based on bus speed.
  - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER
SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the
clocks, so it is important to configure them as part of ->set_power()
More detailed description is written into commit log.
  - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id



Please ignore this series, as one residual change (rather typo error).
Mistakenly while checking in the code, instead of 1928 compatible
property it was 988.

I will submit the new series shortly.

Thanks,
Vaibhav




Testing:
I have done basic testing on both eMMC and SD card on PXA1928 based
platform.

Note: I tried to made sure that I do not break any other platform, which
used sdhci, except HS200 configuration.
Unfortunately I do not have access to any other datasheets, where I can
cross check the details on HS200 bit-fields. Probably someone who has
access can confirm [PATCH 4/5], whether it impacts other platforms.

Kevin Liu (1):
   mmc: sdhci-pxav3: Fix HS200 mode support

Vaibhav Hiremath (4):
   mmc: sdhci-pxav3: Enable pxa1928 device support
   mmc: sdhci-pxav3: Add platform specific set_clock ops
   mmc: sdhci-pxav3: Add pinctl setting according to bus clock
   mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

  drivers/mmc/host/sdhci-pltfm.c |   3 +
  drivers/mmc/host/sdhci-pxav3.c | 168 ++---
  drivers/mmc/host/sdhci.c   |   3 +-
  drivers/mmc/host/sdhci.h   |   2 +
  4 files changed, 163 insertions(+), 13 deletions(-)


--
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/5] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

[Vaibhav Hiremath]

On Friday 04 September 2015 09:02 PM, Vaibhav Hiremath wrote:

PXA1928 SDHCI controller has few differences, for example,

PXAxxxPXA1928
=====
SDCLK_DELAY field   0x10A 0x114
SDCLK_DELAY mask0x1F  0x3FF
SDCLK_DELAY shift9  8
SDCLK_SEL shift  8  2 (SEL1)

So this patch series introduces new compatible device_id
(marvell,pxav3-1928-sdhci), and makes use of .data for handling
such differences.

The series also adds support like,

  - independent ->set_clock() api, as we need to enable internal clock gate
 and TX clock
  - pinctrl configuration based on bus speed.
  - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER
SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the
clocks, so it is important to configure them as part of ->set_power()
More detailed description is written into commit log.
  - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id



Please ignore this series, as one residual change (rather typo error).
Mistakenly while checking in the code, instead of 1928 compatible
property it was 988.

I will submit the new series shortly.

Thanks,
Vaibhav




Testing:
I have done basic testing on both eMMC and SD card on PXA1928 based
platform.

Note: I tried to made sure that I do not break any other platform, which
used sdhci, except HS200 configuration.
Unfortunately I do not have access to any other datasheets, where I can
cross check the details on HS200 bit-fields. Probably someone who has
access can confirm [PATCH 4/5], whether it impacts other platforms.

Kevin Liu (1):
   mmc: sdhci-pxav3: Fix HS200 mode support

Vaibhav Hiremath (4):
   mmc: sdhci-pxav3: Enable pxa1928 device support
   mmc: sdhci-pxav3: Add platform specific set_clock ops
   mmc: sdhci-pxav3: Add pinctl setting according to bus clock
   mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

  drivers/mmc/host/sdhci-pltfm.c |   3 +
  drivers/mmc/host/sdhci-pxav3.c | 168 ++---
  drivers/mmc/host/sdhci.c   |   3 +-
  drivers/mmc/host/sdhci.h   |   2 +
  4 files changed, 163 insertions(+), 13 deletions(-)


--
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 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

[Vaibhav Hiremath]

PXA1928 SDHCI controller has few differences, for example,

 PXAxxxPXA1928
 =====
 SDCLK_DELAY field   0x10A 0x114
 SDCLK_DELAY mask0x1F  0x3FF
 SDCLK_DELAY shift9  8
 SDCLK_SEL shift  8  2 (SEL1)

So this patch series introduces new compatible device_id
(marvell,pxav3-1928-sdhci), and makes use of .data for handling
such differences.

The series also adds support like,

 - independent ->set_clock() api, as we need to enable internal clock gate
   and TX clock
 - pinctrl configuration based on bus speed.
 - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER
   SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the
   clocks, so it is important to configure them as part of ->set_power()
   More detailed description is written into commit log.
 - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id
 - Enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON quirk for pxa1928 device


V1 => V2:
=
 - Fixed typo issue (residual change remained by mistake)
 - Added new patch updating DT binding document for pxa1928 support
 - Added new patch enabling CARD_ON_NEEDS_BUS_ON for pxa1928 device

Testing:
I have done basic testing on both eMMC and SD card on PXA1928 based
platform.

Note: I tried to made sure that I do not break any other platform, which
used sdhci, except HS200 configuration.·
Unfortunately I do not have access to any other datasheets, where I can
cross check the details on HS200 bit-fields. Probably someone who has
access can confirm [PATCH 4/5], whether it impacts other platforms.

Kevin Liu (1):
  mmc: sdhci-pxav3: Fix HS200 mode support

Vaibhav Hiremath (6):
  mmc: sdhci-pxav3: Enable pxa1928 device support
  mmc: sdhci-pxav3: binding: Add pxa1928 compatible support
  mmc: sdhci-pxav3: Add platform specific set_clock ops
  mmc: sdhci-pxav3: Add pinctl setting according to bus clock
  mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields
  mmc: sdhci: enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON for pxa1928

 .../devicetree/bindings/mmc/sdhci-pxa.txt  |   2 +-
 drivers/mmc/host/sdhci-pltfm.c |   4 +
 drivers/mmc/host/sdhci-pxav3.c | 168 +++--
 drivers/mmc/host/sdhci.c   |   3 +-
 drivers/mmc/host/sdhci.h   |   2 +
 5 files changed, 165 insertions(+), 14 deletions(-)

-- 
1.9.1

--
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 4/7] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
  - Default (slow/normal) pin state
  - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
Signed-off-by: Kevin Liu <kl...@marvell.com>
---
 drivers/mmc/host/sdhci-pxav3.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
 };
 
 static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
 }
 
+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);
 }
 
 static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-
 }
 
 static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}
 
+   pxa->pinctrl = devm_pinctrl_get(dev);
+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");
+   pxa->pins_fast = pinctrl_lookup_state(pxa->pinctrl, "fast");
+   if (IS_ERR(pxa->pins_fast))
+   dev_info(dev, "could not get fast pinstate\n");
+   }
+
pm_runtime_get_noresume(>dev);
pm_runtime_set_active(>dev);
pm_runtime_set_autosuspend_delay(>dev, PXAV3_RPM_DELAY_MS);
-- 
1.9.1

--
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 2/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support

[Vaibhav Hiremath]

With support for pxa1928 family of devices , this patch
updates the binding document with compatible property
of "marvell,pxav3-1928-sdhci".

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 3d1b449..29edcf5 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 
drivers.
 
 Required properties:
 - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or
-  "marvell,armada-380-sdhci".
+  "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci".
 - reg:
   * for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for
 the SDHCI registers.
-- 
1.9.1

--
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 1/7] mmc: sdhci-pxav3: Enable pxa1928 device support

[Vaibhav Hiremath]

SDHCI controller present in PXA1928 has few differences as far as
register map is concerned.
For example,

 PXAxxxPXA1928
 =====
 SDCLK_DELAY field   0x10A 0x114
 SDCLK_DELAY mask0x1F  0x3FF
 SDCLK_DELAY shift9  8
 SDCLK_SEL shift  8  2 (SEL1)

So in order to support multi-platform, use sdhci_pxa_regdata structure
as a variant data according to platform.

Note that, there are some more differences, which would be added
as and when respective feature gets added to the driver.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pxav3.c | 62 ++
 1 file changed, 51 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 6d4bad4..aecae04 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -42,9 +42,6 @@
 #define PXAV3_RPM_DELAY_MS 50
 
 #define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define  SDCLK_DELAY_SHIFT 9
-#define  SDCLK_DELAY_MASK  0x1f
 
 #define SD_CFG_FIFO_PARAM  0x100
 #define  SDCFG_GEN_PAD_CLK_ON  BIT(6)
@@ -58,11 +55,25 @@
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
+#define SD_RX_CFG_REG  0x114
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
 #define IO_PWR_MMC1_PAD_1V8BIT(2)
 
+struct sdhci_pxa_data {
+   u32 sdclk_delay_reg;
+   u32 sdclk_delay_mask;
+   u8 sdclk_delay_shift;
+   u8 sdclk_sel_mask;
+   u8 sdclk_sel_shift;
+   /*
+* We have few more differences, add them along with their
+* respective feature support
+*/
+};
+
 struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
@@ -70,6 +81,24 @@ struct sdhci_pxa {
void __iomem *sdio3_conf_reg;
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
+   struct sdhci_pxa_data *data;
+};
+
+static struct sdhci_pxa_data pxav3_data_v1 = {
+   .sdclk_delay_reg= SD_CLOCK_BURST_SIZE_SETUP,
+   .sdclk_delay_mask   = 0x1F,
+   .sdclk_delay_shift  = 9,
+   .sdclk_sel_mask = 0x1,
+   .sdclk_sel_shift= 8,
+};
+
+static struct sdhci_pxa_data pxav3_data_v2 = {
+   .sdclk_delay_reg= SD_RX_CFG_REG,
+   .sdclk_delay_mask   = 0x3FF,
+   .sdclk_delay_shift  = 8,
+   /* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
+   .sdclk_sel_mask = 0x3,
+   .sdclk_sel_shift= 2,/* SDCLK_SEL1 */
 };
 
 /*
@@ -183,6 +212,8 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 {
struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
 
sdhci_reset(host, mask);
 
@@ -193,12 +224,14 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 */
if (pdata && 0 != pdata->clk_delay_cycles) {
u16 tmp;
-
-   tmp = readw(host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
-   tmp |= (pdata->clk_delay_cycles & SDCLK_DELAY_MASK)
-   << SDCLK_DELAY_SHIFT;
-   tmp |= SDCLK_SEL;
-   writew(tmp, host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
+   struct sdhci_pxa_data *data = pxa->data;
+
+   tmp = readw(host->ioaddr + data->sdclk_delay_reg);
+   tmp |= (pdata->clk_delay_cycles & 
data->sdclk_delay_mask)
+   << data->sdclk_delay_shift;
+   tmp &= ~(data->sdclk_sel_mask << data->sdclk_sel_shift);
+   tmp |= 1 << data->sdclk_sel_shift;
+   writew(tmp, host->ioaddr + data->sdclk_delay_reg);
}
}
 }
@@ -363,10 +396,16 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
 #ifdef CONFIG_OF
 static const struct of_device_id sdhci_pxav3_of_match[] = {
{
-   .compatible = "mrvl,pxav3-mmc",
+   .compatible = "mrvl,pxav3-mmc",
+   .data   = (void *)_data_v1,
+   },
+   {
+   .compatible = "marvell,armada-380-sdhci",
+   .data   = (void *)_data_v1,
},
{
-  

Re: [PATCH-v2 1/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

On Monday 07 September 2015 05:26 PM, Jisheng Zhang wrote:

On Mon, 7 Sep 2015 17:01:09 +0530
Vaibhav Hiremath <vaibhav.hirem...@linaro.org> wrote:


There were some coding style issues where spaces have been used instead
of tabs, for example, in macro definitions, alignment of function
declarations/definitions, etc...

This patch fixes all such occurrences in the code.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
  drivers/mmc/host/sdhci-pxav3.c | 46 +-
  1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 946d37f..7a07177 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -39,24 +39,24 @@
  #include "sdhci.h"
  #include "sdhci-pltfm.h"

-#define PXAV3_RPM_DELAY_MS 50
+#define PXAV3_RPM_DELAY_MS 50

-#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define SDCLK_DELAY_SHIFT  9
-#define SDCLK_DELAY_MASK   0x1f
+#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
+#define SDCLK_SEL  0x100
+#define  SDCLK_DELAY_SHIFT 9
+#define  SDCLK_DELAY_MASK  0x1f

-#define SD_CFG_FIFO_PARAM   0x100
-#define SDCFG_GEN_PAD_CLK_ON   (1<<6)
-#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
-#define SDCFG_GEN_PAD_CLK_CNT_SHIFT24
+#define SD_CFG_FIFO_PARAM  0x100
+#define  SDCFG_GEN_PAD_CLK_ON  (1<<6)
+#define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
+#define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24

-#define SD_SPI_MODE  0x108
-#define SD_CE_ATA_1  0x10C
+#define SD_SPI_MODE0x108
+#define SD_CE_ATA_10x10C

-#define SD_CE_ATA_2  0x10E
-#define SDCE_MISC_INT  (1<<2)
-#define SDCE_MISC_INT_EN   (1<<1)
+#define SD_CE_ATA_20x10E
+#define  SDCE_MISC_INT (1<<2)
+#define  SDCE_MISC_INT_EN  (1<<1)

  struct sdhci_pxa {
struct clk *clk_core;
@@ -284,7 +284,7 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 * FE-2946959
 */
if (pxa->sdio3_conf_reg) {
-   u8 reg_val  = readb(pxa->sdio3_conf_reg);
+   u8 reg_val = readb(pxa->sdio3_conf_reg);

if (uhs == MMC_TIMING_UHS_SDR50 ||
uhs == MMC_TIMING_UHS_DDR50) {
@@ -304,20 +304,20 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
  }

  static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock = sdhci_set_clock,
-   .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
-   .get_max_clock = sdhci_pltfm_clk_get_max_clock,
-   .set_bus_width = sdhci_set_bus_width,
-   .reset = pxav3_reset,
-   .set_uhs_signaling = pxav3_set_uhs_signaling,
+   .set_clock  = sdhci_set_clock,
+   .platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
+   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .set_bus_width  = sdhci_set_bus_width,
+   .reset  = pxav3_reset,
+   .set_uhs_signaling  = pxav3_set_uhs_signaling,


IMHO, this is not an improvement, previous style is fine and I saw
such style in kernel here and there



I had received feedback to use above style on different patch-series.
And I also think this looks more clean and readable.

Thanks,
Vaibhav
--
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 2/3] mmc: sdhci-pxav3: Use BIT macro for bit field definitions

[Vaibhav Hiremath]

Instead of using shift operation use BIT macro for bit field
definitions.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pxav3.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 7a07177..a8a8c94 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -47,7 +47,7 @@
 #define  SDCLK_DELAY_MASK  0x1f
 
 #define SD_CFG_FIFO_PARAM  0x100
-#define  SDCFG_GEN_PAD_CLK_ON  (1<<6)
+#define  SDCFG_GEN_PAD_CLK_ON  BIT(6)
 #define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
 #define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
@@ -55,8 +55,8 @@
 #define SD_CE_ATA_10x10C
 
 #define SD_CE_ATA_20x10E
-#define  SDCE_MISC_INT (1<<2)
-#define  SDCE_MISC_INT_EN  (1<<1)
+#define  SDCE_MISC_INT BIT(2)
+#define  SDCE_MISC_INT_EN  BIT(1)
 
 struct sdhci_pxa {
struct clk *clk_core;
-- 
1.9.1

--
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 0/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

Trivial patch-series, which fixes the tabbing issue in the driver,
uses the BIT macro for bit fields and prints notice on -EPROBE_DEFER
in sdhci_add_host() function on regulator unavailability.

V1 => V2

 - Fixed all comments from Joe, mostly alignment changes
 - Separated BIT macro usage patch into new one.
 - changed error to kernel notice for EPROBE_DEFER in sdhci_add_host()

Note: This patch-series should get merged before another series -

[PATCH-v2 0/7] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

Vaibhav Hiremath (3):
  mmc: sdhci-pxav3: Fix tabbing issue
  mmc: sdhci-pxav3: Use BIT macro for bit field definitions
  mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn

 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 drivers/mmc/host/sdhci.c   |  5 -
 2 files changed, 27 insertions(+), 24 deletions(-)

-- 
1.9.1

--
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 5/7] mmc: sdhci-pxav3: Fix HS200 mode support

[Vaibhav Hiremath]

From: Kevin Liu <kl...@marvell.com>

IN case of MMC HS200 mode, current code does not enable
SD_CE_ATA_2.MMC_HS200 & SD_CE_ATA_2.MMC_CARD bit configurations.

So this patch updates the above bit fields correctly.

Signed-off-by: Tim Wang <wan...@marvell.com>
Signed-off-by: Kevin Liu <kl...@marvell.com>
Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
Note: Unfortunately I do not have access to any other datasheets
which uses sdhci-pxav3 driver, so quite not sure whether this would
break any existing platform, probably NOT, as I do not see any
references for this change.
If anyone can confirm that would be really great.

 drivers/mmc/host/sdhci-pxav3.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d933f75..6978810 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,8 @@
 #define SD_CE_ATA_10x10C
 
 #define SD_CE_ATA_20x10E
+#define  SD_CE_ATA2_HS200_EN   BIT(10)
+#define  SD_CE_ATA2_MMC_MODE   BIT(12)
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
@@ -330,6 +332,17 @@ static int pxav3_select_pinstate(struct sdhci_host *host, 
unsigned int uhs)
return pinctrl_select_state(pxa->pinctrl, pinctrl);
 }
 
+static int pxav3_select_hs200(struct sdhci_host *host)
+{
+   u16 reg = 0;
+
+   reg = sdhci_readw(host, SD_CE_ATA_2);
+   reg |= SD_CE_ATA2_HS200_EN | SD_CE_ATA2_MMC_MODE;
+   sdhci_writew(host, reg, SD_CE_ATA_2);
+
+   return 0;
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -361,6 +374,10 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
case MMC_TIMING_UHS_DDR50:
ctrl_2 |= SDHCI_CTRL_UHS_DDR50 | SDHCI_CTRL_VDD_180;
break;
+   case MMC_TIMING_MMC_HS200:
+   ctrl_2 |= SDHCI_CTRL_UHS_SDR104 | SDHCI_CTRL_VDD_180;
+   pxav3_select_hs200(host);
+   break;
}
 
/*
-- 
1.9.1

--
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 6/7] mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

[Vaibhav Hiremath]

IN case of Marvell 1928 family of devices, the SD_BUS_POWER and
SD_BUS_VLT bits are used internally to gate the clocks, so
we have to set these fields.

Pasting Spec words here,

The  and  fields should be configured
to correct values. These actually do not do the voltage selection
or switch power to the SD card. However these fields are used
internally to gate the clock. So if these fields are set
incorrectly, SD module will not function.

And during my development, I have seen that SD card wouldn't function
without right configuration into these fields.

So this patch adds new quirk (SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER),
which make sure that ->set_power() sets these fields.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pltfm.c | 3 +++
 drivers/mmc/host/sdhci.c   | 3 ++-
 drivers/mmc/host/sdhci.h   | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index a207f5a..5788a8c 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -101,6 +101,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
of_device_is_compatible(np, "fsl,mpc8536-esdhc"))
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
+   if (of_device_is_compatible(np, "marvell,pxav3-1928-sdhci"))
+   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER;
+
clk = of_get_property(np, "clock-frequency", );
if (clk && size == sizeof(*clk) && *clk)
pltfm_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2d58b31..418f381 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1265,7 +1265,8 @@ static void sdhci_set_power(struct sdhci_host *host, 
unsigned char mode,
else
sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
 
-   return;
+   if (!(host->quirks2 | SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER))
+   return;
}
 
if (mode != MMC_POWER_OFF) {
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 9b0e2a8..8802a0c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -409,6 +409,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_SUPPORT_SINGLE(1<<13)
 /* Controller broken with using ACMD23 */
 #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14)
+/* Voltage capabilities of Controller must be set  */
+#define SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER  (1<<15)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
1.9.1

--
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 7/7] mmc: sdhci: enable SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON for pxa1928

[Vaibhav Hiremath]

Card power is dependent on bus power, without that card
wouldn't respond (No CARD_INT). So this patch enables the
quirk SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pltfm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 5788a8c..057190c 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -102,7 +102,8 @@ void sdhci_get_of_property(struct platform_device *pdev)
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
if (of_device_is_compatible(np, "marvell,pxav3-1928-sdhci"))
-   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER;
+   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER |
+   SDHCI_QUIRK2_CARD_ON_NEEDS_BUS_ON;
 
clk = of_get_property(np, "clock-frequency", );
if (clk && size == sizeof(*clk) && *clk)
-- 
1.9.1

--
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 3/7] mmc: sdhci-pxav3: Add platform specific set_clock ops

[Vaibhav Hiremath]

In case of PXA1928 & family of devices, the TX BUS and internal clock
need to be set as part of ->set_clock() ops, so this patch adds
platform specific ->set_clock() operation.

Note that, in order to not break other platforms, this patch
introduced the flag, which controls whether controller/platform
specific clock configuration needs to be executed.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index aecae04..c2b2b78 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -48,6 +48,10 @@
 #define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
 #define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
+#define SD_FIFO_PARAM  0x104
+#define  INTERNAL_CLK_GATE_CTRLBIT(8)
+#define  INTERNAL_CLK_GATE_ON  BIT(9)
+
 #define SD_SPI_MODE0x108
 #define SD_CE_ATA_10x10C
 
@@ -57,6 +61,9 @@
 
 #define SD_RX_CFG_REG  0x114
 
+#define TX_CFG_REG 0x118
+#define  TX_INTERNAL_SEL_BUS_CLK   BIT(30)
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
@@ -68,6 +75,9 @@ struct sdhci_pxa_data {
u8 sdclk_delay_shift;
u8 sdclk_sel_mask;
u8 sdclk_sel_shift;
+
+   /* set this if platform needs separate clock configuration */
+   bool set_pltfrm_clk;
/*
 * We have few more differences, add them along with their
 * respective feature support
@@ -90,6 +100,7 @@ static struct sdhci_pxa_data pxav3_data_v1 = {
.sdclk_delay_shift  = 9,
.sdclk_sel_mask = 0x1,
.sdclk_sel_shift= 8,
+   .set_pltfrm_clk = false,
 };
 
 static struct sdhci_pxa_data pxav3_data_v2 = {
@@ -99,6 +110,7 @@ static struct sdhci_pxa_data pxav3_data_v2 = {
/* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
.sdclk_sel_mask = 0x3,
.sdclk_sel_shift= 2,/* SDCLK_SEL1 */
+   .set_pltfrm_clk = true,
 };
 
 /*
@@ -375,8 +387,40 @@ static void pxav3_voltage_switch(struct sdhci_host *host,
writel(val, pxa->io_pwr_reg);
 }
 
+static void pxav3_set_tx_clock(struct sdhci_host *host)
+{
+   u32 val;
+
+   val = sdhci_readl(host, TX_CFG_REG);
+   val |= TX_INTERNAL_SEL_BUS_CLK;
+   sdhci_writel(host, val, TX_CFG_REG);
+}
+
+static void pxav3_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+
+   /* We still use common sdhci_set_clock() */
+   sdhci_set_clock(host, clock);
+
+   /* platform/controller specific clock configuration */
+   if (pxa->data->set_pltfrm_clk && clock != 0) {
+   u32 val;
+
+   val = sdhci_readw(host, SD_FIFO_PARAM);
+   /* Internal clock gate ON and CTRL = 0b11 */
+   val |= INTERNAL_CLK_GATE_CTRL | INTERNAL_CLK_GATE_ON;
+   sdhci_writew(host, val, SD_FIFO_PARAM);
+
+   /* TX internal clock selection */
+   pxav3_set_tx_clock(host);
+   }
+
+}
+
 static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock  = sdhci_set_clock,
+   .set_clock  = pxav3_set_clock,
.platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
.get_max_clock  = sdhci_pltfm_clk_get_max_clock,
.set_bus_width  = sdhci_set_bus_width,
-- 
1.9.1

--
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 1/3] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

There were some coding style issues where spaces have been used instead
of tabs, for example, in macro definitions, alignment of function
declarations/definitions, etc...

This patch fixes all such occurrences in the code.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 946d37f..7a07177 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -39,24 +39,24 @@
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
 
-#define PXAV3_RPM_DELAY_MS 50
+#define PXAV3_RPM_DELAY_MS 50
 
-#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define SDCLK_DELAY_SHIFT  9
-#define SDCLK_DELAY_MASK   0x1f
+#define SD_CLOCK_BURST_SIZE_SETUP  0x10A
+#define SDCLK_SEL  0x100
+#define  SDCLK_DELAY_SHIFT 9
+#define  SDCLK_DELAY_MASK  0x1f
 
-#define SD_CFG_FIFO_PARAM   0x100
-#define SDCFG_GEN_PAD_CLK_ON   (1<<6)
-#define SDCFG_GEN_PAD_CLK_CNT_MASK 0xFF
-#define SDCFG_GEN_PAD_CLK_CNT_SHIFT24
+#define SD_CFG_FIFO_PARAM  0x100
+#define  SDCFG_GEN_PAD_CLK_ON  (1<<6)
+#define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
+#define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
-#define SD_SPI_MODE  0x108
-#define SD_CE_ATA_1  0x10C
+#define SD_SPI_MODE0x108
+#define SD_CE_ATA_10x10C
 
-#define SD_CE_ATA_2  0x10E
-#define SDCE_MISC_INT  (1<<2)
-#define SDCE_MISC_INT_EN   (1<<1)
+#define SD_CE_ATA_20x10E
+#define  SDCE_MISC_INT (1<<2)
+#define  SDCE_MISC_INT_EN  (1<<1)
 
 struct sdhci_pxa {
struct clk *clk_core;
@@ -284,7 +284,7 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 * FE-2946959
 */
if (pxa->sdio3_conf_reg) {
-   u8 reg_val  = readb(pxa->sdio3_conf_reg);
+   u8 reg_val = readb(pxa->sdio3_conf_reg);
 
if (uhs == MMC_TIMING_UHS_SDR50 ||
uhs == MMC_TIMING_UHS_DDR50) {
@@ -304,20 +304,20 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
 }
 
 static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock = sdhci_set_clock,
-   .platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
-   .get_max_clock = sdhci_pltfm_clk_get_max_clock,
-   .set_bus_width = sdhci_set_bus_width,
-   .reset = pxav3_reset,
-   .set_uhs_signaling = pxav3_set_uhs_signaling,
+   .set_clock  = sdhci_set_clock,
+   .platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
+   .get_max_clock  = sdhci_pltfm_clk_get_max_clock,
+   .set_bus_width  = sdhci_set_bus_width,
+   .reset  = pxav3_reset,
+   .set_uhs_signaling  = pxav3_set_uhs_signaling,
 };
 
 static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
-   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
+   .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
| SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC
| SDHCI_QUIRK_32BIT_ADMA_SIZE
| SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
-   .ops = _sdhci_ops,
+   .ops= _sdhci_ops,
 };
 
 #ifdef CONFIG_OF
-- 
1.9.1

--
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 3/3] mmc: sdhci: print notice on -EPROBE_DEFER in sdhci_add_host() fn

[Vaibhav Hiremath]

This patch adds kernel notice/message to sdhci_host_add() fn on
-EPROBE_DEFER.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1dbe932..37a5cd5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3130,8 +3130,11 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->caps |= MMC_CAP_NEEDS_POLL;
 
/* If there are external regulators, get them */
-   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER) {
+   pr_notice("%s: regulator supply unavailable, deferring 
probe.\n",
+   mmc_hostname(mmc));
return -EPROBE_DEFER;
+   }
 
/* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
if (!IS_ERR(mmc->supply.vqmmc)) {
-- 
1.9.1

--
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 5/5] mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

[Vaibhav Hiremath]

IN case of Marvell 1928 family of devices, the SD_BUS_POWER and
SD_BUS_VLT bits are used internally to gate the clocks, so
we have to set these fields.

Pasting Spec words here,

The  and  fields should be configured
to correct values. These actually do not do the voltage selection
or switch power to the SD card. However these fields are used
internally to gate the clock. So if these fields are set
incorrectly, SD module will not function.

And during my development, I have seen that SD card wouldn't function
without right configuration into these fields.

So this patch adds new quirk (SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER),
which make sure that ->set_power() sets these fields.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pltfm.c | 3 +++
 drivers/mmc/host/sdhci.c   | 3 ++-
 drivers/mmc/host/sdhci.h   | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index a207f5a..0872da0 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -101,6 +101,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
of_device_is_compatible(np, "fsl,mpc8536-esdhc"))
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
+   if (of_device_is_compatible(np, "marvell,pxav3-988-sdhci"))
+   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER;
+
clk = of_get_property(np, "clock-frequency", );
if (clk && size == sizeof(*clk) && *clk)
pltfm_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2d58b31..418f381 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1265,7 +1265,8 @@ static void sdhci_set_power(struct sdhci_host *host, 
unsigned char mode,
else
sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
 
-   return;
+   if (!(host->quirks2 | SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER))
+   return;
}
 
if (mode != MMC_POWER_OFF) {
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 9b0e2a8..8802a0c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -409,6 +409,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_SUPPORT_SINGLE(1<<13)
 /* Controller broken with using ACMD23 */
 #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14)
+/* Voltage capabilities of Controller must be set  */
+#define SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER  (1<<15)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
1.9.1

--
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 3/5] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
  - Default (slow/normal) pin state
  - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath 
Signed-off-by: Kevin Liu 
---
 drivers/mmc/host/sdhci-pxav3.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
 };
 
 static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
 }
 
+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);
 }
 
 static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-
 }
 
 static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}
 
+   pxa->pinctrl = devm_pinctrl_get(dev);
+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");
+   pxa->pins_fast = pinctrl_lookup_state(pxa->pinctrl, "fast");
+   if (IS_ERR(pxa->pins_fast))
+   dev_info(dev, "could not get fast pinstate\n");
+   }
+
pm_runtime_get_noresume(>dev);
pm_runtime_set_active(>dev);
pm_runtime_set_autosuspend_delay(>dev, PXAV3_RPM_DELAY_MS);
-- 
1.9.1

--
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 4/5] mmc: sdhci-pxav3: Fix HS200 mode support

[Vaibhav Hiremath]

From: Kevin Liu 

IN case of MMC HS200 mode, current code does not enable
SD_CE_ATA_2.MMC_HS200 & SD_CE_ATA_2.MMC_CARD bit configurations.

So this patch updates the above bit fields correctly.

Signed-off-by: Tim Wang 
Signed-off-by: Kevin Liu 
Signed-off-by: Vaibhav Hiremath 
---
Note: Unfortunately I do not have access to any other datasheets
which uses sdhci-pxav3 driver, so quite not sure whether this would
break any existing platform, probably NOT, as I do not see any
references for this change.
If anyone can confirm that would be really great.

 drivers/mmc/host/sdhci-pxav3.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d933f75..6978810 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,8 @@
 #define SD_CE_ATA_10x10C
 
 #define SD_CE_ATA_20x10E
+#define  SD_CE_ATA2_HS200_EN   BIT(10)
+#define  SD_CE_ATA2_MMC_MODE   BIT(12)
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
@@ -330,6 +332,17 @@ static int pxav3_select_pinstate(struct sdhci_host *host, 
unsigned int uhs)
return pinctrl_select_state(pxa->pinctrl, pinctrl);
 }
 
+static int pxav3_select_hs200(struct sdhci_host *host)
+{
+   u16 reg = 0;
+
+   reg = sdhci_readw(host, SD_CE_ATA_2);
+   reg |= SD_CE_ATA2_HS200_EN | SD_CE_ATA2_MMC_MODE;
+   sdhci_writew(host, reg, SD_CE_ATA_2);
+
+   return 0;
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -361,6 +374,10 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
case MMC_TIMING_UHS_DDR50:
ctrl_2 |= SDHCI_CTRL_UHS_DDR50 | SDHCI_CTRL_VDD_180;
break;
+   case MMC_TIMING_MMC_HS200:
+   ctrl_2 |= SDHCI_CTRL_UHS_SDR104 | SDHCI_CTRL_VDD_180;
+   pxav3_select_hs200(host);
+   break;
}
 
/*
-- 
1.9.1

--
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/5] mmc: sdhci-pxav3: Enable pxa1928 device support

[Vaibhav Hiremath]

SDHCI controller present in PXA1928 has few differences as far as
register map is concerned.
For example,

 PXAxxxPXA1928
 =====
 SDCLK_DELAY field   0x10A 0x114
 SDCLK_DELAY mask0x1F  0x3FF
 SDCLK_DELAY shift9  8
 SDCLK_SEL shift  8  2 (SEL1)

So in order to support multi-platform, use sdhci_pxa_regdata structure
as a variant data according to platform.

Note that, there are some more differences, which would be added
as and when respective feature gets added to the driver.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 62 ++
 1 file changed, 51 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 6d4bad4..aecae04 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -42,9 +42,6 @@
 #define PXAV3_RPM_DELAY_MS 50
 
 #define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define  SDCLK_DELAY_SHIFT 9
-#define  SDCLK_DELAY_MASK  0x1f
 
 #define SD_CFG_FIFO_PARAM  0x100
 #define  SDCFG_GEN_PAD_CLK_ON  BIT(6)
@@ -58,11 +55,25 @@
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
+#define SD_RX_CFG_REG  0x114
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
 #define IO_PWR_MMC1_PAD_1V8BIT(2)
 
+struct sdhci_pxa_data {
+   u32 sdclk_delay_reg;
+   u32 sdclk_delay_mask;
+   u8 sdclk_delay_shift;
+   u8 sdclk_sel_mask;
+   u8 sdclk_sel_shift;
+   /*
+* We have few more differences, add them along with their
+* respective feature support
+*/
+};
+
 struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
@@ -70,6 +81,24 @@ struct sdhci_pxa {
void __iomem *sdio3_conf_reg;
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
+   struct sdhci_pxa_data *data;
+};
+
+static struct sdhci_pxa_data pxav3_data_v1 = {
+   .sdclk_delay_reg= SD_CLOCK_BURST_SIZE_SETUP,
+   .sdclk_delay_mask   = 0x1F,
+   .sdclk_delay_shift  = 9,
+   .sdclk_sel_mask = 0x1,
+   .sdclk_sel_shift= 8,
+};
+
+static struct sdhci_pxa_data pxav3_data_v2 = {
+   .sdclk_delay_reg= SD_RX_CFG_REG,
+   .sdclk_delay_mask   = 0x3FF,
+   .sdclk_delay_shift  = 8,
+   /* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
+   .sdclk_sel_mask = 0x3,
+   .sdclk_sel_shift= 2,/* SDCLK_SEL1 */
 };
 
 /*
@@ -183,6 +212,8 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 {
struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
 
sdhci_reset(host, mask);
 
@@ -193,12 +224,14 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 */
if (pdata && 0 != pdata->clk_delay_cycles) {
u16 tmp;
-
-   tmp = readw(host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
-   tmp |= (pdata->clk_delay_cycles & SDCLK_DELAY_MASK)
-   << SDCLK_DELAY_SHIFT;
-   tmp |= SDCLK_SEL;
-   writew(tmp, host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
+   struct sdhci_pxa_data *data = pxa->data;
+
+   tmp = readw(host->ioaddr + data->sdclk_delay_reg);
+   tmp |= (pdata->clk_delay_cycles & 
data->sdclk_delay_mask)
+   << data->sdclk_delay_shift;
+   tmp &= ~(data->sdclk_sel_mask << data->sdclk_sel_shift);
+   tmp |= 1 << data->sdclk_sel_shift;
+   writew(tmp, host->ioaddr + data->sdclk_delay_reg);
}
}
 }
@@ -363,10 +396,16 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
 #ifdef CONFIG_OF
 static const struct of_device_id sdhci_pxav3_of_match[] = {
{
-   .compatible = "mrvl,pxav3-mmc",
+   .compatible = "mrvl,pxav3-mmc",
+   .data   = (void *)_data_v1,
+   },
+   {
+   .compatible = "marvell,armada-380-sdhci",
+   .data   = (void *)_data_v1,
},
{
-   .compatible = "marvel

[PATCH 2/5] mmc: sdhci-pxav3: Add platform specific set_clock ops

[Vaibhav Hiremath]

In case of PXA1928 & family of devices, the TX BUS and internal clock
need to be set as part of ->set_clock() ops, so this patch adds
platform specific ->set_clock() operation.

Note that, in order to not break other platforms, this patch
introduced the flag, which controls whether controller/platform
specific clock configuration needs to be executed.

Signed-off-by: Vaibhav Hiremath 
---
 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index aecae04..c2b2b78 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -48,6 +48,10 @@
 #define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
 #define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
+#define SD_FIFO_PARAM  0x104
+#define  INTERNAL_CLK_GATE_CTRLBIT(8)
+#define  INTERNAL_CLK_GATE_ON  BIT(9)
+
 #define SD_SPI_MODE0x108
 #define SD_CE_ATA_10x10C
 
@@ -57,6 +61,9 @@
 
 #define SD_RX_CFG_REG  0x114
 
+#define TX_CFG_REG 0x118
+#define  TX_INTERNAL_SEL_BUS_CLK   BIT(30)
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
@@ -68,6 +75,9 @@ struct sdhci_pxa_data {
u8 sdclk_delay_shift;
u8 sdclk_sel_mask;
u8 sdclk_sel_shift;
+
+   /* set this if platform needs separate clock configuration */
+   bool set_pltfrm_clk;
/*
 * We have few more differences, add them along with their
 * respective feature support
@@ -90,6 +100,7 @@ static struct sdhci_pxa_data pxav3_data_v1 = {
.sdclk_delay_shift  = 9,
.sdclk_sel_mask = 0x1,
.sdclk_sel_shift= 8,
+   .set_pltfrm_clk = false,
 };
 
 static struct sdhci_pxa_data pxav3_data_v2 = {
@@ -99,6 +110,7 @@ static struct sdhci_pxa_data pxav3_data_v2 = {
/* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
.sdclk_sel_mask = 0x3,
.sdclk_sel_shift= 2,/* SDCLK_SEL1 */
+   .set_pltfrm_clk = true,
 };
 
 /*
@@ -375,8 +387,40 @@ static void pxav3_voltage_switch(struct sdhci_host *host,
writel(val, pxa->io_pwr_reg);
 }
 
+static void pxav3_set_tx_clock(struct sdhci_host *host)
+{
+   u32 val;
+
+   val = sdhci_readl(host, TX_CFG_REG);
+   val |= TX_INTERNAL_SEL_BUS_CLK;
+   sdhci_writel(host, val, TX_CFG_REG);
+}
+
+static void pxav3_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+
+   /* We still use common sdhci_set_clock() */
+   sdhci_set_clock(host, clock);
+
+   /* platform/controller specific clock configuration */
+   if (pxa->data->set_pltfrm_clk && clock != 0) {
+   u32 val;
+
+   val = sdhci_readw(host, SD_FIFO_PARAM);
+   /* Internal clock gate ON and CTRL = 0b11 */
+   val |= INTERNAL_CLK_GATE_CTRL | INTERNAL_CLK_GATE_ON;
+   sdhci_writew(host, val, SD_FIFO_PARAM);
+
+   /* TX internal clock selection */
+   pxav3_set_tx_clock(host);
+   }
+
+}
+
 static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock  = sdhci_set_clock,
+   .set_clock  = pxav3_set_clock,
.platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
.get_max_clock  = sdhci_pltfm_clk_get_max_clock,
.set_bus_width  = sdhci_set_bus_width,
-- 
1.9.1

--
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 0/5] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

[Vaibhav Hiremath]

PXA1928 SDHCI controller has few differences, for example,

   PXAxxxPXA1928
   =====
   SDCLK_DELAY field   0x10A 0x114
   SDCLK_DELAY mask0x1F  0x3FF
   SDCLK_DELAY shift9  8
   SDCLK_SEL shift  8  2 (SEL1)

So this patch series introduces new compatible device_id
(marvell,pxav3-1928-sdhci), and makes use of .data for handling
such differences.

The series also adds support like,

 - independent ->set_clock() api, as we need to enable internal clock gate
and TX clock
 - pinctrl configuration based on bus speed.
 - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER
   SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the
   clocks, so it is important to configure them as part of ->set_power()
   More detailed description is written into commit log.
 - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id


Testing:
I have done basic testing on both eMMC and SD card on PXA1928 based
platform.

Note: I tried to made sure that I do not break any other platform, which
used sdhci, except HS200 configuration. 
Unfortunately I do not have access to any other datasheets, where I can
cross check the details on HS200 bit-fields. Probably someone who has
access can confirm [PATCH 4/5], whether it impacts other platforms.

Kevin Liu (1):
  mmc: sdhci-pxav3: Fix HS200 mode support

Vaibhav Hiremath (4):
  mmc: sdhci-pxav3: Enable pxa1928 device support
  mmc: sdhci-pxav3: Add platform specific set_clock ops
  mmc: sdhci-pxav3: Add pinctl setting according to bus clock
  mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

 drivers/mmc/host/sdhci-pltfm.c |   3 +
 drivers/mmc/host/sdhci-pxav3.c | 168 ++---
 drivers/mmc/host/sdhci.c   |   3 +-
 drivers/mmc/host/sdhci.h   |   2 +
 4 files changed, 163 insertions(+), 13 deletions(-)

-- 
1.9.1

--
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 5/5] mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

[Vaibhav Hiremath]

IN case of Marvell 1928 family of devices, the SD_BUS_POWER and
SD_BUS_VLT bits are used internally to gate the clocks, so
we have to set these fields.

Pasting Spec words here,

The  and  fields should be configured
to correct values. These actually do not do the voltage selection
or switch power to the SD card. However these fields are used
internally to gate the clock. So if these fields are set
incorrectly, SD module will not function.

And during my development, I have seen that SD card wouldn't function
without right configuration into these fields.

So this patch adds new quirk (SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER),
which make sure that ->set_power() sets these fields.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pltfm.c | 3 +++
 drivers/mmc/host/sdhci.c   | 3 ++-
 drivers/mmc/host/sdhci.h   | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index a207f5a..0872da0 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -101,6 +101,9 @@ void sdhci_get_of_property(struct platform_device *pdev)
of_device_is_compatible(np, "fsl,mpc8536-esdhc"))
host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
 
+   if (of_device_is_compatible(np, "marvell,pxav3-988-sdhci"))
+   host->quirks2 |= SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER;
+
clk = of_get_property(np, "clock-frequency", );
if (clk && size == sizeof(*clk) && *clk)
pltfm_host->clock = be32_to_cpup(clk);
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 2d58b31..418f381 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1265,7 +1265,8 @@ static void sdhci_set_power(struct sdhci_host *host, 
unsigned char mode,
else
sdhci_writeb(host, 0, SDHCI_POWER_CONTROL);
 
-   return;
+   if (!(host->quirks2 | SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER))
+   return;
}
 
if (mode != MMC_POWER_OFF) {
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 9b0e2a8..8802a0c 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -409,6 +409,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK2_SUPPORT_SINGLE(1<<13)
 /* Controller broken with using ACMD23 */
 #define SDHCI_QUIRK2_ACMD23_BROKEN (1<<14)
+/* Voltage capabilities of Controller must be set  */
+#define SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER  (1<<15)
 
int irq;/* Device IRQ */
void __iomem *ioaddr;   /* Mapped address */
-- 
1.9.1

--
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 3/5] mmc: sdhci-pxav3: Add pinctl setting according to bus clock

[Vaibhav Hiremath]

Different bus clock may need different pin setting.
For example, fast bus clock like 208Mhz need pin drive fast
while slow bus clock prefer pin drive slow to guarantee
signal quality.

So this patch creates two states,
  - Default (slow/normal) pin state
  - And fast pin state for higher freq bus speed.

And selection of pin state is done based on timing mode.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
Signed-off-by: Kevin Liu <kl...@marvell.com>
---
 drivers/mmc/host/sdhci-pxav3.c | 45 +-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c2b2b78..d933f75 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
@@ -92,6 +93,10 @@ struct sdhci_pxa {
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
struct sdhci_pxa_data *data;
+
+   struct pinctrl *pinctrl;
+   struct pinctrl_state *pins_default;
+   struct pinctrl_state *pins_fast;
 };
 
 static struct sdhci_pxa_data pxav3_data_v1 = {
@@ -298,6 +303,33 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
*host, u8 power_mode)
pxa->power_mode = power_mode;
 }
 
+static int pxav3_select_pinstate(struct sdhci_host *host, unsigned int uhs)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+   struct pinctrl_state *pinctrl;
+
+   if (IS_ERR(pxa->pinctrl) ||
+   IS_ERR(pxa->pins_default) ||
+   IS_ERR(pxa->pins_fast))
+   return -EINVAL;
+
+   switch (uhs) {
+   case MMC_TIMING_UHS_SDR50:
+   case MMC_TIMING_UHS_SDR104:
+   case MMC_TIMING_MMC_HS200:
+   case MMC_TIMING_MMC_HS400:
+   pinctrl = pxa->pins_fast;
+   break;
+   default:
+   /* back to default state for other legacy timing */
+   pinctrl = pxa->pins_default;
+   break;
+   }
+
+   return pinctrl_select_state(pxa->pinctrl, pinctrl);
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -353,6 +385,8 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
dev_dbg(mmc_dev(host->mmc),
"%s uhs = %d, ctrl_2 = %04X\n",
__func__, uhs, ctrl_2);
+
+   pxav3_select_pinstate(host, uhs);
 }
 
 static void pxav3_voltage_switch(struct sdhci_host *host,
@@ -416,7 +450,6 @@ static void pxav3_set_clock(struct sdhci_host *host, 
unsigned int clock)
/* TX internal clock selection */
pxav3_set_tx_clock(host);
}
-
 }
 
 static const struct sdhci_ops pxav3_sdhci_ops = {
@@ -586,6 +619,16 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
}
}
 
+   pxa->pinctrl = devm_pinctrl_get(dev);
+   if (!IS_ERR(pxa->pinctrl)) {
+   pxa->pins_default = pinctrl_lookup_state(pxa->pinctrl, 
"default");
+   if (IS_ERR(pxa->pins_default))
+   dev_err(dev, "could not get default pinstate\n");
+   pxa->pins_fast = pinctrl_lookup_state(pxa->pinctrl, "fast");
+   if (IS_ERR(pxa->pins_fast))
+   dev_info(dev, "could not get fast pinstate\n");
+   }
+
pm_runtime_get_noresume(>dev);
pm_runtime_set_active(>dev);
pm_runtime_set_autosuspend_delay(>dev, PXAV3_RPM_DELAY_MS);
-- 
1.9.1

--
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 4/5] mmc: sdhci-pxav3: Fix HS200 mode support

[Vaibhav Hiremath]

From: Kevin Liu <kl...@marvell.com>

IN case of MMC HS200 mode, current code does not enable
SD_CE_ATA_2.MMC_HS200 & SD_CE_ATA_2.MMC_CARD bit configurations.

So this patch updates the above bit fields correctly.

Signed-off-by: Tim Wang <wan...@marvell.com>
Signed-off-by: Kevin Liu <kl...@marvell.com>
Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
Note: Unfortunately I do not have access to any other datasheets
which uses sdhci-pxav3 driver, so quite not sure whether this would
break any existing platform, probably NOT, as I do not see any
references for this change.
If anyone can confirm that would be really great.

 drivers/mmc/host/sdhci-pxav3.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index d933f75..6978810 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -57,6 +57,8 @@
 #define SD_CE_ATA_10x10C
 
 #define SD_CE_ATA_20x10E
+#define  SD_CE_ATA2_HS200_EN   BIT(10)
+#define  SD_CE_ATA2_MMC_MODE   BIT(12)
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
@@ -330,6 +332,17 @@ static int pxav3_select_pinstate(struct sdhci_host *host, 
unsigned int uhs)
return pinctrl_select_state(pxa->pinctrl, pinctrl);
 }
 
+static int pxav3_select_hs200(struct sdhci_host *host)
+{
+   u16 reg = 0;
+
+   reg = sdhci_readw(host, SD_CE_ATA_2);
+   reg |= SD_CE_ATA2_HS200_EN | SD_CE_ATA2_MMC_MODE;
+   sdhci_writew(host, reg, SD_CE_ATA_2);
+
+   return 0;
+}
+
 static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
 {
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -361,6 +374,10 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
*host, unsigned int uhs)
case MMC_TIMING_UHS_DDR50:
ctrl_2 |= SDHCI_CTRL_UHS_DDR50 | SDHCI_CTRL_VDD_180;
break;
+   case MMC_TIMING_MMC_HS200:
+   ctrl_2 |= SDHCI_CTRL_UHS_SDR104 | SDHCI_CTRL_VDD_180;
+   pxav3_select_hs200(host);
+   break;
}
 
/*
-- 
1.9.1

--
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/5] mmc: sdhci-pxav3: Add platform specific set_clock ops

[Vaibhav Hiremath]

In case of PXA1928 & family of devices, the TX BUS and internal clock
need to be set as part of ->set_clock() ops, so this patch adds
platform specific ->set_clock() operation.

Note that, in order to not break other platforms, this patch
introduced the flag, which controls whether controller/platform
specific clock configuration needs to be executed.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pxav3.c | 46 +-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index aecae04..c2b2b78 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -48,6 +48,10 @@
 #define  SDCFG_GEN_PAD_CLK_CNT_MASK0xFF
 #define  SDCFG_GEN_PAD_CLK_CNT_SHIFT   24
 
+#define SD_FIFO_PARAM  0x104
+#define  INTERNAL_CLK_GATE_CTRLBIT(8)
+#define  INTERNAL_CLK_GATE_ON  BIT(9)
+
 #define SD_SPI_MODE0x108
 #define SD_CE_ATA_10x10C
 
@@ -57,6 +61,9 @@
 
 #define SD_RX_CFG_REG  0x114
 
+#define TX_CFG_REG 0x118
+#define  TX_INTERNAL_SEL_BUS_CLK   BIT(30)
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
@@ -68,6 +75,9 @@ struct sdhci_pxa_data {
u8 sdclk_delay_shift;
u8 sdclk_sel_mask;
u8 sdclk_sel_shift;
+
+   /* set this if platform needs separate clock configuration */
+   bool set_pltfrm_clk;
/*
 * We have few more differences, add them along with their
 * respective feature support
@@ -90,6 +100,7 @@ static struct sdhci_pxa_data pxav3_data_v1 = {
.sdclk_delay_shift  = 9,
.sdclk_sel_mask = 0x1,
.sdclk_sel_shift= 8,
+   .set_pltfrm_clk = false,
 };
 
 static struct sdhci_pxa_data pxav3_data_v2 = {
@@ -99,6 +110,7 @@ static struct sdhci_pxa_data pxav3_data_v2 = {
/* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
.sdclk_sel_mask = 0x3,
.sdclk_sel_shift= 2,/* SDCLK_SEL1 */
+   .set_pltfrm_clk = true,
 };
 
 /*
@@ -375,8 +387,40 @@ static void pxav3_voltage_switch(struct sdhci_host *host,
writel(val, pxa->io_pwr_reg);
 }
 
+static void pxav3_set_tx_clock(struct sdhci_host *host)
+{
+   u32 val;
+
+   val = sdhci_readl(host, TX_CFG_REG);
+   val |= TX_INTERNAL_SEL_BUS_CLK;
+   sdhci_writel(host, val, TX_CFG_REG);
+}
+
+static void pxav3_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
+
+   /* We still use common sdhci_set_clock() */
+   sdhci_set_clock(host, clock);
+
+   /* platform/controller specific clock configuration */
+   if (pxa->data->set_pltfrm_clk && clock != 0) {
+   u32 val;
+
+   val = sdhci_readw(host, SD_FIFO_PARAM);
+   /* Internal clock gate ON and CTRL = 0b11 */
+   val |= INTERNAL_CLK_GATE_CTRL | INTERNAL_CLK_GATE_ON;
+   sdhci_writew(host, val, SD_FIFO_PARAM);
+
+   /* TX internal clock selection */
+   pxav3_set_tx_clock(host);
+   }
+
+}
+
 static const struct sdhci_ops pxav3_sdhci_ops = {
-   .set_clock  = sdhci_set_clock,
+   .set_clock  = pxav3_set_clock,
.platform_send_init_74_clocks   = pxav3_gen_init_74_clocks,
.get_max_clock  = sdhci_pltfm_clk_get_max_clock,
.set_bus_width  = sdhci_set_bus_width,
-- 
1.9.1

--
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/5] mmc: sdhci-pxav3: Enable pxa1928 device support

[Vaibhav Hiremath]

SDHCI controller present in PXA1928 has few differences as far as
register map is concerned.
For example,

 PXAxxxPXA1928
 =====
 SDCLK_DELAY field   0x10A 0x114
 SDCLK_DELAY mask0x1F  0x3FF
 SDCLK_DELAY shift9  8
 SDCLK_SEL shift  8  2 (SEL1)

So in order to support multi-platform, use sdhci_pxa_regdata structure
as a variant data according to platform.

Note that, there are some more differences, which would be added
as and when respective feature gets added to the driver.

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
 drivers/mmc/host/sdhci-pxav3.c | 62 ++
 1 file changed, 51 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 6d4bad4..aecae04 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -42,9 +42,6 @@
 #define PXAV3_RPM_DELAY_MS 50
 
 #define SD_CLOCK_BURST_SIZE_SETUP  0x10A
-#define SDCLK_SEL  0x100
-#define  SDCLK_DELAY_SHIFT 9
-#define  SDCLK_DELAY_MASK  0x1f
 
 #define SD_CFG_FIFO_PARAM  0x100
 #define  SDCFG_GEN_PAD_CLK_ON  BIT(6)
@@ -58,11 +55,25 @@
 #define  SDCE_MISC_INT BIT(2)
 #define  SDCE_MISC_INT_EN  BIT(1)
 
+#define SD_RX_CFG_REG  0x114
+
 /* IO Power control */
 #define IO_PWR_AKEY_ASFAR  0xbaba
 #define IO_PWR_AKEY_ASSAR  0xeb10
 #define IO_PWR_MMC1_PAD_1V8BIT(2)
 
+struct sdhci_pxa_data {
+   u32 sdclk_delay_reg;
+   u32 sdclk_delay_mask;
+   u8 sdclk_delay_shift;
+   u8 sdclk_sel_mask;
+   u8 sdclk_sel_shift;
+   /*
+* We have few more differences, add them along with their
+* respective feature support
+*/
+};
+
 struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
@@ -70,6 +81,24 @@ struct sdhci_pxa {
void __iomem *sdio3_conf_reg;
void __iomem *io_pwr_reg;
void __iomem *io_pwr_lock_reg;
+   struct sdhci_pxa_data *data;
+};
+
+static struct sdhci_pxa_data pxav3_data_v1 = {
+   .sdclk_delay_reg= SD_CLOCK_BURST_SIZE_SETUP,
+   .sdclk_delay_mask   = 0x1F,
+   .sdclk_delay_shift  = 9,
+   .sdclk_sel_mask = 0x1,
+   .sdclk_sel_shift= 8,
+};
+
+static struct sdhci_pxa_data pxav3_data_v2 = {
+   .sdclk_delay_reg= SD_RX_CFG_REG,
+   .sdclk_delay_mask   = 0x3FF,
+   .sdclk_delay_shift  = 8,
+   /* Only set SDCLK_SEL1, as driver uses default value of SDCLK_SEL0 */
+   .sdclk_sel_mask = 0x3,
+   .sdclk_sel_shift= 2,/* SDCLK_SEL1 */
 };
 
 /*
@@ -183,6 +212,8 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 {
struct platform_device *pdev = to_platform_device(mmc_dev(host->mmc));
struct sdhci_pxa_platdata *pdata = pdev->dev.platform_data;
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_pxa *pxa = pltfm_host->priv;
 
sdhci_reset(host, mask);
 
@@ -193,12 +224,14 @@ static void pxav3_reset(struct sdhci_host *host, u8 mask)
 */
if (pdata && 0 != pdata->clk_delay_cycles) {
u16 tmp;
-
-   tmp = readw(host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
-   tmp |= (pdata->clk_delay_cycles & SDCLK_DELAY_MASK)
-   << SDCLK_DELAY_SHIFT;
-   tmp |= SDCLK_SEL;
-   writew(tmp, host->ioaddr + SD_CLOCK_BURST_SIZE_SETUP);
+   struct sdhci_pxa_data *data = pxa->data;
+
+   tmp = readw(host->ioaddr + data->sdclk_delay_reg);
+   tmp |= (pdata->clk_delay_cycles & 
data->sdclk_delay_mask)
+   << data->sdclk_delay_shift;
+   tmp &= ~(data->sdclk_sel_mask << data->sdclk_sel_shift);
+   tmp |= 1 << data->sdclk_sel_shift;
+   writew(tmp, host->ioaddr + data->sdclk_delay_reg);
}
}
 }
@@ -363,10 +396,16 @@ static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
 #ifdef CONFIG_OF
 static const struct of_device_id sdhci_pxav3_of_match[] = {
{
-   .compatible = "mrvl,pxav3-mmc",
+   .compatible = "mrvl,pxav3-mmc",
+   .data   = (void *)_data_v1,
+   },
+   {
+   .compatible = "marvell,armada-380-sdhci",
+   .data   = (void *)_data_v1,
},
{
-  

[PATCH 0/5] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller

[Vaibhav Hiremath]

PXA1928 SDHCI controller has few differences, for example,

   PXAxxxPXA1928
   =====
   SDCLK_DELAY field   0x10A 0x114
   SDCLK_DELAY mask0x1F  0x3FF
   SDCLK_DELAY shift9  8
   SDCLK_SEL shift  8  2 (SEL1)

So this patch series introduces new compatible device_id
(marvell,pxav3-1928-sdhci), and makes use of .data for handling
such differences.

The series also adds support like,

 - independent ->set_clock() api, as we need to enable internal clock gate
and TX clock
 - pinctrl configuration based on bus speed.
 - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER
   SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the
   clocks, so it is important to configure them as part of ->set_power()
   More detailed description is written into commit log.
 - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id


Testing:
I have done basic testing on both eMMC and SD card on PXA1928 based
platform.

Note: I tried to made sure that I do not break any other platform, which
used sdhci, except HS200 configuration. 
Unfortunately I do not have access to any other datasheets, where I can
cross check the details on HS200 bit-fields. Probably someone who has
access can confirm [PATCH 4/5], whether it impacts other platforms.

Kevin Liu (1):
  mmc: sdhci-pxav3: Fix HS200 mode support

Vaibhav Hiremath (4):
  mmc: sdhci-pxav3: Enable pxa1928 device support
  mmc: sdhci-pxav3: Add platform specific set_clock ops
  mmc: sdhci-pxav3: Add pinctl setting according to bus clock
  mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields

 drivers/mmc/host/sdhci-pltfm.c |   3 +
 drivers/mmc/host/sdhci-pxav3.c | 168 ++---
 drivers/mmc/host/sdhci.c   |   3 +-
 drivers/mmc/host/sdhci.h   |   2 +
 4 files changed, 163 insertions(+), 13 deletions(-)

-- 
1.9.1

--
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 3/3] mmc: sdhci-pxav3: Add ->voltage_switch callback support

[Vaibhav Hiremath]

On Wednesday 02 September 2015 07:21 PM, Shawn Lin wrote:

On 2015/9/2 3:32, Vaibhav Hiremath wrote:

In case PXA1928 family of devices, there is device/controller specific
configuration to control voltage/power on the IO pins.

This patch implements and enables the sdhci_ops->voltage_switch()
callback api.
Note that IO pad register addresses are fetched as a memory resource.

For example, in case of PXA1928 and family of devices, the DT property
would look something like,

sdh1: sdh@d428 {
compatible = "mrvl,pxav3-mmc";
reg-names = "sdhci", "io-pwr", "io-pwr-lock-unlock";
reg = <0xd428 0x120>,
<0xd401e81c 4>,
    <0xd4015068 8>;
...
};

Signed-off-by: Vaibhav Hiremath 
---
  drivers/mmc/host/sdhci-pxav3.c | 59
++
  1 file changed, 59 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c
b/drivers/mmc/host/sdhci-pxav3.c
index 5d26fe0..cebb2f9 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -63,11 +63,18 @@
  #define IO_PWR_AKEY_ASSAR0xeb10
  #define IO_PWR_MMC1_PAD_1V8BIT(2)

+/* IO Power control */
+#define IO_PWR_AKEY_ASFAR0xbaba
+#define IO_PWR_AKEY_ASSAR0xeb10
+#define IO_PWR_MMC1_PAD_1V8BIT(2)
+
  struct sdhci_pxa {
  struct clk *clk_core;
  struct clk *clk_io;
  u8power_mode;
  void __iomem *sdio3_conf_reg;
+void __iomem *io_pwr_reg;
+void __iomem *io_pwr_lock_reg;
  };

  /*
@@ -307,6 +314,38 @@ static void pxav3_set_uhs_signaling(struct
sdhci_host *host, unsigned int uhs)
  __func__, uhs, ctrl_2);
  }

+static void pxav3_voltage_switch(struct sdhci_host *host,
+u8 signal_voltage)
+{
+struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+struct sdhci_pxa *pxa = pltfm_host->priv;
+unsigned int val;
+
+if (!pxa->io_pwr_reg || !pxa->io_pwr_lock_reg)
+return;
+
+/* Lock register is 64 bit: First & Second access register */
+writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+val = readl(pxa->io_pwr_reg);
+
+switch (signal_voltage) {
+case MMC_SIGNAL_VOLTAGE_180:
+case MMC_SIGNAL_VOLTAGE_120:
+val |= IO_PWR_MMC1_PAD_1V8;
+break;
+case MMC_SIGNAL_VOLTAGE_330:
+default:
+val &= ~IO_PWR_MMC1_PAD_1V8;
+break;
+}
+
+writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+
+writel(val, pxa->io_pwr_reg);
+}
+
  static const struct sdhci_ops pxav3_sdhci_ops = {
  .set_clock= sdhci_set_clock,
  .platform_send_init_74_clocks= pxav3_gen_init_74_clocks,
@@ -314,6 +353,7 @@ static const struct sdhci_ops pxav3_sdhci_ops = {
  .set_bus_width= sdhci_set_bus_width,
  .reset= pxav3_reset,
  .set_uhs_signaling= pxav3_set_uhs_signaling,
+.voltage_switch= pxav3_voltage_switch,
  };

  static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
@@ -368,6 +408,7 @@ static int sdhci_pxav3_probe(struct
platform_device *pdev)
  struct sdhci_host *host = NULL;
  struct sdhci_pxa *pxa = NULL;
  const struct of_device_id *match;
+struct resource *res;
  int ret;

  pxa = devm_kzalloc(>dev, sizeof(struct sdhci_pxa),
GFP_KERNEL);
@@ -408,6 +449,24 @@ static int sdhci_pxav3_probe(struct
platform_device *pdev)
  goto err_mbus_win;
  }

+res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"io-pwr-conf");
+if (res) {
+pxa->io_pwr_reg = devm_ioremap_resource(>dev, res);
+if (IS_ERR(pxa->io_pwr_reg)) {
+ret = PTR_ERR(pxa->io_pwr_reg);
+goto err_mbus_win;
+}
+}


Hi Vaibhav,

Why not get it from syscon and use regmap API to deal with it.
IMO, that's okay, you can find examples from
drivers/mmc/host/dw_mmc-k3.c: dw_mci_hi6220_switch_voltage




After looking more into this, things are not looking good to me -

PXA1928 (thats what I have details for) has different needs here,

The lock/unlock register located in apbc_clocks register space, and sysconf
will not be right place for it.

I think the approach which I took in this series looks better to me :)

Thanks,
Vaibhav

--
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 3/3] mmc: sdhci-pxav3: Add ->voltage_switch callback support

[Vaibhav Hiremath]

On Wednesday 02 September 2015 07:21 PM, Shawn Lin wrote:

On 2015/9/2 3:32, Vaibhav Hiremath wrote:

In case PXA1928 family of devices, there is device/controller specific
configuration to control voltage/power on the IO pins.

This patch implements and enables the sdhci_ops->voltage_switch()
callback api.
Note that IO pad register addresses are fetched as a memory resource.

For example, in case of PXA1928 and family of devices, the DT property
would look something like,

sdh1: sdh@d428 {
compatible = "mrvl,pxav3-mmc";
reg-names = "sdhci", "io-pwr", "io-pwr-lock-unlock";
reg = <0xd428 0x120>,
<0xd401e81c 4>,
    <0xd4015068 8>;
...
};

Signed-off-by: Vaibhav Hiremath <vaibhav.hirem...@linaro.org>
---
  drivers/mmc/host/sdhci-pxav3.c | 59
++
  1 file changed, 59 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c
b/drivers/mmc/host/sdhci-pxav3.c
index 5d26fe0..cebb2f9 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -63,11 +63,18 @@
  #define IO_PWR_AKEY_ASSAR0xeb10
  #define IO_PWR_MMC1_PAD_1V8BIT(2)

+/* IO Power control */
+#define IO_PWR_AKEY_ASFAR0xbaba
+#define IO_PWR_AKEY_ASSAR0xeb10
+#define IO_PWR_MMC1_PAD_1V8BIT(2)
+
  struct sdhci_pxa {
  struct clk *clk_core;
  struct clk *clk_io;
  u8power_mode;
  void __iomem *sdio3_conf_reg;
+void __iomem *io_pwr_reg;
+void __iomem *io_pwr_lock_reg;
  };

  /*
@@ -307,6 +314,38 @@ static void pxav3_set_uhs_signaling(struct
sdhci_host *host, unsigned int uhs)
  __func__, uhs, ctrl_2);
  }

+static void pxav3_voltage_switch(struct sdhci_host *host,
+u8 signal_voltage)
+{
+struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+struct sdhci_pxa *pxa = pltfm_host->priv;
+unsigned int val;
+
+if (!pxa->io_pwr_reg || !pxa->io_pwr_lock_reg)
+return;
+
+/* Lock register is 64 bit: First & Second access register */
+writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+val = readl(pxa->io_pwr_reg);
+
+switch (signal_voltage) {
+case MMC_SIGNAL_VOLTAGE_180:
+case MMC_SIGNAL_VOLTAGE_120:
+val |= IO_PWR_MMC1_PAD_1V8;
+break;
+case MMC_SIGNAL_VOLTAGE_330:
+default:
+val &= ~IO_PWR_MMC1_PAD_1V8;
+break;
+}
+
+writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+
+writel(val, pxa->io_pwr_reg);
+}
+
  static const struct sdhci_ops pxav3_sdhci_ops = {
  .set_clock= sdhci_set_clock,
  .platform_send_init_74_clocks= pxav3_gen_init_74_clocks,
@@ -314,6 +353,7 @@ static const struct sdhci_ops pxav3_sdhci_ops = {
  .set_bus_width= sdhci_set_bus_width,
  .reset= pxav3_reset,
  .set_uhs_signaling= pxav3_set_uhs_signaling,
+.voltage_switch= pxav3_voltage_switch,
  };

  static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
@@ -368,6 +408,7 @@ static int sdhci_pxav3_probe(struct
platform_device *pdev)
  struct sdhci_host *host = NULL;
  struct sdhci_pxa *pxa = NULL;
  const struct of_device_id *match;
+struct resource *res;
  int ret;

  pxa = devm_kzalloc(>dev, sizeof(struct sdhci_pxa),
GFP_KERNEL);
@@ -408,6 +449,24 @@ static int sdhci_pxav3_probe(struct
platform_device *pdev)
  goto err_mbus_win;
  }

+res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"io-pwr-conf");
+if (res) {
+pxa->io_pwr_reg = devm_ioremap_resource(>dev, res);
+if (IS_ERR(pxa->io_pwr_reg)) {
+ret = PTR_ERR(pxa->io_pwr_reg);
+goto err_mbus_win;
+}
+}


Hi Vaibhav,

Why not get it from syscon and use regmap API to deal with it.
IMO, that's okay, you can find examples from
drivers/mmc/host/dw_mmc-k3.c: dw_mci_hi6220_switch_voltage




After looking more into this, things are not looking good to me -

PXA1928 (thats what I have details for) has different needs here,

The lock/unlock register located in apbc_clocks register space, and sysconf
will not be right place for it.

I think the approach which I took in this series looks better to me :)

Thanks,
Vaibhav

--
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/2] mmc: sdhci-pxav3: Print ret value on error from sdhci_add_host() fn

[Vaibhav Hiremath]

On Wednesday 02 September 2015 08:37 PM, Joe Perches wrote:

On Wed, 2015-09-02 at 18:37 +0530, Vaibhav Hiremath wrote:

On Wednesday 02 September 2015 02:07 AM, Joe Perches wrote:

On Wed, 2015-09-02 at 00:54 +0530, Vaibhav Hiremath wrote:

Return value would give clear information about the actual root-cause
of the failure.
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
@@ -455,7 +455,7 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)

ret = sdhci_add_host(host);
if (ret) {
-   dev_err(>dev, "failed to add host\n");
+   dev_err(>dev, "failed to add host ret - %d\n", ret);
goto err_add_host;
}


If this is really desirable, there are many other callers of
sdhci_add_host with error messages just like this one.


How about this? If you are ok, I can change it and submit the patch
again.
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c

[]

@@ -3176,8 +3176,11 @@ int sdhci_add_host(struct sdhci_host *host)
  mmc->caps |= MMC_CAP_NEEDS_POLL;

  /* If there are external regulators, get them */
-   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER) {
+   pr_err("%s: regulator supply unavailable, deferring
probe. \n",
+   mmc_hostname(mmc));
  return -EPROBE_DEFER;
+   }


(your email client has inappropriate line wrapping)

The KERN_ here probably isn't right.

Deferring isn't an error, at best it's a notification


I would consider it as an ERROR if it gets deferred
continuously/multiple times due to same reason.


and perhaps should be at pr_notice/KERN_NOTICE



Yeah, KERN_NOTICE looks right here.


I don't know how often or how many times this deferral
can occur.  Do you?



-EDEFER_PROBE usually means that driver has some dependency,
for which it has to wait.
In my case, during every boot, I pxav3_sdhci_probe gets deferred once
due to regulator unavailability.

Thanks,
Vaibhav
--
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 3/3] mmc: sdhci-pxav3: Add ->voltage_switch callback support

[Vaibhav Hiremath]

On Wednesday 02 September 2015 07:21 PM, Shawn Lin wrote:

On 2015/9/2 3:32, Vaibhav Hiremath wrote:

In case PXA1928 family of devices, there is device/controller specific
configuration to control voltage/power on the IO pins.

This patch implements and enables the sdhci_ops->voltage_switch()
callback api.
Note that IO pad register addresses are fetched as a memory resource.

For example, in case of PXA1928 and family of devices, the DT property
would look something like,

sdh1: sdh@d428 {
compatible = "mrvl,pxav3-mmc";
reg-names = "sdhci", "io-pwr", "io-pwr-lock-unlock";
reg = <0xd428 0x120>,
<0xd401e81c 4>,
    <0xd4015068 8>;
...
};

Signed-off-by: Vaibhav Hiremath 
---
  drivers/mmc/host/sdhci-pxav3.c | 59
++
  1 file changed, 59 insertions(+)

diff --git a/drivers/mmc/host/sdhci-pxav3.c
b/drivers/mmc/host/sdhci-pxav3.c
index 5d26fe0..cebb2f9 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -63,11 +63,18 @@
  #define IO_PWR_AKEY_ASSAR0xeb10
  #define IO_PWR_MMC1_PAD_1V8BIT(2)

+/* IO Power control */
+#define IO_PWR_AKEY_ASFAR0xbaba
+#define IO_PWR_AKEY_ASSAR0xeb10
+#define IO_PWR_MMC1_PAD_1V8BIT(2)
+
  struct sdhci_pxa {
  struct clk *clk_core;
  struct clk *clk_io;
  u8power_mode;
  void __iomem *sdio3_conf_reg;
+void __iomem *io_pwr_reg;
+void __iomem *io_pwr_lock_reg;
  };

  /*
@@ -307,6 +314,38 @@ static void pxav3_set_uhs_signaling(struct
sdhci_host *host, unsigned int uhs)
  __func__, uhs, ctrl_2);
  }

+static void pxav3_voltage_switch(struct sdhci_host *host,
+u8 signal_voltage)
+{
+struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+struct sdhci_pxa *pxa = pltfm_host->priv;
+unsigned int val;
+
+if (!pxa->io_pwr_reg || !pxa->io_pwr_lock_reg)
+return;
+
+/* Lock register is 64 bit: First & Second access register */
+writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+val = readl(pxa->io_pwr_reg);
+
+switch (signal_voltage) {
+case MMC_SIGNAL_VOLTAGE_180:
+case MMC_SIGNAL_VOLTAGE_120:
+val |= IO_PWR_MMC1_PAD_1V8;
+break;
+case MMC_SIGNAL_VOLTAGE_330:
+default:
+val &= ~IO_PWR_MMC1_PAD_1V8;
+break;
+}
+
+writel(IO_PWR_AKEY_ASFAR, pxa->io_pwr_lock_reg);
+writel(IO_PWR_AKEY_ASSAR, pxa->io_pwr_lock_reg + 4);
+
+writel(val, pxa->io_pwr_reg);
+}
+
  static const struct sdhci_ops pxav3_sdhci_ops = {
  .set_clock= sdhci_set_clock,
  .platform_send_init_74_clocks= pxav3_gen_init_74_clocks,
@@ -314,6 +353,7 @@ static const struct sdhci_ops pxav3_sdhci_ops = {
  .set_bus_width= sdhci_set_bus_width,
  .reset= pxav3_reset,
  .set_uhs_signaling= pxav3_set_uhs_signaling,
+.voltage_switch= pxav3_voltage_switch,
  };

  static struct sdhci_pltfm_data sdhci_pxav3_pdata = {
@@ -368,6 +408,7 @@ static int sdhci_pxav3_probe(struct
platform_device *pdev)
  struct sdhci_host *host = NULL;
  struct sdhci_pxa *pxa = NULL;
  const struct of_device_id *match;
+struct resource *res;
  int ret;

  pxa = devm_kzalloc(>dev, sizeof(struct sdhci_pxa),
GFP_KERNEL);
@@ -408,6 +449,24 @@ static int sdhci_pxav3_probe(struct
platform_device *pdev)
  goto err_mbus_win;
  }

+res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
"io-pwr-conf");
+if (res) {
+pxa->io_pwr_reg = devm_ioremap_resource(>dev, res);
+if (IS_ERR(pxa->io_pwr_reg)) {
+ret = PTR_ERR(pxa->io_pwr_reg);
+goto err_mbus_win;
+}
+}


Hi Vaibhav,

Why not get it from syscon and use regmap API to deal with it.
IMO, that's okay, you can find examples from
drivers/mmc/host/dw_mmc-k3.c: dw_mci_hi6220_switch_voltage




Thanks Shawn,
Good to know that, something similar is already in the mainline.

Quickly looked into the driver, and I think it looks ok and doable.
I will for couple of days, to see whether I get further comments and then
spin next version.

Thanks,
Vaibhav
--
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/2] mmc: sdhci-pxav3: Print ret value on error from sdhci_add_host() fn

[Vaibhav Hiremath]

On Wednesday 02 September 2015 02:07 AM, Joe Perches wrote:

On Wed, 2015-09-02 at 00:54 +0530, Vaibhav Hiremath wrote:

Return value would give clear information about the actual root-cause
of the failure.
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
@@ -455,7 +455,7 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)

ret = sdhci_add_host(host);
if (ret) {
-   dev_err(>dev, "failed to add host\n");
+   dev_err(>dev, "failed to add host ret - %d\n", ret);
goto err_add_host;
}



If this is really desirable, there are many other callers of
sdhci_add_host with error messages just like this one.



How about this? If you are ok, I can change it and submit the patch
again.


diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d2caa60..3a4902c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3176,8 +3176,11 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->caps |= MMC_CAP_NEEDS_POLL;

/* If there are external regulators, get them */
-   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER)
+   if (mmc_regulator_get_supply(mmc) == -EPROBE_DEFER) {
+   pr_err("%s: regulator supply unavailable, deferring 
probe. \n",

+   mmc_hostname(mmc));
return -EPROBE_DEFER;
+   }

/* If vqmmc regulator and no 1.8V signalling, then there's no 
UHS */

if (!IS_ERR(mmc->supply.vqmmc)) {


Thanks,
Vaibhav
--
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 1/2] mmc: sdhci-pxav3: Fix tabbing issue

[Vaibhav Hiremath]

On Wednesday 02 September 2015 02:01 AM, Joe Perches wrote:

On Wed, 2015-09-02 at 00:54 +0530, Vaibhav Hiremath wrote:

There were some coding style issues where spaces have been used instead
of tabs, for example, in macro definitions, alignment of function
declarations/definitions, etc...

This patch fixes all such occurrences in the code.
And also use BIT for bit definitions.


Please send 2 patches instead.


diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c

[]

@@ -128,7 +133,7 @@ static int mv_conf_mbus_windows(struct platform_device 
*pdev,
  }

  static int armada_38x_quirks(struct platform_device *pdev,
-struct sdhci_host *host)
+   struct sdhci_host *host)


This is not an improvement.



Missed to highlight one more point here,

The kernel CodingStyle talks about indentation, pasting it below -

---
Outside of comments, documentation and except in Kconfig, spaces are
never used for indentation.
---

But I see spaces are being used at lot of places :)

Till now all the patches or drivers which I submitted, I never used
spaces. :)
Anyway, just wanted to highlight CodingStyle document here.

Thanks,
Vaibhav
--
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/