Re: [rtc-linux] Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Krzysztof Kozlowski]

W dniu 28.10.2015 o 19:30, Alim Akhtar pisze:
> Hi Alexandre,
> 
> On 10/28/2015 03:18 PM, Alexandre Belloni wrote:
>> On 28/10/2015 at 12:31:43 +0900, Krzysztof Kozlowski wrote :
>>> The s2mps13 clock driver added new name and compatible... which was
>>> probably totally unneeded (I missed that during review). We don't have
>>> to make this as a rule...
>>>
>>> Since we do not have any data about future workarounds and the
>>> differences then just follow Ockham's razor - use the same name and
>>> compatible.
>>>
>>
>> So you don't care about DT backward compatibility because when a
>> workaround will be needed for one of the IPs, then you will have to
>> update the old dtb to use it.
>>
>> Unless you are sure that the IP is the same, doing
>>
>> { "s2mps15-rtc",S2MPS14X },
>>
>> is probably the best way to handle that. Note that I personally don't
>> care about the DT ABI, I'm just pointing out what may happen ;)
>>
> Thats what my point is, anyway I am still looking into the fine prints
> of the s2mps15 and s2mps14 user manual, now I have found at least one
> difference in their one of the register bit, which might be a good
> reason to keep s2mps15-rtc device.

No, this is not a good reason. Devices may be different but from
driver's perspective they behave the same. This means for example that
they use the same compatible. They can use the same driver name.

We have for example AHCI driver for entire range of different devices.
Some of them are different enough that require special code. So they
have different name and compatible. All of other use the same ahci
driver. But devices are different...

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Alexandre Belloni]

On 28/10/2015 at 22:31:48 +0900, Krzysztof Kozlowski wrote :
> > So you don't care about DT backward compatibility because when a
> > workaround will be needed for one of the IPs, then you will have to
> > update the old dtb to use it.
> 
> Nope, DTB does not contain the name for RTC driver (s2mps15-rtc). It
> will be exactly the same.
> 

Sure, I see it now. So no change is needed in the rtc driver until you
need to use that particular bit that is different.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC

[Krzysztof Kozlowski]

W dniu 28.10.2015 o 17:46, Lee Jones pisze:
> On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
> 
>> On 26.10.2015 23:34, Lee Jones wrote:
>>> On Mon, 26 Oct 2015, Alim Akhtar wrote:
>>>
 From: Thomas Abraham 

 Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
 PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
 clock outputs and battery charger. This patch adds initial support for
 LDO and buck regulators of S2MPS15 device.

 Signed-off-by: Thomas Abraham 
 Signed-off-by: Alim Akhtar 
 [Alim: Added s2mps15_devs like rtc and clk and related changes]
 Reviewed-by: Krzysztof Kozlowski 
 ---
  drivers/mfd/sec-core.c  |   31 +++
  drivers/mfd/sec-irq.c   |8 ++
  include/linux/mfd/samsung/core.h|1 +
  include/linux/mfd/samsung/s2mps15.h |  158 
 +++
  4 files changed, 198 insertions(+)
  create mode 100644 include/linux/mfd/samsung/s2mps15.h
>>>
>>> I replied to the previous set and won't be reviewing this one until
>>> all of the open points are solved.
>>
>> The naming and compatibles used by the driver are confusing but how it
>> was at beginning. Beside the confusion, the names are correct:
>>
>> 1. Main mfd driver:
>>  - compatible: samsung,s2mps1*-pmic
>>  - driver name: sec_pmic
>>
>> 2. Regulator driver:
>>  - no compatible (because it always searches for "regulators" subnode of
>> its parent... that is the convention/legacy behaviour)
>>  - driver name: s2mps1*-pmic
>>
>> I hope that explains your concerns.
> 
> It explains *why*, but doesn't ease my concerns in any way.
> 
> Unfortunately I've only just realised the disparity we have between
> MFD and the Regulator subsystem, which is annoying because it's now
> almost impossible to rectify.  
> 
> We should have taken one of two views.  Either a) The MFD is the PMIC
> device which encompasses regulator control.  In which case the MFD
> and it's corresponding compatible string would be named *-pmic and the
> regulator driver would be called *-regulator. Or b) The MFD could be
> considered a normal MFD and be named after the model number, then the
> regulator 'could' be named *-pmic.
> 
> However, with reference to b), how much other Power Management does
> the regulator driver do besides control regulators?  I suspect not
> much.  Therefore my preference would be for a).  My second choice
> would be a mixuture of the two where nothing gets named *-pmic.  The
> last option on my list would be the current situation where we seem to
> be calling both the MFD (PMIC) itself and the Regulator driver
> *-pmic, which is not good.

Starting from the description of device-family. This is called "Power
Management IC" but it is rather a "Power Deliver/Distribute IC". There
isn't any logic inside except enable/disable/configure/set low power
mode for regulators.

However in the same time the IC comes (always) with:
 - 32kHz clocks,
 - RTC,
 - backup battery charger (no driver for it),
 - reset for SoC,
 - shutdown on thermal alert (also no driver for this control).

The solution a) seems fine to me. Make sense and it looks entirely
backward compatible - only driver names will be modified.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC

[Alim Akhtar]

Hello,

On 10/28/2015 02:16 PM, Lee Jones wrote:

On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:


On 26.10.2015 23:34, Lee Jones wrote:

On Mon, 26 Oct 2015, Alim Akhtar wrote:


From: Thomas Abraham 

Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.

Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski 
---
  drivers/mfd/sec-core.c  |   31 +++
  drivers/mfd/sec-irq.c   |8 ++
  include/linux/mfd/samsung/core.h|1 +
  include/linux/mfd/samsung/s2mps15.h |  158 +++
  4 files changed, 198 insertions(+)
  create mode 100644 include/linux/mfd/samsung/s2mps15.h


I replied to the previous set and won't be reviewing this one until
all of the open points are solved.


The naming and compatibles used by the driver are confusing but how it
was at beginning. Beside the confusion, the names are correct:

1. Main mfd driver:
  - compatible: samsung,s2mps1*-pmic
  - driver name: sec_pmic

2. Regulator driver:
  - no compatible (because it always searches for "regulators" subnode of
its parent... that is the convention/legacy behaviour)
  - driver name: s2mps1*-pmic

I hope that explains your concerns.


It explains *why*, but doesn't ease my concerns in any way.

Unfortunately I've only just realised the disparity we have between
MFD and the Regulator subsystem, which is annoying because it's now
almost impossible to rectify.

We should have taken one of two views.  Either a) The MFD is the PMIC
device which encompasses regulator control.  In which case the MFD
and it's corresponding compatible string would be named *-pmic and the
regulator driver would be called *-regulator. Or b) The MFD could be
considered a normal MFD and be named after the model number, then the
regulator 'could' be named *-pmic.

However, with reference to b), how much other Power Management does
the regulator driver do besides control regulators?  I suspect not
much.  Therefore my preference would be for a).  My second choice
would be a mixuture of the two where nothing gets named *-pmic.  The
last option on my list would be the current situation where we seem to
be calling both the MFD (PMIC) itself and the Regulator driver
*-pmic, which is not good.

Well, I would have also preferred option a), but keeping existing DT 
bindings, looks like we need to go with the current situation.

Krzysztof any thought on this?


diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..db3d4d4ff805 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
  };

+static const struct mfd_cell s2mps15_devs[] = {
+   {
+   .name = "s2mps15-pmic",
+   }, {
+   .name = "s2mps15-rtc",
+   }, {
+   .name = "s2mps15-clk",
+   .of_compatible = "samsung,s2mps15-clk",
+   },
+};
+
  static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+   .compatible = "samsung,s2mps15-pmic",
+   .data = (void *)S2MPS15X,
+   }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
  };

+static const struct regmap_config s2mps15_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = S2MPS15_REG_LDODSCH4,
+   .volatile_reg = s2mps11_volatile,
+   .cache_type = REGCACHE_FLAT,
+};
+
  static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = _regmap_config;
break;
+   case S2MPS15X:
+   regmap = _regmap_config;
+   break;
case S5M8763X:
regmap = _regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+   case S2MPS15X:
+   sec_devs = s2mps15_devs;
+   

Re: [PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC

[Lee Jones]

On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:

> W dniu 28.10.2015 o 17:46, Lee Jones pisze:
> > On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
> > 
> >> On 26.10.2015 23:34, Lee Jones wrote:
> >>> On Mon, 26 Oct 2015, Alim Akhtar wrote:
> >>>
>  From: Thomas Abraham 
> 
>  Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The 
>  S2MPS15
>  PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
>  clock outputs and battery charger. This patch adds initial support for
>  LDO and buck regulators of S2MPS15 device.
> 
>  Signed-off-by: Thomas Abraham 
>  Signed-off-by: Alim Akhtar 
>  [Alim: Added s2mps15_devs like rtc and clk and related changes]
>  Reviewed-by: Krzysztof Kozlowski 
>  ---
>   drivers/mfd/sec-core.c  |   31 +++
>   drivers/mfd/sec-irq.c   |8 ++
>   include/linux/mfd/samsung/core.h|1 +
>   include/linux/mfd/samsung/s2mps15.h |  158 
>  +++
>   4 files changed, 198 insertions(+)
>   create mode 100644 include/linux/mfd/samsung/s2mps15.h
> >>>
> >>> I replied to the previous set and won't be reviewing this one until
> >>> all of the open points are solved.
> >>
> >> The naming and compatibles used by the driver are confusing but how it
> >> was at beginning. Beside the confusion, the names are correct:
> >>
> >> 1. Main mfd driver:
> >>  - compatible: samsung,s2mps1*-pmic
> >>  - driver name: sec_pmic
> >>
> >> 2. Regulator driver:
> >>  - no compatible (because it always searches for "regulators" subnode of
> >> its parent... that is the convention/legacy behaviour)
> >>  - driver name: s2mps1*-pmic
> >>
> >> I hope that explains your concerns.
> > 
> > It explains *why*, but doesn't ease my concerns in any way.
> > 
> > Unfortunately I've only just realised the disparity we have between
> > MFD and the Regulator subsystem, which is annoying because it's now
> > almost impossible to rectify.  
> > 
> > We should have taken one of two views.  Either a) The MFD is the PMIC
> > device which encompasses regulator control.  In which case the MFD
> > and it's corresponding compatible string would be named *-pmic and the
> > regulator driver would be called *-regulator. Or b) The MFD could be
> > considered a normal MFD and be named after the model number, then the
> > regulator 'could' be named *-pmic.
> > 
> > However, with reference to b), how much other Power Management does
> > the regulator driver do besides control regulators?  I suspect not
> > much.  Therefore my preference would be for a).  My second choice
> > would be a mixuture of the two where nothing gets named *-pmic.  The
> > last option on my list would be the current situation where we seem to
> > be calling both the MFD (PMIC) itself and the Regulator driver
> > *-pmic, which is not good.
> 
> Starting from the description of device-family. This is called "Power
> Management IC" but it is rather a "Power Deliver/Distribute IC". There
> isn't any logic inside except enable/disable/configure/set low power
> mode for regulators.
> 
> However in the same time the IC comes (always) with:
>  - 32kHz clocks,
>  - RTC,
>  - backup battery charger (no driver for it),
>  - reset for SoC,
>  - shutdown on thermal alert (also no driver for this control).
> 
> The solution a) seems fine to me. Make sense and it looks entirely
> backward compatible - only driver names will be modified.

Perfect solution from my PoV.

Thanks Krzysztof.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Pending rtc-s3c patches

[Krzysztof Kozlowski]

W dniu 28.10.2015 o 19:14, Alexandre Belloni pisze:
> Hi,
> 
> There are three pending patches (from 2010 and 2011) for rtc-s3c. I'd
> like to get an update and either drop or apply those.
> 
> Can someone take a few minutes to review them?
> 
> The patches are:
> http://patchwork.ozlabs.org/patch/71318/
> http://patchwork.ozlabs.org/patch/99857/
> http://patchwork.ozlabs.org/patch/101732/
> 
> I'm not sure about 71318 but I guess I can take 99857 and 101732.

Hi,

I'll take a look at them in next days. Thanks for digging them out!

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC

[Krzysztof Kozlowski]

W dniu 28.10.2015 o 20:21, Alim Akhtar pisze:
> Hello,
> 
> On 10/28/2015 02:16 PM, Lee Jones wrote:
>> On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
>>
>>> On 26.10.2015 23:34, Lee Jones wrote:
 On Mon, 26 Oct 2015, Alim Akhtar wrote:

> From: Thomas Abraham 
>
> Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The
> S2MPS15
> PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three
> 32.768KHz
> clock outputs and battery charger. This patch adds initial support for
> LDO and buck regulators of S2MPS15 device.
>
> Signed-off-by: Thomas Abraham 
> Signed-off-by: Alim Akhtar 
> [Alim: Added s2mps15_devs like rtc and clk and related changes]
> Reviewed-by: Krzysztof Kozlowski 
> ---
>   drivers/mfd/sec-core.c  |   31 +++
>   drivers/mfd/sec-irq.c   |8 ++
>   include/linux/mfd/samsung/core.h|1 +
>   include/linux/mfd/samsung/s2mps15.h |  158
> +++
>   4 files changed, 198 insertions(+)
>   create mode 100644 include/linux/mfd/samsung/s2mps15.h

 I replied to the previous set and won't be reviewing this one until
 all of the open points are solved.
>>>
>>> The naming and compatibles used by the driver are confusing but how it
>>> was at beginning. Beside the confusion, the names are correct:
>>>
>>> 1. Main mfd driver:
>>>   - compatible: samsung,s2mps1*-pmic
>>>   - driver name: sec_pmic
>>>
>>> 2. Regulator driver:
>>>   - no compatible (because it always searches for "regulators"
>>> subnode of
>>> its parent... that is the convention/legacy behaviour)
>>>   - driver name: s2mps1*-pmic
>>>
>>> I hope that explains your concerns.
>>
>> It explains *why*, but doesn't ease my concerns in any way.
>>
>> Unfortunately I've only just realised the disparity we have between
>> MFD and the Regulator subsystem, which is annoying because it's now
>> almost impossible to rectify.
>>
>> We should have taken one of two views.  Either a) The MFD is the PMIC
>> device which encompasses regulator control.  In which case the MFD
>> and it's corresponding compatible string would be named *-pmic and the
>> regulator driver would be called *-regulator. Or b) The MFD could be
>> considered a normal MFD and be named after the model number, then the
>> regulator 'could' be named *-pmic.
>>
>> However, with reference to b), how much other Power Management does
>> the regulator driver do besides control regulators?  I suspect not
>> much.  Therefore my preference would be for a).  My second choice
>> would be a mixuture of the two where nothing gets named *-pmic.  The
>> last option on my list would be the current situation where we seem to
>> be calling both the MFD (PMIC) itself and the Regulator driver
>> *-pmic, which is not good.
>>
> Well, I would have also preferred option a), but keeping existing DT
> bindings, looks like we need to go with the current situation.
> Krzysztof any thought on this?
> 

Looks good to me. Please, go ahead.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Krzysztof Kozlowski]

W dniu 28.10.2015 o 18:48, Alexandre Belloni pisze:
> On 28/10/2015 at 12:31:43 +0900, Krzysztof Kozlowski wrote :
>> The s2mps13 clock driver added new name and compatible... which was
>> probably totally unneeded (I missed that during review). We don't have
>> to make this as a rule...
>>
>> Since we do not have any data about future workarounds and the
>> differences then just follow Ockham's razor - use the same name and
>> compatible.
>>
> 
> So you don't care about DT backward compatibility because when a
> workaround will be needed for one of the IPs, then you will have to
> update the old dtb to use it.

Nope, DTB does not contain the name for RTC driver (s2mps15-rtc). It
will be exactly the same.

> 
> Unless you are sure that the IP is the same, doing
> 
> { "s2mps15-rtc",  S2MPS14X },
> 
> is probably the best way to handle that. Note that I personally don't
> care about the DT ABI, I'm just pointing out what may happen ;)

In case of RTC driver there is no chance of DT ABI issues here.

The clock driver is different because it contain a compatible.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [GIT PULL 4/5] Late Samsung driver updates for v4.4

[Pavel Fedin]

 Hello!

> The question is - do you prefer us to send a following up patch or to
> fix it by amending the commit?
> 
> Here is a fix which can be squashed into these two commits:

 By the way, since we are discussing fixing these commits...
 After hardcoded SROMc handling has been removed, Exynos5410-based machines 
stopped handling it entirely, because the description
has never been added to exynos5410.dtsi (which does not include exynos5.dtsi). 
Shouldn't the description be added there too?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 4/5] Late Samsung driver updates for v4.4

[Krzysztof Kozlowski]

On 28.10.2015 17:00, Pavel Fedin wrote:
>  Hello!
> 
>> The Exynos5410 in current form does not have suspend capability. During
>> boot you should see in dmesg:
>>  Failed to find PMU node
>> coming from mach-exynos/suspend.c.
> 
>  Indeed. By the way, can this be a reason why reboot stopped working? It 
> worked in v4.1. Isn't this a regression?
>  Ok, nevertheless, here is v3 of my patchset.

The noticeable change between v4.1 and v4.2 was for example:
c4241a582d22 ("ARM: EXYNOS: use PS_HOLD based poweroff for all supported
SoCs")

Can you try whether reverting it fixes the issue?

I don't recall any other changes which could affect Exynos5410.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 06/17] dt-bindings: add document for analogix display port driver

[Yakir Yang]

Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
  properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"

Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
  devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt| 50 +
 .../bindings/display/exynos/exynos_dp.txt  | 65 --
 2 files changed, 72 insertions(+), 43 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+   -compatible:
+   platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+   -reg:
+   physical base address of the controller and length
+   of memory mapped region.
+   -interrupts:
+   interrupt combiner values.
+   -clocks:
+   from common clock binding: handle to dp clock.
+   -clock-names:
+   from common clock binding: Shall be "dp".
+   -interrupt-parent:
+   phandle to Interrupt combiner node.
+   -phys:
+   from general PHY binding: the phandle for the PHY device.
+   -phy-names:
+   from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+   -hpd-gpios:
+   Hotplug detect GPIO.
+   Indicates which GPIO should be used for hotplug detection
+   -port@[X]: SoC specific port nodes with endpoint definitions as defined
+   in Documentation/devicetree/bindings/media/video-interfaces.txt,
+   please refer to the SoC specific binding document:
+   * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+   * 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+   dp-controller {
+   compatible = "samsung,exynos5-dp";
+   reg = <0x145b 0x1>;
+   interrupts = <10 3>;
+   interrupt-parent = <>;
+   clocks = < 342>;
+   clock-names = "dp";
+
+   phys = <_phy>;
+   phy-names = "dp";
+   };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 7a3a9cd..9905081 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
-   -samsung,color-space:
-   input video data format.
-   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-   -samsung,dynamic-range:
-   dynamic range for input video data.
-   VESA = 0, CEA = 1
-   -samsung,ycbcr-coeff:
-   YCbCr co-efficients for input video.
-   COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-   -samsung,color-depth:
-   number of bits per colour component.
-   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-   -samsung,link-rate:
-   link rate supported by the panel.
-  

[PATCH v8 05/17] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Yakir Yang]

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).

Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)

Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 3 files changed, 103 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 96afb67..6307060 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}
 
-   ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1030,6 +1030,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   struct drm_display_info *display_info = >connector->display_info;
+   struct video_info *video = >video_info;
+   struct device_node *dp_node = dp->dev->of_node;
+   int vic;
+
+   /* Input video interlaces & hsync pol & vsync pol */
+   video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+   video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+   /* Input video dynamic_range & colorimetry */
+   vic = drm_match_cea_mode(mode);
+   if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+   (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR601;
+   } else if (vic) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   } else {
+   video->dynamic_range = VESA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   }
+
+   /* Input vide bpc and color_formats */
+   switch (display_info->bpc) {
+   case 12:
+   video->color_depth = COLOR_12;
+   break;
+   case 10:
+   video->color_depth = COLOR_10;
+   break;
+   case 8:
+   video->color_depth = COLOR_8;
+   break;
+   case 6:
+   video->color_depth = COLOR_6;
+   break;
+   default:
+   video->color_depth = COLOR_8;
+   break;
+   }
+   if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+   video->color_space = COLOR_YCBCR444;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   video->color_space = COLOR_YCBCR422;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+   video->color_space = COLOR_RGB;
+   else
+   video->color_space = COLOR_RGB;
+
+   /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep 

[PATCH v8 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM

But  there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
   dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
   between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
   register).

This series have been well tested on Rockchip platform with eDP panel on
Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier@Samsung
help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook,
glad to say that things works rightlly.

Thanks,
- Yakir


Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
- Simplify the commit message. (Kishon)

Changes in v6:
- Fix the wrong code in previous series, and test on Samsung snow Chromebook
  successfully, here are the detail changes:
=>
-   if (!dp->panel && !dp->bridge) {
+   if (!dp->panel && !dp->ptn_bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
=>
+   encoder->bridge = bridge;
bridge->driver_private = dp;
bridge->encoder = encoder;
bridge->funcs = _dp_bridge_funcs;
ret = drm_bridge_attach(drm_dev, bridge);
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in 

[PATCH v8 04/17] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

[Yakir Yang]

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04

Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
  directly, but we can take those as hardware limite. For example, RK3288
  only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
  like "link-rate = 0x0a" "lane-count = 4". (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 334181c..96afb67 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
analogix_dp_device *dp,
/*
 * For DP rev.1.1, Maximum link rate of Main Link lanes
 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 */
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, );
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, >link_train.lane_count);
 
if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-   (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+   (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+   (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);
 
-   analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
-   analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 14d20be..9a90a18 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
 #define MAX_EQ_LOOP 5
 
 enum link_rate_type {
-   LINK_RATE_1_62GBPS = 0x06,
-   LINK_RATE_2_70GBPS = 0x0a
+   LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+   LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+   LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
 };
 
 enum link_lane_count_type {
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 10/17] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Yakir Yang 
---
Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)

Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)

Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

Changes in v2: None

 drivers/phy/Kconfig   |   7 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-rockchip-dp.c | 155 ++
 3 files changed, 163 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..c82c22f
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,155 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+   int ret;
+
+   if (enable) {
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_ON);
+   if (ret < 0) {
+   dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dp->phy_24m);
+   } else {
+   clk_disable_unprepare(dp->phy_24m);
+
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_OFF);
+   }
+
+   return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, false);
+}
+
+static const struct phy_ops rockchip_dp_phy_ops = {
+   .power_on   = 

Re: [PATCH 3/7] ARM: exynos_defconfig: enable Exynos DRM Mixer driver

[Krzysztof Kozlowski]

On 26.10.2015 21:03, Andrzej Hajda wrote:
> Mixer driver is selected by CONFIG_DRM_EXYNOS_HDMI option. Since Exynos5433
> HDMI does not require Mixer. There will be separate options to select Mixer
> and HDMI. Adding new option to defconfig before Kconfig will allow to keep
> bisectability.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  arch/arm/configs/exynos_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Krzysztof Kozlowski 

I guess this will go with rest of patchset through Exynos DRM tree:
Acked-by: Krzysztof Kozlowski 


Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/7] ARM: exynos_defconfig: enable Exynos DRM Mixer driver

[Inki Dae]

2015년 10월 28일 15:09에 Krzysztof Kozlowski 이(가) 쓴 글:
> On 26.10.2015 21:03, Andrzej Hajda wrote:
>> Mixer driver is selected by CONFIG_DRM_EXYNOS_HDMI option. Since Exynos5433
>> HDMI does not require Mixer. There will be separate options to select Mixer
>> and HDMI. Adding new option to defconfig before Kconfig will allow to keep
>> bisectability.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>>  arch/arm/configs/exynos_defconfig | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Reviewed-by: Krzysztof Kozlowski 
> 
> I guess this will go with rest of patchset through Exynos DRM tree:
> Acked-by: Krzysztof Kozlowski 

Thanks for ack. I will pick it up.

Thanks,
Inki Dae

> 
> 
> Best regards,
> Krzysztof
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

 Hello!

> > +   sromc: sromc@1225 {
> > +   compatible = "samsung,exynos-srom";
> > +   reg = <0x1225 0x10>;
> 
> Isn't 0x10 too small (SROM_BC3 won't be mapped)?

 Muhaha, indeed, thanks for noticing this.
 By the way, i've just checked exynos4.dtsi and exynos5.dtsi, they specify the 
same size. Did reviewers overlook this small thing?
Shouldn't it be fixed then?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/4] ARM: dts: Add SROMc to Exynos 5410

[Krzysztof Kozlowski]

On 28.10.2015 16:06, Pavel Fedin wrote:
>  Hello!
> 
>>> +   sromc: sromc@1225 {
>>> +   compatible = "samsung,exynos-srom";
>>> +   reg = <0x1225 0x10>;
>>
>> Isn't 0x10 too small (SROM_BC3 won't be mapped)?
> 
>  Muhaha, indeed, thanks for noticing this.
>  By the way, i've just checked exynos4.dtsi and exynos5.dtsi, they specify 
> the same size. Did reviewers overlook this small thing?

Yep, I pointed that 0x100 (from first version of patchset) is too big...
but did not exactly check the length of new value.

> Shouldn't it be fixed then?

Yes. It hasn't been pulled yet by arm-soc... Let's wait Kukjin's opinion
how to deal with exynos[45].dtsi.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

 Hello!

> Yes. It hasn't been pulled yet by arm-soc... Let's wait Kukjin's opinion
> how to deal with exynos[45].dtsi.

 I can simply include it into my patchset, two more lines aren't a problem for 
me.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 4/5] Late Samsung driver updates for v4.4

[Krzysztof Kozlowski]

On 24.10.2015 06:26, Kukjin Kim wrote:
> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> 
>   Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
> tags/samsung-driver
> 
> for you to fetch changes up to c612d5a7785b307df96938d590c3a1edfb624ccf:
> 
>   cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs (2015-10-24
> 04:34:50 +0900)
> 
> 
> Samsung driver udpates for v4.4
> 
> - add support for exynos SROM controller DT based driver
>   (drivers/soc/samsung/exynos-srom.c)
>   : Since the exynos SROM registers are used during Suspend to RAM
> so the exynos SROM driver handles the S2R and then we can remove
> static mapping for SROM registers.
>   : Pankaj tested boot and S2R functionality on Peach-Pi chromebook
>   : Pavel tested on SMDK5410 board
>   : Krzysztof tested on Trats2 (exynos4412) board
> - update Maintainer entry accordingly
> - remove superfluous CONFIG_PM ifdefs with Viresh's ack
> 
> 
> Bartlomiej Zolnierkiewicz (1):
>   cpufreq: s5pv210: remove superfluous CONFIG_PM ifdefs
> 
> Pankaj Dubey (8):
>   ARM: EXYNOS: remove unused static mapping of CMU for exynos5
>   ARM: EXYNOS: code cleanup in map.h
>   dt-bindings: add exynos-srom device tree binding
>   ARM: dts: add SROM device node for exynos4
>   ARM: dts: add SROM device node for exynos5

Hi Olof and Kukjin,

I see that this pull request was not pulled yet. (Un)Fortunately I
spotted one mistake in DTS changes above - the length of mapped region
is too small by one word. This does not produce any visible effect but
actually is wrong because driver will read from unmapped memory.


The question is - do you prefer us to send a following up patch or to
fix it by amending the commit?

Here is a fix which can be squashed into these two commits:
-- >8 --
Subject: [PATCH] ARM: dts: Fix size of mapped SROMC memory region on
 exynos[45]

The SROMC memory region contains 5 registers so the size of mapped
memory should be 0x14 instead of 0x10.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4.dtsi | 2 +-
 arch/arm/boot/dts/exynos5.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2f31f773b096..ffda7f5118cd 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -78,7 +78,7 @@

sromc@1257 {
compatible = "samsung,exynos-srom";
-   reg = <0x1257 0x10>;
+   reg = <0x1257 0x14>;
};

mipi_phy: video-phy@10020710 {
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index b5d3437922c5..fb52d16fba33 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -32,7 +32,7 @@

sromc@1225 {
compatible = "samsung,exynos-srom";
-   reg = <0x1225 0x10>;
+   reg = <0x1225 0x14>;
};

combiner: interrupt-controller@1044 {
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL 4/5] Late Samsung driver updates for v4.4

[Krzysztof Kozlowski]

On 28.10.2015 16:49, Pavel Fedin wrote:
>  Hello!
> 
>> The question is - do you prefer us to send a following up patch or to
>> fix it by amending the commit?
>>
>> Here is a fix which can be squashed into these two commits:
> 
>  By the way, since we are discussing fixing these commits...
>  After hardcoded SROMc handling has been removed, Exynos5410-based machines 
> stopped handling it entirely, because the description
> has never been added to exynos5410.dtsi (which does not include 
> exynos5.dtsi). Shouldn't the description be added there too?

No, it is not needed.
The Exynos5410 in current form does not have suspend capability. During
boot you should see in dmesg:
Failed to find PMU node
coming from mach-exynos/suspend.c.

In suspend.c there is no compatible for Exynos5410.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

Add documentation for new properties, allowing bank configuration.

Signed-off-by: Pavel Fedin 
---
 .../bindings/arm/samsung/exynos-srom.txt   | 24 +-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..9e4a40b 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,30 @@ Required properties:
 
 - reg: offset and length of the register set
 
-Example:
+Bank configurations can be defined in optional subnodes. Each subnode
+describes one bank and contains the following:
+
+Required properties:
+- bank : bank number (0 - 3)
+
+- srom-timing : array of 7 integers: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs
+
+Optional properties:
+- width : data width in bytes (1 or 2). If omitted, default of 1 is used.
+
+Example: basic definition, no banks are configured
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x10>;
+   };
+
+Example: SROMc with bank3 configuration
sromc@1257 {
compatible = "samsung,exynos-srom";
reg = <0x1257 0x10>;
+   bank@3 {
+   bank = <3>;
+   width = <2>;
+   srom-timing = <1 9 12 1 9 1 1>;
+   };
};
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Pavel Fedin]

This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.

With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.

This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html

Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.

v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now

v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation

Pavel Fedin (4):
  Documentation: dt-bindings: Describe SROMc configuration
  ARM: dts: Add SROMc to Exynos 5410
  drivers: exynos-srom: Add support for bank configuration
  ARM: dts: Add Ethernet chip to SMDK5410

 .../bindings/arm/samsung/exynos-srom.txt   | 24 -
 arch/arm/boot/dts/exynos5410-smdk5410.dts  | 42 ++
 arch/arm/boot/dts/exynos5410.dtsi  |  5 +++
 arch/arm/mach-exynos/Kconfig   |  2 +-
 drivers/soc/samsung/Kconfig|  2 +-
 drivers/soc/samsung/exynos-srom.c  | 42 +-
 6 files changed, 113 insertions(+), 4 deletions(-)

-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

This machine uses own SoC device tree file, add missing part.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..e2b58f8 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,11 @@
reg = <0x1000 0x100>;
};
 
+   sromc: sromc@1225 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x14>;
+   };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 4/4] ARM: dts: Add Ethernet chip to SMDK5410

[Pavel Fedin]

The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410-smdk5410.dts | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..2a6a5ac 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -35,6 +35,17 @@
reg = <0x02037000 0x1000>;
};
 
+   ethernet@0700 {
+   compatible = "smsc,lan9115";
+   reg = <0x0700 0x1>;
+   phy-mode = "mii";
+   interrupt-parent = <>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+   };
+
 };
 
 _0 {
@@ -61,6 +72,27 @@
disable-wp;
 };
 
+_0 {
+   srom_ctl: srom-ctl {
+   samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+  "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+   samsung,pin-function = <2>;
+   samsung,pin-drv = <0>;
+   };
+
+   srom_ebi: srom-ebi {
+   samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+  "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+  "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+  "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+  "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+  "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+};
+
  {
status = "okay";
 };
@@ -72,3 +104,13 @@
  {
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ctl>, <_ebi>;
+   bank@3 {
+   bank = <3>;
+   width = <2>;
+   srom-timing = <1 9 12 1 9 1 1>;
+   };
+};
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/4] drivers: exynos-srom: Add support for bank configuration

[Pavel Fedin]

Bindings are based on u-boot implementation, however they are stored in
subnodes, providing support for more than one bank.

Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.

Signed-off-by: Pavel Fedin 
---
 arch/arm/mach-exynos/Kconfig  |  2 +-
 drivers/soc/samsung/Kconfig   |  2 +-
 drivers/soc/samsung/exynos-srom.c | 42 ++-
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
-   select EXYNOS_SROM if PM
+   select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
 
 config EXYNOS_SROM
bool
-   depends on ARM && ARCH_EXYNOS && PM
+   depends on ARM && ARCH_EXYNOS
 
 endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c 
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..6c8c56a 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -67,9 +67,46 @@ static struct exynos_srom_reg_dump 
*exynos_srom_alloc_reg_dump(
return rd;
 }
 
+static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
+{
+   u32 bank, width;
+   u32 timing[7];
+   u32 bw;
+
+   if (of_property_read_u32(np, "bank", ))
+   return -ENXIO;
+   if (of_property_read_u32(np, "width", ))
+   width = 1;
+   if (of_property_read_u32_array(np, "srom-timing", timing, 7)) {
+   pr_err("Could not decode SROMC configuration\n");
+   return -ENXIO;
+   }
+
+   bank *= 4; /* Convert bank into shift/offset */
+
+   bw = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+   if (width == 2)
+   bw |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+   bw <<= bank;
+   bw |= __raw_readl(srom->reg_base + EXYNOS_SROM_BW) &
+ ~(EXYNOS_SROM_BW__CS_MASK << bank);
+   __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+   __raw_writel((timing[0] << EXYNOS_SROM_BCX__PMC__SHIFT) |
+   (timing[1] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+   (timing[2] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+   (timing[3] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+   (timing[4] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+   (timing[5] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+   (timing[6] << EXYNOS_SROM_BCX__TACS__SHIFT),
+   srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+   return 0;
+}
+
 static int exynos_srom_probe(struct platform_device *pdev)
 {
-   struct device_node *np;
+   struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = >dev;
 
@@ -100,6 +137,9 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
+   for_each_child_of_node(np, child)
+   decode_sromc(srom, child);
+
return 0;
 }
 
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [GIT PULL 4/5] Late Samsung driver updates for v4.4

[Pavel Fedin]

 Hello!

> The Exynos5410 in current form does not have suspend capability. During
> boot you should see in dmesg:
>   Failed to find PMU node
> coming from mach-exynos/suspend.c.

 Indeed. By the way, can this be a reason why reboot stopped working? It worked 
in v4.1. Isn't this a regression?
 Ok, nevertheless, here is v3 of my patchset.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 01/17] drm: exynos: dp: convert to drm bridge mode

[Yakir Yang]

In order to move exynos dp code to bridge directory,
we need to convert driver drm bridge mode first. As
dp driver already have a ptn3460 bridge, so we need
to move ptn bridge to the next bridge of dp bridge.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix the wrong code in previous series, and test on Samsung snow Chromebook
  successfully, here are the detail changes:
=>
-   if (!dp->panel && !dp->bridge) {
+   if (!dp->panel && !dp->ptn_bridge) {
ret = exynos_dp_dt_parse_panel(dp);
if (ret)
=>
+   encoder->bridge = bridge;
bridge->driver_private = dp;
bridge->encoder = encoder;
bridge->funcs = _dp_bridge_funcs;
ret = drm_bridge_attach(drm_dev, bridge);

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Keep author name list no changed (Jingoo)

 drivers/gpu/drm/exynos/exynos_dp_core.c | 103 
 drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
 2 files changed, 78 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 124fb9a..aedd074 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
 {
int ret;
 
-   encoder->bridge = dp->bridge;
-   dp->bridge->encoder = encoder;
-   ret = drm_bridge_attach(encoder->dev, dp->bridge);
+   encoder->bridge->next = dp->ptn_bridge;
+   dp->ptn_bridge->encoder = encoder;
+   ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
return ret;
@@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
exynos_dp_device *dp,
return 0;
 }
 
-static int exynos_dp_create_connector(struct drm_encoder *encoder)
+static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
+   struct drm_encoder *encoder = >encoder;
struct drm_connector *connector = >connector;
int ret;
 
/* Pre-empt DP connector creation if there's a bridge */
-   if (dp->bridge) {
+   if (dp->ptn_bridge) {
ret = exynos_drm_attach_lcd_bridge(dp, encoder);
if (!ret)
return 0;
@@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct drm_encoder 
*encoder)
return ret;
 }
 
-static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
-const struct drm_display_mode *mode,
-struct drm_display_mode *adjusted_mode)
-{
-   return true;
-}
-
-static void exynos_dp_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void exynos_dp_enable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
@@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder *encoder)
dp->dpms_mode = DRM_MODE_DPMS_ON;
 }
 
-static void exynos_dp_disable(struct drm_encoder *encoder)
+static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
 {
-   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct exynos_dp_device *dp = bridge->driver_private;
struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
 
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
@@ -1123,6 +,69 @@ static void exynos_dp_disable(struct drm_encoder 
*encoder)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }
 
+static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
+{
+   /* do nothing */
+}
+
+static const struct drm_bridge_funcs exynos_dp_bridge_funcs = {
+   .enable = exynos_dp_bridge_enable,
+   .disable = exynos_dp_bridge_disable,
+   .pre_enable = exynos_dp_bridge_nop,
+   .post_disable = exynos_dp_bridge_nop,
+   .attach = exynos_dp_bridge_attach,
+};
+
+static int exynos_dp_create_connector(struct drm_encoder *encoder)
+{
+   struct exynos_dp_device *dp = encoder_to_dp(encoder);
+   struct drm_device *drm_dev = dp->drm_dev;
+   struct drm_bridge *bridge;
+   int ret;
+
+   bridge = devm_kzalloc(drm_dev->dev, sizeof(*bridge), GFP_KERNEL);
+   if (!bridge) {
+   DRM_ERROR("failed to allocate for drm bridge\n");
+   return 

[PATCH v8 03/17] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
-  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
+  retval =
+  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
 3 files changed, 163 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e561590..334181c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 
while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
 
/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   _block);
+   EDID_EXTENSION_FLAG,
+   _block);
if (retval)
return retval;
 
@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");
 
/* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp, 
I2C_EDID_DEVICE_ADDR,
+   retval = analogix_dp_read_bytes_from_i2c(dp,
+   I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
}
 
analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   _vector);
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
 
/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   [EDID_HEADER_PATTERN]);
+   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, [EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct 
analogix_dp_device *dp)
return -EIO;
}
 
-   analogix_dp_read_byte_from_dpcd(dp,
-   DP_TEST_REQUEST,
-   _vector);
+   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+   _vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_EDID_CHECKSUM,
-   

[PATCH v8 08/17] drm: rockchip: dp: add rockchip platform dp driver

[Yakir Yang]

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)

Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
  and leave "sclk_edp" to analogix dp core driver which name to "dp",
  and leave "pclk_edp" to rockchip dp platform driver which name to
  "pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
  node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.

Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
  for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 442 
 include/drm/bridge/analogix_dp.h|   1 +
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..c2ba945 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_ANALOGIX_DP
+tristate "Rockchip specific extensions for Analogix DP driver"
+depends on DRM_ROCKCHIP
+select DRM_ANALOGIX_DP
+help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..8ad01fb 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o
 
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
 
 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..2c82a9a
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,442 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan 
+ * Yakir Yang 
+ * Jeff Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+   struct drm_device*drm_dev;
+   struct device*dev;
+   struct drm_encoder   encoder;
+   struct drm_connector connector;
+   struct drm_display_mode  mode;
+
+   struct clk   *pclk;
+   struct regmap*grf;
+   struct reset_control *rst;
+
+   struct analogix_dp_plat_data plat_data;
+};
+
+static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
+{
+   reset_control_assert(dp->rst);
+   usleep_range(10, 20);
+   

[PATCH v8 07/17] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Yakir Yang]

After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.

Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.

Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
-   hpd-gpio = < 6 0>;
+   hpd-gpios = < 6 0>;

Changes in v5:
- Correct the misspell in commit message. (Krzysztof)

Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-arndale.dts  | 2 --
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
 arch/arm/boot/dts/exynos5250-spring.dts   | 4 +---
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
 arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
 7 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
  {
status = "okay";
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@
 
  {
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408..ee94110 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 7 GPIO_ACTIVE_HIGH>;
 
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
-   samsung,hpd-gpio = < 0 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 0 GPIO_ACTIVE_HIGH>;
 };
 
  {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f0..8baf40a 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = < 6 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = < 6 GPIO_ACTIVE_HIGH>;
 
ports {
port@0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..e5a4cd5 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ 

[PATCH v8 09/17] dt-bindings: add document for rockchip variant of analogix_dp

[Yakir Yang]

Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Yakir Yang 
---
Changes in v8:
- Modify the commit subject name. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../display/rockchip/analogix_dp-rockchip.txt  | 90 ++
 1 file changed, 90 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..ec93917
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,90 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+  Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: contain a port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+   dp-controller: dp@ff97 {
+   compatible = "rockchip,rk3288-dp";
+   reg = <0xff97 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_EDP>, < PCLK_EDP_CTRL>;
+   clock-names = "dp", "pclk";
+   phys = <_phy>;
+   phy-names = "dp";
+
+   rockchip,grf = <>;
+   resets = < 111>;
+   reset-names = "dp";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_hpd>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in: port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_edp>;
+   };
+   edp_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <_out_edp>;
+   };
+   };
+
+   edp_out: port@1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_out_panel: endpoint {
+   reg = <0>;
+   remote-endpoint = <_in_edp>
+   };
+   };
+   };
+   };
+
+   pinctrl {
+   edp {
+   edp_hpd: edp-hpd {
+   rockchip,pins = <7 11 RK_FUNC_2 
_pull_none>;
+   };
+   };
+   };
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 11/17] dt-bindings: add document for rockchip dp phy

[Yakir Yang]

Add dt binding documentation for rockchip display port PHY.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Yakir Yang 
---
Changes in v8:
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Simplify the commit message. (Kishon)

Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..00902cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip Soc Seroes Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+   compatible = "rockchip,rk3288-dp-phy";
+   rockchip,grf = <>;
+   clocks = < SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+};
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pending rtc-s3c patches

[Alexandre Belloni]

Hi,

There are three pending patches (from 2010 and 2011) for rtc-s3c. I'd
like to get an update and either drop or apply those.

Can someone take a few minutes to review them?

The patches are:
http://patchwork.ozlabs.org/patch/71318/
http://patchwork.ozlabs.org/patch/99857/
http://patchwork.ozlabs.org/patch/101732/

I'm not sure about 71318 but I guess I can take 99857 and 101732.

Thanks,

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/13] drm/exynos: async G2D and g2d_move()

[Tobias Jakobi]

Another ping!

With best wishes,
Tobias


Tobias Jakobi wrote:
> Hello,
> 
> this series mostly touches G2D code. It introduces the following:
> 
> (1) drmHandleEvent2() is added to enable processing of vendor-specific
> events. This will be used to expose asynchronous operation of the
> G2D. The necessary kernel infrastructure is already there since
> a lot of kernel versions. [This touches libdrm core code!]
> 
> (2) The necessary infrastructure to handle G2D events. This includes
> adding g2d_config_event() and g2d_exec2() to the public API.
> A test application is provided to ensure that everything works
> as expected.
> 
> (3) A small performance test application which can be used to measure
> the speed of solid color clear operations. Interesting for
> benchmarking and plotting colorful graphs (e.g. through
> Mathematica).
> 
> (4) g2d_move() which works similar to g2d_copy() but like the C
> memmove() properly handles overlapping buffer copies.
> Again a test application is present to check that this
> indeed does what it should.
> 
> (5) Various small changes. A framebuffer colorformat fix for the
> general G2D test application. Moving the currently unused
> g2d_reset() to the public API. Adding a counterpart to
> exynos_bo_map() to unmap buffers again.
> 
> (6) Last but not least a small bump of the Exynos version number.
> 
> Please review and let me know what I should change/improve.
> 
> 
> With best wishes,
> Tobias
> 
> P.S.: Most patches were submitted already some time ago but never
> made it upstream. So if something looks familiar, don't worry! ;)
> 
> Tobias Jakobi (13):
>   drm: Implement drmHandleEvent2()
>   exynos: Introduce exynos_handle_event()
>   tests/exynos: add fimg2d performance analysis
>   exynos/fimg2d: add g2d_config_event
>   exynos: fimg2d: add g2d_exec2
>   tests/exynos: add fimg2d event test
>   tests/exynos: use XRGB for framebuffer
>   exynos: fimg2d: add g2d_set_direction
>   exynos/fimg2d: add g2d_move
>   tests/exynos: add test for g2d_move
>   exynos/fimg2d: add exynos_bo_unmap()
>   exynos/fimg2d: add g2d_reset() to public API
>   exynos: bump version number
> 
>  exynos/exynos-symbol-check |   5 +
>  exynos/exynos_drm.c|  48 ++
>  exynos/exynos_drm.h|  12 ++
>  exynos/exynos_drmif.h  |  27 +++
>  exynos/exynos_fimg2d.c | 164 +--
>  exynos/exynos_fimg2d.h |  49 ++
>  exynos/libdrm_exynos.pc.in |   2 +-
>  tests/exynos/Makefile.am   |  26 ++-
>  tests/exynos/exynos_fimg2d_event.c | 326 
> +
>  tests/exynos/exynos_fimg2d_perf.c  | 320 
>  tests/exynos/exynos_fimg2d_test.c  | 134 ++-
>  xf86drm.h  |  21 +++
>  xf86drmMode.c  |  10 +-
>  13 files changed, 1128 insertions(+), 16 deletions(-)
>  create mode 100644 tests/exynos/exynos_fimg2d_event.c
>  create mode 100644 tests/exynos/exynos_fimg2d_perf.c
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 06/17] dt-bindings: add document for analogix display port driver

[Heiko Stuebner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:26:33 schrieb Yakir Yang:
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 7a3a9cd..9905081 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -31,45 +31,31 @@ Required properties for dp-controller:
>   from general PHY binding: the phandle for the PHY device.
>   -phy-names:
>   from general PHY binding: Should be "dp".
> - -samsung,color-space:
> - input video data format.
> - COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
> - -samsung,dynamic-range:
> - dynamic range for input video data.
> - VESA = 0, CEA = 1
> - -samsung,ycbcr-coeff:
> - YCbCr co-efficients for input video.
> - COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> - -samsung,color-depth:
> - number of bits per colour component.
> - COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> - -samsung,link-rate:
> - link rate supported by the panel.
> - LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
> - -samsung,lane-count:
> - number of lanes supported by the panel.
> - LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> - - display-timings: timings for the connected panel as described by
> - Documentation/devicetree/bindings/video/display-timing.txt

^^ display/display-timings.txt
otherwise this patch does not apply.

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

On 28.10.2015 16:57, Pavel Fedin wrote:
> Add documentation for new properties, allowing bank configuration.
> 
> Signed-off-by: Pavel Fedin 
> ---
>  .../bindings/arm/samsung/exynos-srom.txt   | 24 
> +-
>  1 file changed, 23 insertions(+), 1 deletion(-)

You missed here a lot of potential Cc. Please use get_maintainer.pl
script. It *must* be sent to devicetree list.

Please send it also to DeviceTree maintainers because you are adding
quite generic names for bindings so they may have interesting thoughts
on this.

LKML list is also missing.

> 
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> index 33886d5..9e4a40b 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> @@ -5,8 +5,30 @@ Required properties:
>  
>  - reg: offset and length of the register set
>  
> -Example:
> +Bank configurations can be defined in optional subnodes. Each subnode
> +describes one bank and contains the following:
> +
> +Required properties:
> +- bank : bank number (0 - 3)

I wonder whether this should be maybe "reg"?

> +
> +- srom-timing : array of 7 integers: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs

Missing "pmc"? Where is the seventh?

This looks vendor specific, so prefix with "samsung,exynos-".

> +
> +Optional properties:
> +- width : data width in bytes (1 or 2). If omitted, default of 1 is used.

This is not bank-width? So data-width? Any vendor prefix here? How
generic is this?

These are first things which came to my mind. Maybe DT maintainers will
come with something more...

Best regards,
Krzysztof

> +
> +Example: basic definition, no banks are configured
> + sromc@1257 {
> + compatible = "samsung,exynos-srom";
> + reg = <0x1257 0x10>;
> + };
> +
> +Example: SROMc with bank3 configuration
>   sromc@1257 {
>   compatible = "samsung,exynos-srom";
>   reg = <0x1257 0x10>;
> + bank@3 {
> + bank = <3>;
> + width = <2>;
> + srom-timing = <1 9 12 1 9 1 1>;
> + };
>   };
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v8 10/10] arm: zx_defconfig: remove CONFIG_MMC_DW_IDMAC

[Jaehoon Chung]

Hi, All.

Is there any other opinion about this patch?


Best Regards,
Jaehoon Chung

On 09/16/2015 03:43 PM, Shawn Lin wrote:
> DesignWare MMC Controller's transfer mode should be decided
> at runtime instead of compile-time. So we remove this config
> option and read dw_mmc's register to select DMA master.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/configs/zx_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/zx_defconfig b/arch/arm/configs/zx_defconfig
> index b200bb0..ab683fb 100644
> --- a/arch/arm/configs/zx_defconfig
> +++ b/arch/arm/configs/zx_defconfig
> @@ -83,7 +83,6 @@ CONFIG_MMC=y
>  CONFIG_MMC_UNSAFE_RESUME=y
>  CONFIG_MMC_BLOCK_MINORS=16
>  CONFIG_MMC_DW=y
> -CONFIG_MMC_DW_IDMAC=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT4_FS=y
>  CONFIG_EXT4_FS_POSIX_ACL=y
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/4] drivers: exynos-srom: Add support for bank configuration

[Krzysztof Kozlowski]

On 28.10.2015 16:57, Pavel Fedin wrote:
> Bindings are based on u-boot implementation, however they are stored in
> subnodes, providing support for more than one bank.
> 
> Since the driver now does more than suspend-resume support, dependency on
> CONFIG_PM is removed.
> 
> Signed-off-by: Pavel Fedin 
> ---
>  arch/arm/mach-exynos/Kconfig  |  2 +-
>  drivers/soc/samsung/Kconfig   |  2 +-
>  drivers/soc/samsung/exynos-srom.c | 42 
> ++-
>  3 files changed, 43 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 83c85f5..c22dc42 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
>   select ARM_GIC
>   select COMMON_CLK_SAMSUNG
>   select EXYNOS_THERMAL
> - select EXYNOS_SROM if PM
> + select EXYNOS_SROM
>   select HAVE_ARM_SCU if SMP
>   select HAVE_S3C2410_I2C if I2C
>   select HAVE_S3C2410_WATCHDOG if WATCHDOG
> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
> index 2833b5b..ea4bc2a 100644
> --- a/drivers/soc/samsung/Kconfig
> +++ b/drivers/soc/samsung/Kconfig
> @@ -8,6 +8,6 @@ config SOC_SAMSUNG
>  
>  config EXYNOS_SROM
>   bool
> - depends on ARM && ARCH_EXYNOS && PM
> + depends on ARM && ARCH_EXYNOS
>  
>  endmenu
> diff --git a/drivers/soc/samsung/exynos-srom.c 
> b/drivers/soc/samsung/exynos-srom.c
> index 57a232d..6c8c56a 100644
> --- a/drivers/soc/samsung/exynos-srom.c
> +++ b/drivers/soc/samsung/exynos-srom.c
> @@ -67,9 +67,46 @@ static struct exynos_srom_reg_dump 
> *exynos_srom_alloc_reg_dump(
>   return rd;
>  }
>  
> +static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
> +{
> + u32 bank, width;
> + u32 timing[7];
> + u32 bw;
> +
> + if (of_property_read_u32(np, "bank", ))
> + return -ENXIO;

This is an invalid value in DTB, not missing device or address, so -EINVAL.

> + if (of_property_read_u32(np, "width", ))
> + width = 1;
> + if (of_property_read_u32_array(np, "srom-timing", timing, 7)) {

s/7/ARRAY_SIZE/

> + pr_err("Could not decode SROMC configuration\n");

dev_err()

> + return -ENXIO;

Here also I would prefer -EINVAL

> + }
> +
> + bank *= 4; /* Convert bank into shift/offset */
> +
> + bw = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
> + if (width == 2)
> + bw |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
> + bw <<= bank;
> + bw |= __raw_readl(srom->reg_base + EXYNOS_SROM_BW) &
> +   ~(EXYNOS_SROM_BW__CS_MASK << bank);

This is reversed pattern. First read, then set or clear bits and finally
write. It makes easier to understand what is the intention.

> + __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
> +
> + __raw_writel((timing[0] << EXYNOS_SROM_BCX__PMC__SHIFT) |
> + (timing[1] << EXYNOS_SROM_BCX__TACP__SHIFT) |
> + (timing[2] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
> + (timing[3] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
> + (timing[4] << EXYNOS_SROM_BCX__TACC__SHIFT) |
> + (timing[5] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
> + (timing[6] << EXYNOS_SROM_BCX__TACS__SHIFT),
> + srom->reg_base + EXYNOS_SROM_BC0 + bank);
> +
> + return 0;
> +}
> +
>  static int exynos_srom_probe(struct platform_device *pdev)
>  {
> - struct device_node *np;
> + struct device_node *np, *child;
>   struct exynos_srom *srom;
>   struct device *dev = >dev;
>  
> @@ -100,6 +137,9 @@ static int exynos_srom_probe(struct platform_device *pdev)
>   return -ENOMEM;
>   }
>  
> + for_each_child_of_node(np, child)
> + decode_sromc(srom, child);

You ignore the return value here so bank may be not configured but
device probe will return 0.

Maybe clean up and fail the probe?

Best regards,
Krzysztof

> +
>   return 0;
>  }
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v8 09/10] arm: multi_v7_defconfig: remove CONFIG_MMC_DW_IDMAC

[Jaehoon Chung]

Hi, All.

Is there any other opinion about this patch?

Best Regards,
Jaehoon Chung

On 09/16/2015 03:43 PM, Shawn Lin wrote:
> DesignWare MMC Controller's transfer mode should be decided
> at runtime instead of compile-time. So we remove this config
> option and read dw_mmc's register to select DMA master.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/configs/multi_v7_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 03deb7f..ad929ea 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -539,7 +539,6 @@ CONFIG_MMC_ATMELMCI=y
>  CONFIG_MMC_MVSDIO=y
>  CONFIG_MMC_SDHI=y
>  CONFIG_MMC_DW=y
> -CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_PLTFM=y
>  CONFIG_MMC_DW_EXYNOS=y
>  CONFIG_MMC_DW_ROCKCHIP=y
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/4] regulator: s2mps11: add support for S2MPS15 regulators

[Alim Akhtar]

From: Thomas Abraham 

The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators and allows programming these regulators via a
I2C interface. This patch adds initial support for LDO/Buck regulators of
S2MPS15 PMIC.

Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
Reviewed-by: Krzysztof Kozlowski 
---
 drivers/regulator/Kconfig   |4 +-
 drivers/regulator/s2mps11.c |  135 ++-
 2 files changed, 136 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 64bccff557be..3e3ee5b88b3f 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -588,10 +588,10 @@ config REGULATOR_S2MPA01
 via I2C bus. S2MPA01 has 10 Bucks and 26 LDO outputs.
 
 config REGULATOR_S2MPS11
-   tristate "Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage regulator"
+   tristate "Samsung S2MPS11/13/14/15/S2MPU02 voltage regulator"
depends on MFD_SEC_CORE
help
-This driver supports a Samsung S2MPS11/S2MPS13/S2MPS14/S2MPU02 voltage
+This driver supports a Samsung S2MPS11/13/14/15/S2MPU02 voltage
 output regulator via I2C bus. The chip is comprised of high efficient
 Buck converters including Dual-Phase Buck converter, Buck-Boost
 converter, various LDOs.
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 72fc3c32db49..b2f3a28e720c 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* The highest number of possible regulators for supported devices. */
@@ -661,6 +662,133 @@ static const struct regulator_desc s2mps14_regulators[] = 
{
S2MPS14_BUCK1235_START_SEL),
 };
 
+static struct regulator_ops s2mps15_reg_ldo_ops = {
+   .list_voltage   = regulator_list_voltage_linear_range,
+   .map_voltage= regulator_map_voltage_linear_range,
+   .is_enabled = regulator_is_enabled_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+};
+
+static struct regulator_ops s2mps15_reg_buck_ops = {
+   .list_voltage   = regulator_list_voltage_linear_range,
+   .map_voltage= regulator_map_voltage_linear_range,
+   .is_enabled = regulator_is_enabled_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .set_voltage_time_sel   = regulator_set_voltage_time_sel,
+};
+
+#define regulator_desc_s2mps15_ldo(num, range) {   \
+   .name   = "LDO"#num,\
+   .id = S2MPS15_LDO##num, \
+   .ops= _reg_ldo_ops, \
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \
+   .linear_ranges  = range,\
+   .n_linear_ranges = ARRAY_SIZE(range),   \
+   .n_voltages = S2MPS15_LDO_N_VOLTAGES,   \
+   .vsel_reg   = S2MPS15_REG_L1CTRL + num - 1, \
+   .vsel_mask  = S2MPS15_LDO_VSEL_MASK,\
+   .enable_reg = S2MPS15_REG_L1CTRL + num - 1, \
+   .enable_mask= S2MPS15_ENABLE_MASK   \
+}
+
+#define regulator_desc_s2mps15_buck(num, range) {  \
+   .name   = "BUCK"#num,   \
+   .id = S2MPS15_BUCK##num,\
+   .ops= _reg_buck_ops,\
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \
+   .linear_ranges  = range,\
+   .n_linear_ranges = ARRAY_SIZE(range),   \
+   .ramp_delay = 12500,\
+   .n_voltages = S2MPS15_BUCK_N_VOLTAGES,  \
+   .vsel_reg   = S2MPS15_REG_B1CTRL2 + ((num - 1) * 2),\
+   .vsel_mask  = S2MPS15_BUCK_VSEL_MASK,   \
+   .enable_reg = S2MPS15_REG_B1CTRL1 + ((num - 1) * 2),\
+   .enable_mask= S2MPS15_ENABLE_MASK   \
+}
+
+/* voltage range for s2mps15 LDO 3, 5, 15, 16, 18, 20, 23 and 27 */
+static const struct regulator_linear_range s2mps15_ldo_voltage_ranges1[] = {
+   

[PATCH v4 0/4] mfd: sec: add S2MPS15 PMIC support

[Alim Akhtar]

Samsung's S2MPS15 PMIC is targetted to be used with Samsung's Exynos7 SoC.
The S2MPS15 PMIC is similar in functionality to S2MPS11/14 PMIC. It contains
27 LDO and 10 Buck regulators, RTC, three 32.768 KHz clock outputs and allows
programming these blocks via a I2C interface. This patch series adds initial
support for LDO/Buck regulators of S2MPS15 PMIC.

Changes since v3:
* Changes regulator driver name from s2mps15-pmic -> s2mps15-regulator as 
disscussed here [2]
* Re-use the exsisting compatible/names for s2mps15 clock block.

Changes since v2:
* Addressed Lee Jones review comments.

Changes since v1:
* Added suggestion from Krzysztof [1].
* Added s2mps15's 32.768 clocks support.
* Added s2mps15's rtc support.

V1 of these patches (with a lesser features) were posted a year back,
since then there is not much progress on this, this is my attempt to
move things forward.

[1]-> https://lkml.org/lkml/2014/10/14/67
[2]-> https://lkml.org/lkml/2015/10/28/417

This series is based on linux-next-20151022.
This is tested on exynos7-espresso board.


Alim Akhtar (1):
  drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

Thomas Abraham (3):
  dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC
  mfd: sec: Add support for S2MPS15 PMIC
  regulator: s2mps11: add support for S2MPS15 regulators

 Documentation/devicetree/bindings/mfd/s2mps11.txt |   23 +--
 drivers/mfd/sec-core.c|   31 
 drivers/mfd/sec-irq.c |8 ++
 drivers/regulator/Kconfig |4 +-
 drivers/regulator/s2mps11.c   |  135 +-
 drivers/rtc/rtc-s5m.c |   20 ++-
 include/linux/mfd/samsung/core.h  |1 +
 include/linux/mfd/samsung/rtc.h   |4 +
 include/linux/mfd/samsung/s2mps15.h   |  158 +
 9 files changed, 371 insertions(+), 13 deletions(-)
 create mode 100644 include/linux/mfd/samsung/s2mps15.h

-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Alim Akhtar]

From: Thomas Abraham 

Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.

Cc: devicet...@vger.kernel.org
Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt |   23 ++---
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 890f0b0e1643..c0427c9d0886 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,5 +1,5 @@
 
-* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
+* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
 
 The Samsung S2MPS11 is a multi-function device which includes voltage and
 current regulators, RTC, charger controller and other sub-blocks. It is
@@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each 
sub-block is
 addressed by the host system using different I2C slave addresses.
 
 Required properties:
-- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
- or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
+- compatible: Should be one of the following
+   - "samsung,s2mps11-pmic"
+   - "samsung,s2mps13-pmic"
+   - "samsung,s2mps14-pmic"
+   - "samsung,s2mps15-pmic"
+   - "samsung,s2mpu02-pmic".
 - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
 
 Optional properties:
@@ -24,7 +28,7 @@ Optional properties:
   unwanted buck warm reset (setting buck voltages to default values).
 
 Optional nodes:
-- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768
+- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
buffered 32.768
   KHz outputs, so to register these as clocks with common clock framework
   instantiate a sub-node named "clocks". It uses the common clock binding
   documented in :
@@ -37,12 +41,13 @@ Optional nodes:
 the clock which they consume.
 Clock   ID   Devices
 --
-32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767
-32KhzCP1S2MPS11, S2MPS13, S5M8767
-32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767
+32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
+32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767
+32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
 
   - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk",
-   "samsung,s2mps14-clk", "samsung,s5m8767-clk"
+   "samsung,s2mps14-clk", "samsung,s2mps15-clk",
+   "samsung,s5m8767-clk"
 
 - regulators: The regulators of s2mps11 that have to be instantiated should be
 included in a sub-node named 'regulators'. Regulator nodes included in this
@@ -90,6 +95,7 @@ as per the datasheet of s2mps11.
- S2MPS11: 1 to 38
- S2MPS13: 1 to 40
- S2MPS14: 1 to 25
+   - S2MPS15: 1 to 27
- S2MPU02: 1 to 28
  - Example: LDO1, LDO2, LDO28
- BUCKn
@@ -97,6 +103,7 @@ as per the datasheet of s2mps11.
- S2MPS11: 1 to 10
- S2MPS13: 1 to 10
- S2MPS14: 1 to 5
+   - S2MPS15: 1 to 10
- S2MPU02: 1 to 7
  - Example: BUCK1, BUCK2, BUCK9
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/4] mfd: sec: Add support for S2MPS15 PMIC

[Alim Akhtar]

From: Thomas Abraham 

Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.

Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski 
---
 drivers/mfd/sec-core.c  |   31 +++
 drivers/mfd/sec-irq.c   |8 ++
 include/linux/mfd/samsung/core.h|1 +
 include/linux/mfd/samsung/s2mps15.h |  158 +++
 4 files changed, 198 insertions(+)
 create mode 100644 include/linux/mfd/samsung/s2mps15.h

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2626fc0b5b8c..fbb8a5715597 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
}
 };
 
+static const struct mfd_cell s2mps15_devs[] = {
+   {
+   .name = "s2mps15-regulator",
+   }, {
+   .name = "s2mps15-rtc",
+   }, {
+   .name = "s2mps13-clk",
+   .of_compatible = "samsung,s2mps13-clk",
+   },
+};
+
 static const struct mfd_cell s2mpa01_devs[] = {
{
.name = "s2mpa01-pmic",
@@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
.compatible = "samsung,s2mps14-pmic",
.data = (void *)S2MPS14X,
}, {
+   .compatible = "samsung,s2mps15-pmic",
+   .data = (void *)S2MPS15X,
+   }, {
.compatible = "samsung,s2mpa01-pmic",
.data = (void *)S2MPA01,
}, {
@@ -226,6 +241,15 @@ static const struct regmap_config s2mps14_regmap_config = {
.cache_type = REGCACHE_FLAT,
 };
 
+static const struct regmap_config s2mps15_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+
+   .max_register = S2MPS15_REG_LDODSCH4,
+   .volatile_reg = s2mps11_volatile,
+   .cache_type = REGCACHE_FLAT,
+};
+
 static const struct regmap_config s2mpu02_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
case S2MPS14X:
regmap = _regmap_config;
break;
+   case S2MPS15X:
+   regmap = _regmap_config;
+   break;
case S5M8763X:
regmap = _regmap_config;
break;
@@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
sec_devs = s2mps14_devs;
num_sec_devs = ARRAY_SIZE(s2mps14_devs);
break;
+   case S2MPS15X:
+   sec_devs = s2mps15_devs;
+   num_sec_devs = ARRAY_SIZE(s2mps15_devs);
+   break;
case S2MPU02:
sec_devs = s2mpu02_devs;
num_sec_devs = ARRAY_SIZE(s2mpu02_devs);
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 806fa8dbb22d..d77de431cc50 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -407,6 +407,11 @@ static const struct regmap_irq_chip s2mps14_irq_chip = {
S2MPS1X_IRQ_CHIP_COMMON_DATA,
 };
 
+static const struct regmap_irq_chip s2mps15_irq_chip = {
+   .name = "s2mps15",
+   S2MPS1X_IRQ_CHIP_COMMON_DATA,
+};
+
 static const struct regmap_irq_chip s2mpu02_irq_chip = {
.name = "s2mpu02",
.irqs = s2mpu02_irqs,
@@ -466,6 +471,9 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
case S2MPS14X:
sec_irq_chip = _irq_chip;
break;
+   case S2MPS15X:
+   sec_irq_chip = _irq_chip;
+   break;
case S2MPU02:
sec_irq_chip = _irq_chip;
break;
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index a06098639399..6bc4bcd488ac 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -44,6 +44,7 @@ enum sec_device_type {
S2MPS11X,
S2MPS13X,
S2MPS14X,
+   S2MPS15X,
S2MPU02,
 };
 
diff --git a/include/linux/mfd/samsung/s2mps15.h 
b/include/linux/mfd/samsung/s2mps15.h
new file mode 100644
index ..36d35287c3c0
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mps15.h
@@ -0,0 +1,158 @@
+/*
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ *  http://www.samsung.com
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later 

Re: [PATCH] ARM: exynos: Bring back reboot on Exynos5410

[Krzysztof Kozlowski]

On 28.10.2015 18:36, Pavel Fedin wrote:
> Since 8cfc7fdd33080e30b86d21b1a8c9ad0686427ddc ("ARM: EXYNOS: move restart

This should be sufficient (although full is okay as well):
$ git config core.abbrev 12

> code into pmu driver") PMU support is required in order for the reboot to
> work. Unfortunately, there is currently no PMU support for 5410.
> 
> This patch adds exynos5410-pmu to the list of recognized devices. It is
> okay for the code to have empty struct exynos_pmu_data, in this case only
> minimal support is enabled. This is enough for SWRESET to work.
> 
> Signed-off-by: Pavel Fedin 

This definitely looks like a fix for a regression, so:
Cc: 
Fixes: 8cfc7fdd3308 ("ARM: EXYNOS: move restart code into pmu driver")

> ---
>  arch/arm/mach-exynos/pmu.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
> index de68938..7b9e33c 100644
> --- a/arch/arm/mach-exynos/pmu.c
> +++ b/arch/arm/mach-exynos/pmu.c
> @@ -908,6 +908,10 @@ static const struct exynos_pmu_data exynos5250_pmu_data 
> = {
>   .powerdown_conf = exynos5_powerdown_conf,
>  };
>  
> +static struct exynos_pmu_data exynos5410_pmu_data = {
> + /* Only SWRESET is currently supported on 5410 */
> +};

static const struct

With these changes:
Reviewed-by: Krzysztof Kozlowski 


Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Yakir Yang 
---
Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)

Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)

Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

Changes in v2: None

 drivers/phy/Kconfig   |   7 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-rockchip-dp.c | 151 ++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..f3e0058
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+   int ret;
+
+   if (enable) {
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_ON);
+   if (ret < 0) {
+   dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dp->phy_24m);
+   } else {
+   clk_disable_unprepare(dp->phy_24m);
+
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_OFF);
+   }
+
+   return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, false);
+}
+

Re: [PATCH] ARM: exynos: Bring back reboot on Exynos5410

[Krzysztof Kozlowski]

On 29.10.2015 11:06, Pankaj Dubey wrote:
> Hi Pavel,
> 
> On 29 October 2015 at 07:11, Krzysztof Kozlowski
>  wrote:
>> On 28.10.2015 18:36, Pavel Fedin wrote:
>>> Since 8cfc7fdd33080e30b86d21b1a8c9ad0686427ddc ("ARM: EXYNOS: move restart
>>
>> This should be sufficient (although full is okay as well):
>> $ git config core.abbrev 12
>>
>>> code into pmu driver") PMU support is required in order for the reboot to
>>> work. Unfortunately, there is currently no PMU support for 5410.
>>>
>>> This patch adds exynos5410-pmu to the list of recognized devices. It is
>>> okay for the code to have empty struct exynos_pmu_data, in this case only
>>> minimal support is enabled. This is enough for SWRESET to work.
>>>
>>> Signed-off-by: Pavel Fedin 
>>
>> This definitely looks like a fix for a regression, so:
>> Cc: 
>> Fixes: 8cfc7fdd3308 ("ARM: EXYNOS: move restart code into pmu driver")
>>
>>> ---
>>>  arch/arm/mach-exynos/pmu.c | 7 +++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
>>> index de68938..7b9e33c 100644
>>> --- a/arch/arm/mach-exynos/pmu.c
>>> +++ b/arch/arm/mach-exynos/pmu.c
>>> @@ -908,6 +908,10 @@ static const struct exynos_pmu_data 
>>> exynos5250_pmu_data = {
>>>   .powerdown_conf = exynos5_powerdown_conf,
>>>  };
>>>
>>> +static struct exynos_pmu_data exynos5410_pmu_data = {
>>> + /* Only SWRESET is currently supported on 5410 */
>>> +};
>>
>> static const struct
>>
>> With these changes:
>> Reviewed-by: Krzysztof Kozlowski 
>>
>>
> 
> Patch looks ok, but after Alim's patch series [1] to handle poweroff
> and reboot via generic syscon based driver gets merged, this will
> become redundant entry into PMU driver in the absence of any PMU  data
> for Exynos5410. Alim has taken care of adding power-off and reboot
> device node in exynos5410.dtsi [2].
> 
> [1]: http://www.spinics.net/lists/devicetree/msg98858.html
> [2]: http://www.spinics.net/lists/devicetree/msg98862.html
> 

Yes, current patch makes sense only if it gets into fixes for current RC
and then backported to stable kernels. Alim's patchset won't be backported.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC

[Alim Akhtar]

On 10/28/2015 07:21 PM, Lee Jones wrote:

On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:


W dniu 28.10.2015 o 17:46, Lee Jones pisze:

On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:


On 26.10.2015 23:34, Lee Jones wrote:

On Mon, 26 Oct 2015, Alim Akhtar wrote:


From: Thomas Abraham 

Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
clock outputs and battery charger. This patch adds initial support for
LDO and buck regulators of S2MPS15 device.

Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
[Alim: Added s2mps15_devs like rtc and clk and related changes]
Reviewed-by: Krzysztof Kozlowski 
---
  drivers/mfd/sec-core.c  |   31 +++
  drivers/mfd/sec-irq.c   |8 ++
  include/linux/mfd/samsung/core.h|1 +
  include/linux/mfd/samsung/s2mps15.h |  158 +++
  4 files changed, 198 insertions(+)
  create mode 100644 include/linux/mfd/samsung/s2mps15.h


I replied to the previous set and won't be reviewing this one until
all of the open points are solved.


The naming and compatibles used by the driver are confusing but how it
was at beginning. Beside the confusion, the names are correct:

1. Main mfd driver:
  - compatible: samsung,s2mps1*-pmic
  - driver name: sec_pmic

2. Regulator driver:
  - no compatible (because it always searches for "regulators" subnode of
its parent... that is the convention/legacy behaviour)
  - driver name: s2mps1*-pmic

I hope that explains your concerns.


It explains *why*, but doesn't ease my concerns in any way.

Unfortunately I've only just realised the disparity we have between
MFD and the Regulator subsystem, which is annoying because it's now
almost impossible to rectify.

We should have taken one of two views.  Either a) The MFD is the PMIC
device which encompasses regulator control.  In which case the MFD
and it's corresponding compatible string would be named *-pmic and the
regulator driver would be called *-regulator. Or b) The MFD could be
considered a normal MFD and be named after the model number, then the
regulator 'could' be named *-pmic.

However, with reference to b), how much other Power Management does
the regulator driver do besides control regulators?  I suspect not
much.  Therefore my preference would be for a).  My second choice
would be a mixuture of the two where nothing gets named *-pmic.  The
last option on my list would be the current situation where we seem to
be calling both the MFD (PMIC) itself and the Regulator driver
*-pmic, which is not good.


Starting from the description of device-family. This is called "Power
Management IC" but it is rather a "Power Deliver/Distribute IC". There
isn't any logic inside except enable/disable/configure/set low power
mode for regulators.

However in the same time the IC comes (always) with:
  - 32kHz clocks,
  - RTC,
  - backup battery charger (no driver for it),
  - reset for SoC,
  - shutdown on thermal alert (also no driver for this control).

The solution a) seems fine to me. Make sense and it looks entirely
backward compatible - only driver names will be modified.


Perfect solution from my PoV.

Thanks Krzysztof.


Thanks Jones/Krzysztof as always.
Will update the patches.


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 4/4] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Krzysztof Kozlowski]

On 29.10.2015 13:58, Alim Akhtar wrote:
> RTC found in s2mps15 is almost same as one found on s2mps14/13
> with few differences in RTC_UPDATE register fields, like
> bit fields are changed for WUDR and AUDR.
> This patch add required changes to enable s2mps15 rtc timer.
> 
> Cc: Alexandre Belloni 
> Signed-off-by: Alim Akhtar 
> ---
>  drivers/rtc/rtc-s5m.c   |   20 ++--
>  include/linux/mfd/samsung/rtc.h |4 
>  2 files changed, 22 insertions(+), 2 deletions(-)


Oh, this is totally different than previous patch and changelog does not
mention these changes.

Was the previous RTC patch tested?
Here the AUDR and WUDR seem to be reversed... oh, that is strange. :)

Best regards,
Krzysztof

> 
> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
> index f2504b4eef34..0d106a99958f 100644
> --- a/drivers/rtc/rtc-s5m.c
> +++ b/drivers/rtc/rtc-s5m.c
> @@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct 
> s5m_rtc_info *info,
>   ret = regmap_read(info->regmap, S5M_RTC_STATUS, );
>   val &= S5M_ALARM0_STATUS;
>   break;
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
> @@ -223,6 +224,9 @@ static inline int s5m8767_rtc_set_time_reg(struct 
> s5m_rtc_info *info)
>   if (info->device_type == S5M8763X || info->device_type == S5M8767X)
>   data |= S5M_RTC_TIME_EN_MASK;
>  
> + if (info->device_type == S2MPS15X)
> + data |= S2MPS15_RTC_WUDR_MASK;
> +
>   ret = regmap_write(info->regmap, info->regs->rtc_udr_update, data);
>   if (ret < 0) {
>   dev_err(info->dev, "failed to write update reg(%d)\n", ret);
> @@ -252,6 +256,9 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
> s5m_rtc_info *info)
>   case S5M8767X:
>   data &= ~S5M_RTC_TIME_EN_MASK;
>   break;
> + case S2MPS15X:
> + data |= S2MPS15_RTC_AUDR_MASK;
> + break;
>   case S2MPS14X:
>   data |= S2MPS_RTC_RUDR_MASK;
>   break;
> @@ -275,7 +282,6 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
> s5m_rtc_info *info)
>   if (info->device_type == S2MPS13X)
>   regmap_update_bits(info->regmap, info->regs->rtc_udr_update,
>  S2MPS13_RTC_AUDR_MASK, 0);
> -
>   return ret;
>  }
>  
> @@ -317,7 +323,8 @@ static int s5m_rtc_read_time(struct device *dev, struct 
> rtc_time *tm)
>   u8 data[info->regs->regs_count];
>   int ret;
>  
> - if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
> + if (info->device_type == S2MPS15X || info->device_type == S2MPS14X ||
> + info->device_type == S2MPS13X) {
>   ret = regmap_update_bits(info->regmap,
>   info->regs->rtc_udr_update,
>   S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
> @@ -339,6 +346,7 @@ static int s5m_rtc_read_time(struct device *dev, struct 
> rtc_time *tm)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
> @@ -366,6 +374,7 @@ static int s5m_rtc_set_time(struct device *dev, struct 
> rtc_time *tm)
>   s5m8763_tm_to_data(tm, data);
>   break;
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   ret = s5m8767_tm_to_data(tm, data);
> @@ -414,6 +423,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct 
> rtc_wkalrm *alrm)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   s5m8767_data_to_tm(data, >time, info->rtc_24hr_mode);
> @@ -463,6 +473,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   for (i = 0; i < info->regs->regs_count; i++)
> @@ -508,6 +519,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   data[RTC_SEC] |= ALARM_ENABLE_MASK;
> @@ -548,6 +560,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct 
> rtc_wkalrm *alrm)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   s5m8767_tm_to_data(>time, data);
> @@ -631,6 +644,7 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
>   ret = regmap_raw_write(info->regmap, S5M_ALARM0_CONF, data, 2);
>   break;
>  
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>

[PATCH] ARM: EXYNOS: Constify local exynos_pmu_data structure

[Krzysztof Kozlowski]

The Exynos5420 instance of exynos_pmu_data structure is not modified and
can be made const.

Signed-off-by: Krzysztof Kozlowski 
Suggested-by: Pavel Fedin 
---
 arch/arm/mach-exynos/pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index de68938ee6aa..5775154501d8 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -908,7 +908,7 @@ static const struct exynos_pmu_data exynos5250_pmu_data = {
.powerdown_conf = exynos5_powerdown_conf,
 };
 
-static struct exynos_pmu_data exynos5420_pmu_data = {
+static const struct exynos_pmu_data exynos5420_pmu_data = {
.pmu_config = exynos5420_pmu_config,
.pmu_init   = exynos5420_pmu_init,
.powerdown_conf = exynos5420_powerdown_conf,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: exynos: Bring back reboot on Exynos5410

[Pankaj Dubey]

Hi Pavel,

On 29 October 2015 at 07:11, Krzysztof Kozlowski
 wrote:
> On 28.10.2015 18:36, Pavel Fedin wrote:
>> Since 8cfc7fdd33080e30b86d21b1a8c9ad0686427ddc ("ARM: EXYNOS: move restart
>
> This should be sufficient (although full is okay as well):
> $ git config core.abbrev 12
>
>> code into pmu driver") PMU support is required in order for the reboot to
>> work. Unfortunately, there is currently no PMU support for 5410.
>>
>> This patch adds exynos5410-pmu to the list of recognized devices. It is
>> okay for the code to have empty struct exynos_pmu_data, in this case only
>> minimal support is enabled. This is enough for SWRESET to work.
>>
>> Signed-off-by: Pavel Fedin 
>
> This definitely looks like a fix for a regression, so:
> Cc: 
> Fixes: 8cfc7fdd3308 ("ARM: EXYNOS: move restart code into pmu driver")
>
>> ---
>>  arch/arm/mach-exynos/pmu.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
>> index de68938..7b9e33c 100644
>> --- a/arch/arm/mach-exynos/pmu.c
>> +++ b/arch/arm/mach-exynos/pmu.c
>> @@ -908,6 +908,10 @@ static const struct exynos_pmu_data exynos5250_pmu_data 
>> = {
>>   .powerdown_conf = exynos5_powerdown_conf,
>>  };
>>
>> +static struct exynos_pmu_data exynos5410_pmu_data = {
>> + /* Only SWRESET is currently supported on 5410 */
>> +};
>
> static const struct
>
> With these changes:
> Reviewed-by: Krzysztof Kozlowski 
>
>

Patch looks ok, but after Alim's patch series [1] to handle poweroff
and reboot via generic syscon based driver gets merged, this will
become redundant entry into PMU driver in the absence of any PMU  data
for Exynos5410. Alim has taken care of adding power-off and reboot
device node in exynos5410.dtsi [2].

[1]: http://www.spinics.net/lists/devicetree/msg98858.html
[2]: http://www.spinics.net/lists/devicetree/msg98862.html

Thanks,
Pankaj Dubey

> Best regards,
> Krzysztof
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: EXYNOS: Constify local exynos_pmu_data structure

[Pankaj Dubey]

On 29 October 2015 at 07:10, Krzysztof Kozlowski
 wrote:
> The Exynos5420 instance of exynos_pmu_data structure is not modified and
> can be made const.
>
> Signed-off-by: Krzysztof Kozlowski 
> Suggested-by: Pavel Fedin 

Reviewed-by: Pankaj Dubey 

Thanks,
Pankaj Dubey

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/4] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Alim Akhtar]

RTC found in s2mps15 is almost same as one found on s2mps14/13
with few differences in RTC_UPDATE register fields, like
bit fields are changed for WUDR and AUDR.
This patch add required changes to enable s2mps15 rtc timer.

Cc: Alexandre Belloni 
Signed-off-by: Alim Akhtar 
---
 drivers/rtc/rtc-s5m.c   |   20 ++--
 include/linux/mfd/samsung/rtc.h |4 
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index f2504b4eef34..0d106a99958f 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct 
s5m_rtc_info *info,
ret = regmap_read(info->regmap, S5M_RTC_STATUS, );
val &= S5M_ALARM0_STATUS;
break;
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
@@ -223,6 +224,9 @@ static inline int s5m8767_rtc_set_time_reg(struct 
s5m_rtc_info *info)
if (info->device_type == S5M8763X || info->device_type == S5M8767X)
data |= S5M_RTC_TIME_EN_MASK;
 
+   if (info->device_type == S2MPS15X)
+   data |= S2MPS15_RTC_WUDR_MASK;
+
ret = regmap_write(info->regmap, info->regs->rtc_udr_update, data);
if (ret < 0) {
dev_err(info->dev, "failed to write update reg(%d)\n", ret);
@@ -252,6 +256,9 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
case S5M8767X:
data &= ~S5M_RTC_TIME_EN_MASK;
break;
+   case S2MPS15X:
+   data |= S2MPS15_RTC_AUDR_MASK;
+   break;
case S2MPS14X:
data |= S2MPS_RTC_RUDR_MASK;
break;
@@ -275,7 +282,6 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
if (info->device_type == S2MPS13X)
regmap_update_bits(info->regmap, info->regs->rtc_udr_update,
   S2MPS13_RTC_AUDR_MASK, 0);
-
return ret;
 }
 
@@ -317,7 +323,8 @@ static int s5m_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
u8 data[info->regs->regs_count];
int ret;
 
-   if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
+   if (info->device_type == S2MPS15X || info->device_type == S2MPS14X ||
+   info->device_type == S2MPS13X) {
ret = regmap_update_bits(info->regmap,
info->regs->rtc_udr_update,
S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
@@ -339,6 +346,7 @@ static int s5m_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
break;
 
case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
@@ -366,6 +374,7 @@ static int s5m_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
s5m8763_tm_to_data(tm, data);
break;
case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = s5m8767_tm_to_data(tm, data);
@@ -414,6 +423,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct 
rtc_wkalrm *alrm)
break;
 
case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, >time, info->rtc_24hr_mode);
@@ -463,6 +473,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
break;
 
case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
for (i = 0; i < info->regs->regs_count; i++)
@@ -508,6 +519,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
break;
 
case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[RTC_SEC] |= ALARM_ENABLE_MASK;
@@ -548,6 +560,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct 
rtc_wkalrm *alrm)
break;
 
case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_tm_to_data(>time, data);
@@ -631,6 +644,7 @@ static int s5m8767_rtc_init_reg(struct s5m_rtc_info *info)
ret = regmap_raw_write(info->regmap, S5M_ALARM0_CONF, data, 2);
break;
 
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[0] = (0 << BCD_EN_SHIFT) | (1 << MODEL24_SHIFT);
@@ -679,6 +693,7 @@ static int s5m_rtc_probe(struct platform_device *pdev)
return -ENOMEM;
 
switch (platform_get_device_id(pdev)->driver_data) {
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
regmap_cfg = _rtc_regmap_config;
@@ -805,6 +820,7 @@ 

Re: [PATCH v4 4/4] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Alim Akhtar]

On 10/29/2015 10:37 AM, Krzysztof Kozlowski wrote:

On 29.10.2015 13:58, Alim Akhtar wrote:

RTC found in s2mps15 is almost same as one found on s2mps14/13
with few differences in RTC_UPDATE register fields, like
bit fields are changed for WUDR and AUDR.
This patch add required changes to enable s2mps15 rtc timer.

Cc: Alexandre Belloni 
Signed-off-by: Alim Akhtar 
---
  drivers/rtc/rtc-s5m.c   |   20 ++--
  include/linux/mfd/samsung/rtc.h |4 
  2 files changed, 22 insertions(+), 2 deletions(-)



Oh, this is totally different than previous patch and changelog does not
mention these changes.

I am still learning to make thing more correct in first attempt, these 
input will help :-), thanks.



Was the previous RTC patch tested?

Yes, it was tested, but the coverage was limited to wakealarm.

Now I have tested wakealarm and setting hw clock date/time using hwclock 
utility, setting system time/date to rtc and visa-versa, both works as 
expected.



Here the AUDR and WUDR seem to be reversed... oh, that is strange. :)

Yah, indeed this was a surprised for me also, but this how it is 
implemented in s2mps15.



Best regards,
Krzysztof



diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index f2504b4eef34..0d106a99958f 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct 
s5m_rtc_info *info,
ret = regmap_read(info->regmap, S5M_RTC_STATUS, );
val &= S5M_ALARM0_STATUS;
break;
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
@@ -223,6 +224,9 @@ static inline int s5m8767_rtc_set_time_reg(struct 
s5m_rtc_info *info)
if (info->device_type == S5M8763X || info->device_type == S5M8767X)
data |= S5M_RTC_TIME_EN_MASK;

+   if (info->device_type == S2MPS15X)
+   data |= S2MPS15_RTC_WUDR_MASK;
+
ret = regmap_write(info->regmap, info->regs->rtc_udr_update, data);
if (ret < 0) {
dev_err(info->dev, "failed to write update reg(%d)\n", ret);
@@ -252,6 +256,9 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
case S5M8767X:
data &= ~S5M_RTC_TIME_EN_MASK;
break;
+   case S2MPS15X:
+   data |= S2MPS15_RTC_AUDR_MASK;
+   break;
case S2MPS14X:
data |= S2MPS_RTC_RUDR_MASK;
break;
@@ -275,7 +282,6 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
s5m_rtc_info *info)
if (info->device_type == S2MPS13X)
regmap_update_bits(info->regmap, info->regs->rtc_udr_update,
   S2MPS13_RTC_AUDR_MASK, 0);
-
return ret;
  }

@@ -317,7 +323,8 @@ static int s5m_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
u8 data[info->regs->regs_count];
int ret;

-   if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
+   if (info->device_type == S2MPS15X || info->device_type == S2MPS14X ||
+   info->device_type == S2MPS13X) {
ret = regmap_update_bits(info->regmap,
info->regs->rtc_udr_update,
S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
@@ -339,6 +346,7 @@ static int s5m_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
break;

case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
@@ -366,6 +374,7 @@ static int s5m_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
s5m8763_tm_to_data(tm, data);
break;
case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
ret = s5m8767_tm_to_data(tm, data);
@@ -414,6 +423,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct 
rtc_wkalrm *alrm)
break;

case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
s5m8767_data_to_tm(data, >time, info->rtc_24hr_mode);
@@ -463,6 +473,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
break;

case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
for (i = 0; i < info->regs->regs_count; i++)
@@ -508,6 +519,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
break;

case S5M8767X:
+   case S2MPS15X:
case S2MPS14X:
case S2MPS13X:
data[RTC_SEC] |= ALARM_ENABLE_MASK;
@@ -548,6 +560,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct 
rtc_wkalrm *alrm)
break;

case S5M8767X:
+  

Re: [PATCH v4 4/4] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Krzysztof Kozlowski]

On 29.10.2015 13:58, Alim Akhtar wrote:
> RTC found in s2mps15 is almost same as one found on s2mps14/13
> with few differences in RTC_UPDATE register fields, like
> bit fields are changed for WUDR and AUDR.
> This patch add required changes to enable s2mps15 rtc timer.
> 
> Cc: Alexandre Belloni 
> Signed-off-by: Alim Akhtar 
> ---
>  drivers/rtc/rtc-s5m.c   |   20 ++--
>  include/linux/mfd/samsung/rtc.h |4 
>  2 files changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
> index f2504b4eef34..0d106a99958f 100644
> --- a/drivers/rtc/rtc-s5m.c
> +++ b/drivers/rtc/rtc-s5m.c
> @@ -188,6 +188,7 @@ static inline int s5m_check_peding_alarm_interrupt(struct 
> s5m_rtc_info *info,
>   ret = regmap_read(info->regmap, S5M_RTC_STATUS, );
>   val &= S5M_ALARM0_STATUS;
>   break;
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   ret = regmap_read(info->s5m87xx->regmap_pmic, S2MPS14_REG_ST2,
> @@ -223,6 +224,9 @@ static inline int s5m8767_rtc_set_time_reg(struct 
> s5m_rtc_info *info)
>   if (info->device_type == S5M8763X || info->device_type == S5M8767X)
>   data |= S5M_RTC_TIME_EN_MASK;
>  
> + if (info->device_type == S2MPS15X)
> + data |= S2MPS15_RTC_WUDR_MASK;
> +


You are setting here bit 1 and bit 4. However vendor code sets only bit
4 (called WUDR there). That's confusing. Why the difference? Or maybe I
am looking at wrong vendor tree (SM-G920F)?

>   ret = regmap_write(info->regmap, info->regs->rtc_udr_update, data);
>   if (ret < 0) {
>   dev_err(info->dev, "failed to write update reg(%d)\n", ret);
> @@ -252,6 +256,9 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
> s5m_rtc_info *info)
>   case S5M8767X:
>   data &= ~S5M_RTC_TIME_EN_MASK;
>   break;
> + case S2MPS15X:
> + data |= S2MPS15_RTC_AUDR_MASK;
> + break;
>   case S2MPS14X:
>   data |= S2MPS_RTC_RUDR_MASK;
>   break;

Another difference: you are setting here exactly the same values as
S2MPS13 - bit 1 and bit 4. However vendor code sets only bit 4 (called
WUDR there)?

What exactly is necessary to update alarm and time registers on S2MPS15?

> @@ -275,7 +282,6 @@ static inline int s5m8767_rtc_set_alarm_reg(struct 
> s5m_rtc_info *info)
>   if (info->device_type == S2MPS13X)
>   regmap_update_bits(info->regmap, info->regs->rtc_udr_update,
>  S2MPS13_RTC_AUDR_MASK, 0);
> -

This is not related to the patch.

Best regards,
Krzysztof


>   return ret;
>  }
>  
> @@ -317,7 +323,8 @@ static int s5m_rtc_read_time(struct device *dev, struct 
> rtc_time *tm)
>   u8 data[info->regs->regs_count];
>   int ret;
>  
> - if (info->device_type == S2MPS14X || info->device_type == S2MPS13X) {
> + if (info->device_type == S2MPS15X || info->device_type == S2MPS14X ||
> + info->device_type == S2MPS13X) {
>   ret = regmap_update_bits(info->regmap,
>   info->regs->rtc_udr_update,
>   S2MPS_RTC_RUDR_MASK, S2MPS_RTC_RUDR_MASK);
> @@ -339,6 +346,7 @@ static int s5m_rtc_read_time(struct device *dev, struct 
> rtc_time *tm)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   s5m8767_data_to_tm(data, tm, info->rtc_24hr_mode);
> @@ -366,6 +374,7 @@ static int s5m_rtc_set_time(struct device *dev, struct 
> rtc_time *tm)
>   s5m8763_tm_to_data(tm, data);
>   break;
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   ret = s5m8767_tm_to_data(tm, data);
> @@ -414,6 +423,7 @@ static int s5m_rtc_read_alarm(struct device *dev, struct 
> rtc_wkalrm *alrm)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   s5m8767_data_to_tm(data, >time, info->rtc_24hr_mode);
> @@ -463,6 +473,7 @@ static int s5m_rtc_stop_alarm(struct s5m_rtc_info *info)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   for (i = 0; i < info->regs->regs_count; i++)
> @@ -508,6 +519,7 @@ static int s5m_rtc_start_alarm(struct s5m_rtc_info *info)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   data[RTC_SEC] |= ALARM_ENABLE_MASK;
> @@ -548,6 +560,7 @@ static int s5m_rtc_set_alarm(struct device *dev, struct 
> rtc_wkalrm *alrm)
>   break;
>  
>   case S5M8767X:
> + case S2MPS15X:
>   case S2MPS14X:
>   case S2MPS13X:
>   s5m8767_tm_to_data(>time, data);
> @@ -631,6 +644,7 

Re: [PATCH v4 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Krzysztof Kozlowski]

On 29.10.2015 13:58, Alim Akhtar wrote:
> From: Thomas Abraham 
> 
> Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
> is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Thomas Abraham 
> Signed-off-by: Alim Akhtar 
> Reviewed-by: Krzysztof Kozlowski 
> Acked-by: Lee Jones 
> ---
>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   23 
> ++---
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> index 890f0b0e1643..c0427c9d0886 100644
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> @@ -1,5 +1,5 @@
>  
> -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
> +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
>  
>  The Samsung S2MPS11 is a multi-function device which includes voltage and
>  current regulators, RTC, charger controller and other sub-blocks. It is
> @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. 
> Each sub-block is
>  addressed by the host system using different I2C slave addresses.
>  
>  Required properties:
> -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
> -   or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
> +- compatible: Should be one of the following
> + - "samsung,s2mps11-pmic"
> + - "samsung,s2mps13-pmic"
> + - "samsung,s2mps14-pmic"
> + - "samsung,s2mps15-pmic"
> + - "samsung,s2mpu02-pmic".
>  - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>  
>  Optional properties:
> @@ -24,7 +28,7 @@ Optional properties:
>unwanted buck warm reset (setting buck voltages to default values).
>  
>  Optional nodes:
> -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 
> 32.768
> +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
> buffered 32.768
>KHz outputs, so to register these as clocks with common clock framework
>instantiate a sub-node named "clocks". It uses the common clock binding
>documented in :
> @@ -37,12 +41,13 @@ Optional nodes:
>  the clock which they consume.
>  Clock   ID   Devices
>  --
> -32KhzAP  0S2MPS11, S2MPS13, S2MPS14, S5M8767
> -32KhzCP  1S2MPS11, S2MPS13, S5M8767
> -32KhzBT  2S2MPS11, S2MPS13, S2MPS14, S5M8767
> +32KhzAP  0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
> +32KhzCP  1S2MPS11, S2MPS13, S2MPS15, S5M8767
> +32KhzBT  2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
>  
>- compatible: Should be one of: "samsung,s2mps11-clk", 
> "samsung,s2mps13-clk",
> - "samsung,s2mps14-clk", "samsung,s5m8767-clk"
> + "samsung,s2mps14-clk", "samsung,s2mps15-clk",
> + "samsung,s5m8767-clk"

N. Why "samsung,s2mps15-clk"?

Adding a new compatible to bindings is a major change so my review tag
(from v1 where there was no such compatible) should be dropped. Please
drop it.

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 10/17] phy: Add driver for rockchip Display Port PHY

[Heiko Stuebner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:30:33 schrieb Yakir Yang:
> +static int rockchip_dp_phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct device_node *np = dev->of_node;
> + struct phy_provider *phy_provider;
> + struct rockchip_dp_phy *dp;
> + struct resource *res;

drivers/phy/phy-rockchip-dp.c: In function 'rockchip_dp_phy_probe':
drivers/phy/phy-rockchip-dp.c:86:19: warning: unused variable 'res' 
[-Wunused-variable]

> + struct phy *phy;
> + int ret;
> +
> + if (!np)
> + return -ENODEV;
> +
> + dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
> + if (IS_ERR(dp))
> + return -ENOMEM;
> +
> + dp->dev = dev;
> +
> + dp->phy_24m = devm_clk_get(dev, "24m");
> + if (IS_ERR(dp->phy_24m)) {
> + dev_err(dev, "cannot get clock 24m\n");
> + return PTR_ERR(dp->phy_24m);
> + }
> +
> + ret = clk_set_rate(dp->phy_24m, 2400);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
> + return ret;
> + }
> +

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/5] mfd: sec: Add support for S2MPS15 PMIC

[Lee Jones]

On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:

> On 26.10.2015 23:34, Lee Jones wrote:
> > On Mon, 26 Oct 2015, Alim Akhtar wrote:
> > 
> >> From: Thomas Abraham 
> >>
> >> Add support for S2MPS15 PMIC which is similar to S2MPS11 PMIC. The S2MPS15
> >> PMIC supports 27 LDO regulators, 10 buck regulators, RTC, three 32.768KHz
> >> clock outputs and battery charger. This patch adds initial support for
> >> LDO and buck regulators of S2MPS15 device.
> >>
> >> Signed-off-by: Thomas Abraham 
> >> Signed-off-by: Alim Akhtar 
> >> [Alim: Added s2mps15_devs like rtc and clk and related changes]
> >> Reviewed-by: Krzysztof Kozlowski 
> >> ---
> >>  drivers/mfd/sec-core.c  |   31 +++
> >>  drivers/mfd/sec-irq.c   |8 ++
> >>  include/linux/mfd/samsung/core.h|1 +
> >>  include/linux/mfd/samsung/s2mps15.h |  158 
> >> +++
> >>  4 files changed, 198 insertions(+)
> >>  create mode 100644 include/linux/mfd/samsung/s2mps15.h
> > 
> > I replied to the previous set and won't be reviewing this one until
> > all of the open points are solved.
> 
> The naming and compatibles used by the driver are confusing but how it
> was at beginning. Beside the confusion, the names are correct:
> 
> 1. Main mfd driver:
>  - compatible: samsung,s2mps1*-pmic
>  - driver name: sec_pmic
> 
> 2. Regulator driver:
>  - no compatible (because it always searches for "regulators" subnode of
> its parent... that is the convention/legacy behaviour)
>  - driver name: s2mps1*-pmic
> 
> I hope that explains your concerns.

It explains *why*, but doesn't ease my concerns in any way.

Unfortunately I've only just realised the disparity we have between
MFD and the Regulator subsystem, which is annoying because it's now
almost impossible to rectify.  

We should have taken one of two views.  Either a) The MFD is the PMIC
device which encompasses regulator control.  In which case the MFD
and it's corresponding compatible string would be named *-pmic and the
regulator driver would be called *-regulator. Or b) The MFD could be
considered a normal MFD and be named after the model number, then the
regulator 'could' be named *-pmic.

However, with reference to b), how much other Power Management does
the regulator driver do besides control regulators?  I suspect not
much.  Therefore my preference would be for a).  My second choice
would be a mixuture of the two where nothing gets named *-pmic.  The
last option on my list would be the current situation where we seem to
be calling both the MFD (PMIC) itself and the Regulator driver
*-pmic, which is not good.

> >> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> >> index 2626fc0b5b8c..db3d4d4ff805 100644
> >> --- a/drivers/mfd/sec-core.c
> >> +++ b/drivers/mfd/sec-core.c
> >> @@ -29,6 +29,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -96,6 +97,17 @@ static const struct mfd_cell s2mps14_devs[] = {
> >>}
> >>  };
> >>  
> >> +static const struct mfd_cell s2mps15_devs[] = {
> >> +  {
> >> +  .name = "s2mps15-pmic",
> >> +  }, {
> >> +  .name = "s2mps15-rtc",
> >> +  }, {
> >> +  .name = "s2mps15-clk",
> >> +  .of_compatible = "samsung,s2mps15-clk",
> >> +  },
> >> +};
> >> +
> >>  static const struct mfd_cell s2mpa01_devs[] = {
> >>{
> >>.name = "s2mpa01-pmic",
> >> @@ -125,6 +137,9 @@ static const struct of_device_id sec_dt_match[] = {
> >>.compatible = "samsung,s2mps14-pmic",
> >>.data = (void *)S2MPS14X,
> >>}, {
> >> +  .compatible = "samsung,s2mps15-pmic",
> >> +  .data = (void *)S2MPS15X,
> >> +  }, {
> >>.compatible = "samsung,s2mpa01-pmic",
> >>.data = (void *)S2MPA01,
> >>}, {
> >> @@ -226,6 +241,15 @@ static const struct regmap_config 
> >> s2mps14_regmap_config = {
> >>.cache_type = REGCACHE_FLAT,
> >>  };
> >>  
> >> +static const struct regmap_config s2mps15_regmap_config = {
> >> +  .reg_bits = 8,
> >> +  .val_bits = 8,
> >> +
> >> +  .max_register = S2MPS15_REG_LDODSCH4,
> >> +  .volatile_reg = s2mps11_volatile,
> >> +  .cache_type = REGCACHE_FLAT,
> >> +};
> >> +
> >>  static const struct regmap_config s2mpu02_regmap_config = {
> >>.reg_bits = 8,
> >>.val_bits = 8,
> >> @@ -387,6 +411,9 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> >>case S2MPS14X:
> >>regmap = _regmap_config;
> >>break;
> >> +  case S2MPS15X:
> >> +  regmap = _regmap_config;
> >> +  break;
> >>case S5M8763X:
> >>regmap = _regmap_config;
> >>break;
> >> @@ -445,6 +472,10 @@ static int sec_pmic_probe(struct i2c_client *i2c,
> >>sec_devs = s2mps14_devs;
> >>num_sec_devs = ARRAY_SIZE(s2mps14_devs);
> >>break;
> >> +  case S2MPS15X:

RE: [GIT PULL 4/5] Late Samsung driver updates for v4.4

[Pavel Fedin]

 Hello!

> The noticeable change between v4.1 and v4.2 was for example:
> c4241a582d22 ("ARM: EXYNOS: use PS_HOLD based poweroff for all supported
> SoCs")

 First of all, sorry for misinforming you. It was not v4.1 which worked, but 
3.18 one. I never ran 4.1 on this board, it's my
memory's fault...
 Second, the commit which actually broke 5410 is 
8cfc7fdd33080e30b86d21b1a8c9ad0686427ddc ("ARM: EXYNOS: move restart code into 
pmu
driver"). And we don't have 5410 PMU description in our DT, that's the problem.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 17/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method

[Yakir Yang]

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 24 +++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
 2 files changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 216d33d..4fa5f69 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char 
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 
 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-   unsigned char edid[EDID_BLOCK_LENGTH * 2];
+   unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = analogix_dp_handle_edid(dp);
-   if (ret) {
-   dev_err(dp->dev, "unable to handle edid\n");
-   return;
-   }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 dp->video_info.max_link_rate);
if (ret) {
@@ -947,8 +941,24 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
 int analogix_dp_get_modes(struct device *dev)
 {
struct analogix_dp_device *dp = dev_get_drvdata(dev);
+   struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
 
+   if (dp->plat_data && dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EINVAL;
+   }
+   }
+
+   if (analogix_dp_handle_edid(dp)) {
+   dev_err(dp->dev, "unable to handle edid\n");
+   return -EINVAL;
+   }
+
+   drm_mode_connector_update_edid_property(dp->connector, edid);
+   num_modes += drm_add_edid_modes(dp->connector, edid);
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d3c7e0a..2bd2e0d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
 
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR   0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH  0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM  0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)   (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)   (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)  (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)  (((x) >> 0) & 0x3)
+
 enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolneed_force_hpd;
+   unsigned char   edid[EDID_BLOCK_LENGTH * 2];
 
struct analogix_dp_plat_data *plat_data;
 };
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
-
-/* I2C EDID Chip ID, Slave Address */
-#define I2C_EDID_DEVICE_ADDR   0x50
-#define I2C_E_EDID_DEVICE_ADDR 0x30
-
-#define EDID_BLOCK_LENGTH  0x80
-#define EDID_HEADER_PATTERN0x00

[PATCH v8 16/17] drm: bridge: analogix/dp: move hpd detect to connector detect function

[Yakir Yang]

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3842dbd..216d33d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = analogix_dp_detect_hpd(dp);
-   if (ret) {
-   /* Cable has been disconnected, we're done */
-   return;
-   }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 
 enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
 {
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (analogix_dp_detect_hpd(dp))
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_detect);
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 13/17] drm: bridge: analogix/dp: add some rk3288 special registers setting

[Yakir Yang]

RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12 
 2 files changed, 60 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 861097a..21a3287 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
 #include 
 #include 
 
+#include 
+
 #include "analogix_dp_core.h"
 #include "analogix_dp_reg.h"
 
@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);
 
+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+   writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+   writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+   writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+   writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+   writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+   }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);
 
@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
   bool enable)
 {
u32 reg;
+   u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   phy_pd_addr = ANALOGIX_DP_PD;
 
switch (block) {
case AUX_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   

[PATCH v8 12/17] drm: rockchip: vop: add bpc and color mode setting

[Yakir Yang]

From: Mark Yao 

Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.

Signed-off-by: Mark Yao 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
  video mode, but hard code CRTC video output mode to RGBaaa.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 ++---
 4 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2c82a9a..3990951 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -180,14 +180,29 @@ static void rockchip_dp_drm_encoder_mode_set(struct 
drm_encoder *encoder,
 static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
 {
struct rockchip_dp_device *dp = to_dp(encoder);
+   struct drm_connector *cn = >connector;
+   int ret = -1;
u32 val;
-   int ret;
 
-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   DRM_MODE_CONNECTOR_eDP,
-   ROCKCHIP_OUT_MODE_);
+   /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+   if (cn->display_info.color_formats & DRM_COLOR_FORMAT_RGB444)
+   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
+   DRM_MODE_CONNECTOR_eDP,
+   10, DRM_COLOR_FORMAT_RGB444);
if (ret < 0) {
-   dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
+   dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
return;
}
 
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct 
drm_encoder *encoder)
 static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
 {
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
 }
 
 static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs = 
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device *dev, 
int pipe);
 int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
- int out_mode);
+ int bpc, int color);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..9ef4a1f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1062,14 +1062,40 @@ static const struct drm_plane_funcs vop_plane_funcs = {
 
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
  int connector_type,
- int out_mode)
+ int bpc, int color)
 {
struct vop *vop = to_vop(crtc);
 
+   

[PATCH v8 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

[Yakir Yang]

There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
  flag. (Thierry)

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 +--
 2 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6307060..563ffb1d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}
 
-   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1156,16 +1156,25 @@ static int analogix_dp_dt_parse_pdata(struct 
analogix_dp_device *dp)
struct device_node *dp_node = dp->dev->of_node;
struct video_info *video_info = >video_info;
 
-   if (of_property_read_u32(dp_node, "samsung,link-rate",
-_info->link_rate)) {
-   dev_err(dp->dev, "failed to get link-rate\n");
-   return -EINVAL;
-   }
-
-   if (of_property_read_u32(dp_node, "samsung,lane-count",
-_info->lane_count)) {
-   dev_err(dp->dev, "failed to get lane-count\n");
-   return -EINVAL;
+   switch (dp->plat_data && dp->plat_data->dev_type) {
+   case RK3288_DP:
+   /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+   video_info->max_link_rate = 0x0A;
+   video_info->max_lane_count = 0x04;
+   break;
+   case EXYNOS_DP:
+   /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+   of_property_read_u32(dp_node, "samsung,link-rate",
+_info->max_link_rate);
+   of_property_read_u32(dp_node, "samsung,lane-count",
+_info->max_lane_count);
+   break;
}
 
return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index e37cef6..e6f8243 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
 
-   enum link_rate_type link_rate;
-   enum link_lane_count_type lane_count;
+   enum link_rate_type max_link_rate;
+   enum link_lane_count_type max_lane_count;
 };
 
 struct link_train {
-- 
1.9.1


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/4] ARM: dts: Add SROMc to Exynos 5410

[Pankaj Dubey]

Hi

On Wednesday 28 October 2015 12:54 PM, Krzysztof Kozlowski wrote:

On 28.10.2015 16:06, Pavel Fedin wrote:

  Hello!


+   sromc: sromc@1225 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x10>;


Isn't 0x10 too small (SROM_BC3 won't be mapped)?


  Muhaha, indeed, thanks for noticing this.
  By the way, i've just checked exynos4.dtsi and exynos5.dtsi, they specify the 
same size. Did reviewers overlook this small thing?


Yep, I pointed that 0x100 (from first version of patchset) is too big...
but did not exactly check the length of new value.



Yes, once you pointed out I checked UM for Exynos4415, Exynos5250, 
Exynos5420 and Exynos5410 and all these manuals talks about SROM_BC{0-3} 
only. There is no offset such as SROM_BC{4,5} at least in these SoC 
manuals. Accordingly I modified size from 0x100 to 0x10. But looks like 
I missed to remove SROM_BC{{4,5} from exynos-srom.h. I checked only 
these registers are used in the driver, so as such it should not cause 
any issue in driver as of now, only we have some redundant entry in 
exynos-srom.h which can be removed if it's not applicable for any of 
Exynos SoC, after confirmation from Kukjin.




Shouldn't it be fixed then?


Yes. It hasn't been pulled yet by arm-soc... Let's wait Kukjin's opinion
how to deal with exynos[45].dtsi.




Best regards,
Krzysztof



Thanks,
Pankaj Dubey
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: exynos: Bring back reboot on Exynos5410

[Pavel Fedin]

Since 8cfc7fdd33080e30b86d21b1a8c9ad0686427ddc ("ARM: EXYNOS: move restart
code into pmu driver") PMU support is required in order for the reboot to
work. Unfortunately, there is currently no PMU support for 5410.

This patch adds exynos5410-pmu to the list of recognized devices. It is
okay for the code to have empty struct exynos_pmu_data, in this case only
minimal support is enabled. This is enough for SWRESET to work.

Signed-off-by: Pavel Fedin 
---
 arch/arm/mach-exynos/pmu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
index de68938..7b9e33c 100644
--- a/arch/arm/mach-exynos/pmu.c
+++ b/arch/arm/mach-exynos/pmu.c
@@ -908,6 +908,10 @@ static const struct exynos_pmu_data exynos5250_pmu_data = {
.powerdown_conf = exynos5_powerdown_conf,
 };
 
+static struct exynos_pmu_data exynos5410_pmu_data = {
+   /* Only SWRESET is currently supported on 5410 */
+};
+
 static struct exynos_pmu_data exynos5420_pmu_data = {
.pmu_config = exynos5420_pmu_config,
.pmu_init   = exynos5420_pmu_init,
@@ -934,6 +938,9 @@ static const struct of_device_id exynos_pmu_of_device_ids[] 
= {
.compatible = "samsung,exynos5250-pmu",
.data = _pmu_data,
}, {
+   .compatible = "samsung,exynos5410-pmu",
+   .data = _pmu_data,
+   }, {
.compatible = "samsung,exynos5420-pmu",
.data = _pmu_data,
},
-- 
2.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/4] ARM: dts: Add SROMc to Exynos 5410

[Krzysztof Kozlowski]

On 28.10.2015 18:30, Pankaj Dubey wrote:
> Hi
> 
> On Wednesday 28 October 2015 12:54 PM, Krzysztof Kozlowski wrote:
>> On 28.10.2015 16:06, Pavel Fedin wrote:
>>>   Hello!
>>>
> +sromc: sromc@1225 {
> +compatible = "samsung,exynos-srom";
> +reg = <0x1225 0x10>;

 Isn't 0x10 too small (SROM_BC3 won't be mapped)?
>>>
>>>   Muhaha, indeed, thanks for noticing this.
>>>   By the way, i've just checked exynos4.dtsi and exynos5.dtsi, they
>>> specify the same size. Did reviewers overlook this small thing?
>>
>> Yep, I pointed that 0x100 (from first version of patchset) is too big...
>> but did not exactly check the length of new value.
>>
> 
> Yes, once you pointed out I checked UM for Exynos4415, Exynos5250,
> Exynos5420 and Exynos5410 and all these manuals talks about SROM_BC{0-3}
> only. There is no offset such as SROM_BC{4,5} at least in these SoC
> manuals. Accordingly I modified size from 0x100 to 0x10. But looks like
> I missed to remove SROM_BC{{4,5} from exynos-srom.h. I checked only
> these registers are used in the driver, so as such it should not cause
> any issue in driver as of now, only we have some redundant entry in
> exynos-srom.h which can be removed if it's not applicable for any of
> Exynos SoC, after confirmation from Kukjin.

I was not referring to SROM_BC[45] but to SROM_BC3 which has the offset
of 0x10.

Best regards,
Krzysztof


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

 Hello!

> There is no offset such as SROM_BC{4,5} at least in these SoC
> manuals. Accordingly I modified size from 0x100 to 0x10.

 0x10 is indeed an offset for SROM_BC3. But, it occupies 4 bytes by itself, and 
you have to include it, because you are describing
*SIZE* of the region. :)

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Alexandre Belloni]

On 28/10/2015 at 12:31:43 +0900, Krzysztof Kozlowski wrote :
> The s2mps13 clock driver added new name and compatible... which was
> probably totally unneeded (I missed that during review). We don't have
> to make this as a rule...
> 
> Since we do not have any data about future workarounds and the
> differences then just follow Ockham's razor - use the same name and
> compatible.
> 

So you don't care about DT backward compatibility because when a
workaround will be needed for one of the IPs, then you will have to
update the old dtb to use it.

Unless you are sure that the IP is the same, doing

{ "s2mps15-rtc",S2MPS14X },

is probably the best way to handle that. Note that I personally don't
care about the DT ABI, I'm just pointing out what may happen ;)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [rtc-linux] Re: [PATCH v3 5/5] drivers/rtc/rtc-s5m.c: add support for S2MPS15 RTC

[Alim Akhtar]

Hi Alexandre,

On 10/28/2015 03:18 PM, Alexandre Belloni wrote:

On 28/10/2015 at 12:31:43 +0900, Krzysztof Kozlowski wrote :

The s2mps13 clock driver added new name and compatible... which was
probably totally unneeded (I missed that during review). We don't have
to make this as a rule...

Since we do not have any data about future workarounds and the
differences then just follow Ockham's razor - use the same name and
compatible.



So you don't care about DT backward compatibility because when a
workaround will be needed for one of the IPs, then you will have to
update the old dtb to use it.

Unless you are sure that the IP is the same, doing

{ "s2mps15-rtc",  S2MPS14X },

is probably the best way to handle that. Note that I personally don't
care about the DT ABI, I'm just pointing out what may happen ;)

Thats what my point is, anyway I am still looking into the fine prints 
of the s2mps15 and s2mps14 user manual, now I have found at least one 
difference in their one of the register bit, which might be a good 
reason to keep s2mps15-rtc device.

Will update the same in v4.
Thanks,

--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler

[Javier Martinez Canillas]

Hello Ulf,

On 10/27/2015 11:10 AM, Ulf Hansson wrote:
> On 21 October 2015 at 17:15, Javier Martinez Canillas
>  wrote:
>> The pwrseq_emmc driver does a eMMC card reset before a system reboot to
>> allow broken or limited ROM boot-loaders (that don't have an eMMC reset
>> logic) to be able to read the second stage from the eMMC.
>>
>> But this has to be called before a system reboot handler and while most
>> of them use the priority 128, there are other restart handlers (such as
>> the syscon-reboot one) that use a higher priority. So, use the highest
>> priority to make sure that the eMMC hw is reset before a system reboot.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> Tested-by: Markus Reichl 
>> Tested-by: Anand Moon 
>> Reviewed-by: Alim Akhtar 
>>
>> ---
>> Hello,
>>
>> This patch was needed since a recent series from Alim [0] added
>> syscon reboot and poweroff support to Exynos SoCs and removed
>> the reset handler in the Exynos Power Management Unit (PMU) code.
>>
>> But the PMU and syscon-reboot restart handler have a different
>> priority so [0] breaks restart when eMMC is used on these boards.
>>
>> [0]: http://www.spinics.net/lists/arm-kernel/msg454396.html
>>
>> So this patch must be merged before [0] to avoid regressions.
>>
>> Best regards,
>> Javier
> 
> So it seems like there have been a good discussion around this. I
> don't have any objections, but is more concerned about potential
> regressions.
>

Yes, there was a lot of discussion indeed but it seems we all agree
on the approach and that the patch should not land before having a
lot of testing.
 
> I have queued it up for next (4.4) so we get some testing in
> linux-next. If anyone have issues, please report them.
>

great, some weeks sitting in -next to let the CI infrastructure to
play with it seems reasonable to me. Thanks a lot!
 
> Kind regards
> Uffe
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html