[PATCH 3/3] clockevents/exynos_mct: Implement ->set_state_oneshot_stopped()

2015-12-23 Thread Viresh Kumar
set_state_oneshot_stopped() is called by the clkevt core, when the next
event is required at an expiry time of 'KTIME_MAX'. This normally
happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes.

This patch makes the clockevent device to stop on such an event, to
avoid spurious interrupts, as explained by: commit 8fff52fd5093
("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state").

Signed-off-by: Viresh Kumar 
---
 drivers/clocksource/exynos_mct.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index ff44082a0827..be09bc0b5e26 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -313,6 +313,7 @@ static struct clock_event_device mct_comp_device = {
.set_state_periodic = mct_set_state_periodic,
.set_state_shutdown = mct_set_state_shutdown,
.set_state_oneshot  = mct_set_state_shutdown,
+   .set_state_oneshot_stopped = mct_set_state_shutdown,
.tick_resume= mct_set_state_shutdown,
 };
 
@@ -452,6 +453,7 @@ static int exynos4_local_timer_setup(struct 
mct_clock_event_device *mevt)
evt->set_state_periodic = set_state_periodic;
evt->set_state_shutdown = set_state_shutdown;
evt->set_state_oneshot = set_state_shutdown;
+   evt->set_state_oneshot_stopped = set_state_shutdown;
evt->tick_resume = set_state_shutdown;
evt->features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
evt->rating = 450;
-- 
2.7.0.rc1.186.g94414c4

--
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] regulator: s2m,s5m: constify regulator_ops structures

2015-12-23 Thread Mark Brown
On Wed, Dec 23, 2015 at 08:20:43AM +0100, Julia Lawall wrote:
> On Wed, 23 Dec 2015, Mark Brown wrote:

> > On Sat, Dec 19, 2015 at 03:58:00PM +0100, Julia Lawall wrote:
> > > The regulator_ops structures are never modified, so declare them as const.

> > > Done with the help of Coccinelle.

> > This doesn't apply against current code, please check and resend.

> It works fine for me on today's linux-next (80c75a0f1d).  What goes wrong?

It just doesn't apply against my tree.  Presumably there's a change
somewhere else in -next (probably the MFD tree).


signature.asc
Description: PGP signature


Re: [PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

2015-12-23 Thread Krzysztof Kozlowski
W dniu 18.12.2015 o 18:16, Pavel Fedin pisze:
>  Hello!
> 
>> 4. This branch is not pushed to linux-next. I will sort it out if my
>> previous pull requests get in. I will be out of office for Christmas so
>> depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
>> not go into v4.5 (yay...).
>>
>> 5. If it does not get into v4.5, I will rebase it and proceed further
>> for v4.6.
>>
>> If you have any questions, please let me know.
> 
>  Thank you very much. No, i don't have any questions, i'm glad that my work 
> is picked up and not lost, i'm just keeping an eye on it
> until it goes to stable.
> 
>  P.S. Not related to these sets directly, just to note... When i was writing 
> the doc for SROMc bindings, i noticed that we have two
> directories for Exynos in Documentation/devicetree/bindings/arm:
> 1. Documentation/devicetree/bindings/arm/exynos
> 2. Documentation/devicetree/bindings/arm/Samsung
> 
>  In (1) we have only a single old file, shouldn't this be cleaned up and 
> shouldn't this file be moved to (2)?

Thanks for hind but I already cleaned it up:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=068812ed108acbfe070b893faba9845fe2ea3fd9

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 v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

2015-12-23 Thread Jingoo Han
On Wednesday, December 23, 2015 9:51 PM, Yakir Yang wrote:
> 
> On Rockchip platform, sometimes driver would failed at reading EDID
> message, and it's caused by the AUX reply flag wouldn't received under
> the 100*10us wait time.

The problem is specific for Rockchip platform.
Also, 1 ms is long time.
The best way is that your hardware engineers find the root cause.
I cannot understand why your engineers cannot find the root cause. :-(

> 
> But after expand the wait time a little, the AUX reply flag would be
> set, so maybe the wait time is a little critical. Besides the analogix
> dp book haven't reminded the standard wait for looking AUX reply flag,
> so I thought it's okay to expand the wait time.
> 
> And the external wait time won't hurt Exynos DP too much, cause they
> wouldn't meet this problem, then driver would received the reply command
> very soon, so no more additional wait time would bring to Exynos platform.

Then, when loop time happens on Exynos platform, it will take long time
to return error.

> 
> Signed-off-by: Yakir Yang 
> ---
> Changes in v12:
> - Using another way to expand the AUX reply wait time (Jingoo)
> 
> Changes in v11: None
> Changes in v10: None
> Changes in v9: None
> 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
> 
>  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index cba3ffd..8687eea 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct 
> analogix_dp_device *dp)
>  {
>   int reg;
>   int retval = 0;
> - int timeout_loop = 0;
> + unsigned long timeout;
> 
>   /* Enable AUX CH operation */
>   reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> @@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct 
> analogix_dp_device *dp)
>   writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
> 
>   /* Is AUX CH command reply received? */
> - reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> - while (!(reg & RPLY_RECEIV)) {
> - timeout_loop++;
> - if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> + timeout = jiffies + msecs_to_jiffies(5);
> + while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
> + if (time_after(jiffies, timeout)) {
>   dev_err(dp->dev, "AUX CH command reply failed!\n");
>   return -ETIMEDOUT;
>   }
> - reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);

Sorry, I don't like your patch.

The problem happens because of Rockchip platform.
So, you need to add workaround for only Rockchip platform.

Just add new DT property and new variable for the value for wait time.
When, the probe is called, new wait time value is read from Rockchip DT file.
Then, the new wait time value can be written to the new variable.

new DT property: wait-time-aux
new variable: wait_time_aux


If ( ) // New DT 
wait_time_aux = New DT;
else 
wait_time_aux = 10;


>   usleep_range(10, 11);

If there is NO  new wait time value from DT file, the default value '10' is
used for sleep.

But, if there is new wait time value from DT file, new wait time value
can be used for sleep.

 usleep_range(dp->wait_time_aux, dp->wait_time_aux + 1);

What I want to say is that there should be NO effect on Exynos platform,
because of the hardware bug of Rockchip platform.

Best regards,
Jingoo Han

>   }
> 
> --
> 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 v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply

2015-12-23 Thread Jingoo Han
On Wednesday, December 23, 2015 3:01 PM, Yakir Yang wrote:
> 
> Hi Jingoo,
> 
> On 12/23/2015 12:24 PM, Yakir Yang wrote:
> > Hi Jingoo,
> >
> > On 12/22/2015 08:26 PM, Jingoo Han wrote:
> >> On Wednesday, December 16, 2015 12:58 PM, Yakir Yang wrote:
> >>> After test on rockchiop platform, i found sometims driver would failed
> >>> at reading EDID message. After debugging more, i found that it's okay
> >>> to read_a byte from i2c, but it would failed at AUX transcation if we
> >>> try to ready multi-bytes from i2c.
> >>>
> >>> Driver just can't received the AUX CH reply command, even no AUX error
> >>> code. I may guess that the AUX wait time is not enough, so I try to
> >>> expand the AUX wait time, and i do see this could fix the EDID read
> >>> failed at rockchip platform.
> >>>
> >>> And I thought that expand the wait time won't hurt Exynos platform too
> >>> much, cause Exynos didn't have this problem, then driver would received
> >>> the reply command very soon, so no more additional wait time would
> >>> bring
> >>> to Exynos platform.
> >>>
> >>> Signed-off-by: Yakir Yang 
> >>> ---
> >>> Changes in v11: None
> >>> Changes in v10: None
> >>> Changes in v9: None
> >>> 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
> >>>
> >>>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> index c7e2959..dc376bd 100644
> >>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> >>> @@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct
> >>> analogix_dp_device *dp)
> >>>   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
> >>>   while (!(reg & RPLY_RECEIV)) {
> >>>   timeout_loop++;
> >>> -if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
> >>> +if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
> >> No, I hate this coding.
> >> analogix_dp_reg.c is the common code that can be shared by various SoCs.
> >> Please, find another way.
> >
> > Okay, I have double checked that i do have this problem in my side.
> > Hmmm.
> > I thought it's okay for you if I expand the "DP_TIMEOUT_LOOP_COUNT"
> > directly,
> > it won't hurt Exynos platform too much, cause Exynos didn't have this
> > problem,
> > then driver would received,the reply command very soon, so no more
> > additional
> > wait time would bring to Exynos platform.
> >
> 
> Oh, sorry, little mistaken, I mean, is it okay for you to expand the
> "DP_TIMEOUT_LOOP_COUNT" directly ?

NO.

Don't change DP_TIMEOUT_LOOP_COUNT.
Just, change wait time by adding new DT property.

> 
> - Yakir
> 
> 
> > And actually the datasheet haven't described the spec of aux reply
> > delay time.

Right.
However, the problem is specific for Rockchip platform.
It is the hardware bug of Rockchip platform.
Your delay time is too long to apply to other SoCs platform.

Best regards,
Jingoo Han

> >
> > Thanks,
> > - Yakir
> >
> >> Best regards,
> >> Jingoo Han
> >>
> >>
> >>>   dev_err(dp->dev, "AUX CH command reply failed!\n");
> >>>   return -ETIMEDOUT;
> >>>   }
> >>> --
> >>> 1.9.1
> >>
> >>
> >>
> >>
> >
> >
> >
> > ___
> > Linux-rockchip mailing list
> > linux-rockc...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> >
> >
> >


--
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 v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

2015-12-23 Thread Yakir Yang

Hi Jingoo,

Okay, fine, I would drop this patch, until I found the the root cause.

- Yakir

On 12/23/2015 11:10 PM, Jingoo Han wrote:

On Wednesday, December 23, 2015 9:51 PM, Yakir Yang wrote:

On Rockchip platform, sometimes driver would failed at reading EDID
message, and it's caused by the AUX reply flag wouldn't received under
the 100*10us wait time.

The problem is specific for Rockchip platform.
Also, 1 ms is long time.
The best way is that your hardware engineers find the root cause.
I cannot understand why your engineers cannot find the root cause. :-(


But after expand the wait time a little, the AUX reply flag would be
set, so maybe the wait time is a little critical. Besides the analogix
dp book haven't reminded the standard wait for looking AUX reply flag,
so I thought it's okay to expand the wait time.

And the external wait time won't hurt Exynos DP too much, cause they
wouldn't meet this problem, then driver would received the reply command
very soon, so no more additional wait time would bring to Exynos platform.

Then, when loop time happens on Exynos platform, it will take long time
to return error.


Signed-off-by: Yakir Yang 
---
Changes in v12:
- Using another way to expand the AUX reply wait time (Jingoo)

Changes in v11: None
Changes in v10: None
Changes in v9: None
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

  drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cba3ffd..8687eea 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
  {
int reg;
int retval = 0;
-   int timeout_loop = 0;
+   unsigned long timeout;

/* Enable AUX CH operation */
reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
@@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);

/* Is AUX CH command reply received? */
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   while (!(reg & RPLY_RECEIV)) {
-   timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   timeout = jiffies + msecs_to_jiffies(5);
+   while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
+   if (time_after(jiffies, timeout)) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);

Sorry, I don't like your patch.

The problem happens because of Rockchip platform.
So, you need to add workaround for only Rockchip platform.

Just add new DT property and new variable for the value for wait time.
When, the probe is called, new wait time value is read from Rockchip DT file.
Then, the new wait time value can be written to the new variable.

 new DT property: wait-time-aux
 new variable: wait_time_aux


If ( ) // New DT
 wait_time_aux = New DT;
else
 wait_time_aux = 10;



usleep_range(10, 11);

If there is NO  new wait time value from DT file, the default value '10' is
used for sleep.

But, if there is new wait time value from DT file, new wait time value
can be used for sleep.

  usleep_range(dp->wait_time_aux, dp->wait_time_aux + 1);

What I want to say is that there should be NO effect on Exynos platform,
because of the hardware bug of Rockchip platform.

Best regards,
Jingoo Han


}

--
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 1/3] dt-bindings: regulator/clock/mfd: Reorganize S2MPS-family bindings

2015-12-23 Thread Michael Turquette
On Thu, Dec 3, 2015 at 5:10 PM, Krzysztof Kozlowski
 wrote:
> Bindings for Samsung S2M and S5M family PMICs are in mess. They are
> spread over different files and subdirectories in a non-consistent way.
> The devices and respective drivers for them share a lot in common so
> everything could be organized in a more readable way.
>
> Reorganize the S2MPS11/13/14/15 Device Tree bindings to match the
> drivers for this family of devices:
>  - move mfd/s2mps11.txt to mfd/samsung,sec-core.txt for the main MFD
>driver (common for entire family),
>  - split clock block to clock/samsung,s2mps11.txt,
>  - split regulator block to regulator/samsung,s2mps11.txt.
>
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Michael Turquette 

> ---
>  .../devicetree/bindings/clock/samsung,s2mps11.txt  |  49 +++
>  Documentation/devicetree/bindings/mfd/s2mps11.txt  | 153 
> -
>  .../devicetree/bindings/mfd/samsung,sec-core.txt   |  84 +++
>  .../bindings/regulator/samsung,s2mps11.txt | 102 ++
>  MAINTAINERS|   4 +-
>  5 files changed, 238 insertions(+), 154 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
>  delete mode 100644 Documentation/devicetree/bindings/mfd/s2mps11.txt
>  create mode 100644 Documentation/devicetree/bindings/mfd/samsung,sec-core.txt
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/samsung,s2mps11.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt 
> b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> new file mode 100644
> index ..2726c1d58a79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/samsung,s2mps11.txt
> @@ -0,0 +1,49 @@
> +Binding for Samsung S2M and S5M family clock generator block
> +
> +
> +This is a part of device tree bindings for S2M and S5M family multi-function
> +devices.
> +More information can be found in bindings/mfd/sec-core.txt file.
> +
> +The S2MPS11/13/15 and S5M8767 provide three(AP/CP/BT) buffered 32.768 kHz
> +outputs. The S2MPS14 provides two (AP/BT) buffered 32.768 KHz outputs.
> +
> +To register these as clocks with common clock framework instantiate under
> +main device node a sub-node named "clocks".
> +
> +It uses the common clock binding documented in:
> + - Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +
> +Required properties of the "clocks" sub-node:
> + - #clock-cells: should be 1.
> + - compatible: Should be one of: "samsung,s2mps11-clk", 
> "samsung,s2mps13-clk",
> +   "samsung,s2mps14-clk", "samsung,s5m8767-clk"
> +   The S2MPS15 uses the same compatible as S2MPS13, as both provides similar
> +   clocks.
> +
> +
> +Each clock is assigned an identifier and client nodes use this identifier
> +to specify the clock which they consume.
> +Clock   ID   Devices
> +--
> +32KhzAP0S2MPS11/13/14/15, S5M8767
> +32KhzCP1S2MPS11/13/15, S5M8767
> +32KhzBT2S2MPS11/13/14/15, S5M8767
> +
> +Include dt-bindings/clock/samsung,s2mps11.h file to use preprocessor defines
> +in device tree sources.
> +
> +
> +Example:
> +
> +   s2mps11_pmic@66 {
> +   compatible = "samsung,s2mps11-pmic";
> +   reg = <0x66>;
> +
> +   s2m_osc: clocks {
> +   compatible = "samsung,s2mps11-clk";
> +   #clock-cells = <1>;
> +   clock-output-names = "xx", "yy", "zz";
> +   };
> +   };
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> deleted file mode 100644
> index 09b94c97faac..
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ /dev/null
> @@ -1,153 +0,0 @@
> -
> -* 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
> -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 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:
> -- interrupt-parent: Specifies the phandle of the interrupt controller to 
> which
> -  the interrupts from s2mps11 are delivered to.
> -- interrupts: 

[PATCH v12 0/18] Add Analogix Core Display Port Driver

2015-12-23 Thread 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 different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate 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).

Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to
splict the connector init to platform driver anymore, and this is the biggest
change in version 12.

I have tested this on Rockchip Pinky platform, but

Previous version have been well tested on Rockchip platform and Samsung 
platform,
but for this version I only tested on Rockchip Pinky Chromebook, haven't tested
on Samsung platform yet(would test later).

Thanks,
- Yakir


Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper(Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)
- Using another way to expand the AUX reply wait time (Jingoo)

Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

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 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 

[PATCH v12 02/18] drm: bridge: analogix/dp: fix some obvious code style

2015-12-23 Thread Yakir Yang
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
Acked-by: Jingoo Han 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v12:
- Add the ack from Jingoo

Changes in v11: None
Changes in v10: None
Changes in v9: None
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 3ac4f1d..915fb46 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -64,7 +64,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;
}
@@ -101,8 +101,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;
 
@@ -110,7 +110,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]);
@@ -141,7 +142,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,
@@ -155,10 +156,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;
@@ -169,16 +168,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) 

[PATCH v12 06/18] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

2015-12-23 Thread 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.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Jingoo Han < jingooh...@gmail.com> 
Tested-by: Javier Martinez Canillas 
---
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
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 5cb33ba..b96624b 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 35cfb07..2f37c87 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 

[PATCH v12 03/18] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

2015-12-23 Thread 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}.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v12:
- Remove the enum link_rate_type struct, using the marcos in drm_dp_helper.h 
(Jingoo)

Changes in v11: None
Changes in v10: None
Changes in v9: None
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 | 14 +++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  7 +--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  2 +-
 3 files changed, 9 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 915fb46..fac8ad4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -627,6 +627,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;
@@ -647,7 +649,7 @@ static void analogix_dp_get_max_rx_lane_count(struct 
analogix_dp_device *dp,
 
 static void analogix_dp_init_training(struct analogix_dp_device *dp,
  enum link_lane_count_type max_lane,
- enum link_rate_type max_rate)
+ int max_rate)
 {
/*
 * MACRO_RST must be applied after the PLL_LOCK to avoid
@@ -659,11 +661,12 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
analogix_dp_get_max_rx_bandwidth(dp, >link_train.link_rate);
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)) {
+   if ((dp->link_train.link_rate != DP_LINK_BW_1_62) &&
+   (dp->link_train.link_rate != DP_LINK_BW_2_7) &&
+   (dp->link_train.link_rate != DP_LINK_BW_5_4)) {
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;
+   dp->link_train.link_rate = DP_LINK_BW_1_62;
}
 
if (dp->link_train.lane_count == 0) {
@@ -901,9 +904,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 f7dfc8e..911642e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,11 +20,6 @@
 #define MAX_CR_LOOP5
 #define MAX_EQ_LOOP5
 
-enum link_rate_type {
-   LINK_RATE_1_62GBPS = 0x06,
-   LINK_RATE_2_70GBPS = 0x0a
-};
-
 enum link_lane_count_type {
LANE_COUNT1 = 1,
LANE_COUNT2 = 2,
@@ -128,7 +123,7 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
 
-   enum link_rate_type link_rate;
+   int link_rate;
enum link_lane_count_type lane_count;
 };
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index a388c0a..eb0b63c 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -855,7 +855,7 @@ void analogix_dp_set_link_bandwidth(struct 
analogix_dp_device *dp, u32 bwtype)
u32 reg;
 
reg = bwtype;
-   if ((bwtype == LINK_RATE_2_70GBPS) || (bwtype == 

[PATCH v12 04/18] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

2015-12-23 Thread 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.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
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 fac8ad4..27752df 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,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;
@@ -1077,6 +1077,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" 

[PATCH v12 05/18] dt-bindings: add document for analogix display port driver

2015-12-23 Thread 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.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9: None
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 64693f2..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
-   

[PATCH v12 07/18] drm: rockchip: dp: add rockchip platform dp driver

2015-12-23 Thread 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.

Signed-off-by: Yakir Yang 
---
Changes in v12: None
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)

Changes in v9: None
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 | 385 
 include/drm/bridge/analogix_dp.h|   1 +
 4 files changed, 396 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..686cb49 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..9552273
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,385 @@
+/*
+ * 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_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);

[PATCH v12 08/18] dt-bindings: add document for rockchip variant of analogix_dp

2015-12-23 Thread 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.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---
Changes in v12: None
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9:
- Document more details for 'ports' property.

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  | 91 ++
 1 file changed, 91 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..04d99e3
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+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: there are 2 port nodes with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the output of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+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 v12 09/18] phy: Add driver for rockchip Display Port PHY

2015-12-23 Thread Yakir Yang
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Signed-off-by: Yakir Yang 
Reviewed-by: Heiko Stuebner 
---
Changes in v12:
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)

Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)

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..88f09ec
--- /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(20)
+#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;
+}
+

[PATCH v12 11/18] drm: bridge: analogix/dp: add some rk3288 special registers setting

2015-12-23 Thread Yakir Yang
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.

Signed-off-by: Yakir Yang 
---
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
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 3858df5..1e24b37 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 v12 12/18] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

2015-12-23 Thread 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.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v12: None
Changes in v11: None
Changes in v10:
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9: None
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 27752df..7c5f1f7 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -893,8 +893,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;
@@ -1203,16 +1203,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->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 d488dd6..6cc53d4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -123,8 +123,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;
 
-   int link_rate;
-   enum link_lane_count_type lane_count;
+   int 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


[PATCH v12 13/18] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

2015-12-23 Thread Yakir Yang
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.

This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Tested-by: Javier Martinez Canillas 
---
Changes in v12: None
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt|  4 ++-
 .../bindings/display/exynos/exynos_dp.txt  |  1 +
 .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
 6 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".
 
 Optional properties for dp-controller:
+   -force-hpd:
+   Indicate driver need force hpd when hpd detect failed, this
+   is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
* 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
 
-
 [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 ---
 
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding 
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+   -analogix,need-force-hpd (optional)
-video interfaces (optional)
 
 Deprecated properties for DisplayPort:
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding 
document:
 - phys (required)
 - phy-names (required)
 - hpd-gpios (optional)
+- force-hpd (optional)
 ---
 
 Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 7c5f1f7..0be1ac8 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -62,15 +62,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 {
int timeout_loop = 0;
 
-   while (analogix_dp_get_plug_in_status(dp) != 0) {
+   while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+   if (analogix_dp_get_plug_in_status(dp) == 0)
+   return 0;
+
timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "failed to get hpd plug status\n");
-   return -ETIMEDOUT;
-   }
usleep_range(10, 11);
}
 
+   /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+   if (!dp->force_hpd)
+   return -ETIMEDOUT;
+
+   /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+   

[PATCH v12 14/18] drm: bridge: analogix/dp: move hpd detect to connector detect function

2015-12-23 Thread 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().

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase

But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v12: None
Changes in v11:
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10: None
Changes in v9: None
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 | 38 --
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 0be1ac8..1ff2d8ee 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -904,12 +904,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");
@@ -972,6 +966,11 @@ static struct drm_connector_helper_funcs 
analogix_dp_connector_helper_funcs = {
 enum drm_connector_status
 analogix_dp_detect(struct drm_connector *connector, bool force)
 {
+   struct analogix_dp_device *dp = to_dp(connector);
+
+   if (analogix_dp_detect_hpd(dp))
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 
@@ -1051,13 +1050,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge 
*bridge)
 
pm_runtime_get_sync(dp->dev);
 
-   if (dp->plat_data->panel) {
-   if (drm_panel_prepare(dp->plat_data->panel)) {
-   DRM_ERROR("failed to setup the panel\n");
-   return;
-   }
-   }
-
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
 
@@ -1090,11 +1082,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
 
-   if (dp->plat_data->panel) {
-   if (drm_panel_unprepare(dp->plat_data->panel))
-   DRM_ERROR("failed to turnoff the panel\n");
-   }
-
pm_runtime_put_sync(dp->dev);
 
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1352,6 +1339,15 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
 
pm_runtime_enable(dev);
 
+   phy_power_on(dp->phy);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EBUSY;
+   }
+   }
+
ret = devm_request_irq(>dev, dp->irq, analogix_dp_irq_handler,
   irq_flags, "analogix-dp", dp);
if (ret) {
@@ -1385,6 +1381,12 @@ void analogix_dp_unbind(struct device *dev, struct 
device *master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
analogix_dp_bridge_disable(dp->bridge);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_unprepare(dp->plat_data->panel))
+   DRM_ERROR("failed to turnoff the panel\n");
+   }
+
pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
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 v12 15/18] drm: bridge: analogix/dp: add edid modes parse in get_modes method

2015-12-23 Thread 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.

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase

But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
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 | 17 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
 2 files changed, 33 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 1ff2d8ee..a86a283 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -110,7 +110,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;
@@ -904,12 +904,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) {
@@ -939,8 +933,14 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 int analogix_dp_get_modes(struct drm_connector *connector)
 {
struct analogix_dp_device *dp = to_dp(connector);
+   struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
 
+   if (analogix_dp_handle_edid(dp) == 0) {
+   drm_mode_connector_update_edid_property(>connector, edid);
+   num_modes += drm_add_edid_modes(>connector, edid);
+   }
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
 
@@ -978,6 +978,7 @@ static void analogix_dp_connector_destroy(struct 
drm_connector *connector)
 {
drm_connector_unregister(connector);
drm_connector_cleanup(connector);
+
 }
 
 static struct drm_connector_funcs analogix_dp_connector_funcs = {
@@ -1348,6 +1349,8 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
}
}
 
+   analogix_dp_init_dp(dp);
+
ret = devm_request_irq(>dev, dp->irq, analogix_dp_irq_handler,
   irq_flags, "analogix-dp", 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 a8cba64..40a0759 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_LOOP5
 #define MAX_EQ_LOOP5
 
+/* 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_lane_count_type {
LANE_COUNT1 = 1,
LANE_COUNT2 = 2,
@@ -155,6 +177,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
+   

[PATCH v12 16/18] drm: bridge: analogix/dp: expand the wait time for looking AUX CH reply flag

2015-12-23 Thread Yakir Yang
On Rockchip platform, sometimes driver would failed at reading EDID
message, and it's caused by the AUX reply flag wouldn't received under
the 100*10us wait time.

But after expand the wait time a little, the AUX reply flag would be
set, so maybe the wait time is a little critical. Besides the analogix
dp book haven't reminded the standard wait for looking AUX reply flag,
so I thought it's okay to expand the wait time.

And the external wait time won't hurt Exynos DP too much, cause they
wouldn't meet this problem, then driver would received the reply command
very soon, so no more additional wait time would bring to Exynos platform.

Signed-off-by: Yakir Yang 
---
Changes in v12:
- Using another way to expand the AUX reply wait time (Jingoo)

Changes in v11: None
Changes in v10: None
Changes in v9: None
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

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index cba3ffd..8687eea 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -471,7 +471,7 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
 {
int reg;
int retval = 0;
-   int timeout_loop = 0;
+   unsigned long timeout;
 
/* Enable AUX CH operation */
reg = readl(dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
@@ -479,14 +479,12 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
writel(reg, dp->reg_base + ANALOGIX_DP_AUX_CH_CTL_2);
 
/* Is AUX CH command reply received? */
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
-   while (!(reg & RPLY_RECEIV)) {
-   timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   timeout = jiffies + msecs_to_jiffies(5);
+   while ((readl(dp->reg_base + ANALOGIX_DP_INT_STA) & RPLY_RECEIV) == 0) {
+   if (time_after(jiffies, timeout)) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
-   reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
usleep_range(10, 11);
}
 
-- 
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 v12 17/18] drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time

2015-12-23 Thread Yakir Yang
Turn off the panel power in suspend time would help to reduce
power waste.

Signed-off-by: Yakir Yang 
---
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
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

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a86a283..1e98489 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1400,6 +1400,12 @@ int analogix_dp_suspend(struct device *dev)
struct analogix_dp_device *dp = dev_get_drvdata(dev);
 
clk_disable_unprepare(dp->clock);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_unprepare(dp->plat_data->panel))
+   DRM_ERROR("failed to turnoff the panel\n");
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1415,6 +1421,13 @@ int analogix_dp_resume(struct device *dev)
return ret;
}
 
+   if (dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EBUSY;
+   }
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_resume);
-- 
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 v12 18/18] drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable time

2015-12-23 Thread Yakir Yang
It may caused a dead lock if we flush the hpd work in bridge disable time.

The normal flow would like:
  IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
  OUT <-- analogix_dp_bridge
  OUT <-- DRM IOCTL

The dead lock flow would like:
  IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
  IN --> analogix_dp_hotplug
  IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in 
previous step 1)
** Dead Lock Now **

It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.

The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.

Signed-off-by: Yakir Yang 
---
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
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

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 26 +
 3 files changed, 55 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 1e98489..04efed2 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -851,47 +851,40 @@ static void analogix_dp_enable_scramble(struct 
analogix_dp_device *dp,
}
 }
 
-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
 {
struct analogix_dp_device *dp = arg;
-
+   irqreturn_t ret = IRQ_NONE;
enum dp_irq_type irq_type;
 
irq_type = analogix_dp_get_irq_type(dp);
-   switch (irq_type) {
-   case DP_IRQ_TYPE_HP_CABLE_IN:
-   dev_dbg(dp->dev, "Received irq - cable in\n");
-   schedule_work(>hotplug_work);
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   case DP_IRQ_TYPE_HP_CABLE_OUT:
-   dev_dbg(dp->dev, "Received irq - cable out\n");
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   case DP_IRQ_TYPE_HP_CHANGE:
-   /*
-* We get these change notifications once in a while, but there
-* is nothing we can do with them. Just ignore it for now and
-* only handle cable changes.
-*/
-   dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   default:
-   dev_err(dp->dev, "Received irq - unknown type!\n");
-   break;
+   if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+   analogix_dp_mute_hpd_interrupt(dp);
+   ret = IRQ_WAKE_THREAD;
}
-   return IRQ_HANDLED;
+
+   return ret;
 }
 
-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
 {
-   struct analogix_dp_device *dp;
+   struct analogix_dp_device *dp = arg;
+   enum dp_irq_type irq_type;
+
+   irq_type = analogix_dp_get_irq_type(dp);
+   if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+   irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+   dev_dbg(dp->dev, "Detected cable status changed!\n");
+   if (dp->drm_dev)
+   drm_helper_hpd_irq_event(dp->drm_dev);
+   }
 
-   dp = container_of(work, struct analogix_dp_device, hotplug_work);
+   if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+   analogix_dp_clear_hotplug_interrupts(dp);
+   analogix_dp_unmute_hpd_interrupt(dp);
+   }
 
-   if (dp->drm_dev)
-   drm_helper_hpd_irq_event(dp->drm_dev);
+   return IRQ_HANDLED;
 }
 
 static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1077,7 +1070,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
}
 
disable_irq(dp->irq);
-   flush_work(>hotplug_work);
phy_power_off(dp->phy);
 
if (dp->plat_data->power_off)
@@ -1336,8 +1328,6 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
return -ENODEV;
}
 
-   INIT_WORK(>hotplug_work, analogix_dp_hotplug);
-
pm_runtime_enable(dev);
 

[PATCH] ARM: multi_v7_defconfig: Enable fan, sensors and audio for Odroid XU3

2015-12-23 Thread Krzysztof Kozlowski
From: Krzysztof Kozlowski 

For Odroid XU3-family enable the:
 - PWM fan (to control the CPU fan using thermal subsystem),
 - TI INA231 sensors (provide power measurements of big.LITTLE cores,
   DRAM and GPU),
 - Samsung sound (for Odroid XU3 and Snow as well).

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Javier Martinez Canillas 

---

Resending with Javier's tag.
---
 arch/arm/configs/multi_v7_defconfig | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index f6a2557b55df..419f9413402c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -390,7 +390,8 @@ CONFIG_POWER_RESET_RMOBILE=y
 CONFIG_SENSORS_LM90=y
 CONFIG_SENSORS_LM95245=y
 CONFIG_SENSORS_NTC_THERMISTOR=m
-CONFIG_THERMAL=y
+CONFIG_SENSORS_PWM_FAN=m
+CONFIG_SENSORS_INA2XX=m
 CONFIG_CPU_THERMAL=y
 CONFIG_ROCKCHIP_THERMAL=y
 CONFIG_RCAR_THERMAL=y
@@ -521,10 +522,13 @@ CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_PATCH_LOADER=y
 CONFIG_SND_HDA_CODEC_REALTEK=m
 CONFIG_SND_HDA_CODEC_HDMI=m
-CONFIG_SND_USB_AUDIO=y
+CONFIG_SND_USB_AUDIO=m
 CONFIG_SND_SOC=m
 CONFIG_SND_ATMEL_SOC=m
 CONFIG_SND_ATMEL_SOC_WM8904=m
+CONFIG_SND_SOC_SAMSUNG=m
+CONFIG_SND_SOC_SNOW=m
+CONFIG_SND_SOC_ODROIDX2=m
 CONFIG_SND_SOC_SH4_FSI=m
 CONFIG_SND_SOC_RCAR=m
 CONFIG_SND_SOC_RSRC_CARD=m
-- 
2.1.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 3/9] ARM64: EXYNOS: clk: Clock dependency for ARM64 for v4.5

2015-12-23 Thread Krzysztof Kozlowski
W dniu 22.12.2015 o 13:46, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:40AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> Dependency for soc64 changes.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-clk-arm64-symbols-4.5
>>
>> for you to fetch changes up to 8c2a90ed18a74e8b9cdbba679403faa44d6024fc:
>>
>>   clk: samsung: Don't build ARMv8 clock drivers on ARMv7 (2015-11-22 
>> 19:25:29 +0900)
> 
> Hi,
> 
> Looks like this lacks ack from any of the clock maintainers.

It got the ack from Sylwester and Tomasz - Samsung clock maintainers. If
it is not sufficient... then let's wait with it for v4.6. I am on
holidays now so I cannot really do anything meaningful with it.


> 
> Given that EXYNOS_ARM64_COMMON_CLK is not yet introduced, this will cause
> a breakage in bisectability on some of these platforms as well.

The patch introduces EXYNOS_ARM64_COMMON_CLK which will be enabled by
default on our platforms. What kind of breakage do you have in mind?

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 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Tomasz Figa
2015-12-23 19:54 GMT+09:00 Tomasz Figa :
> Hi,
>
> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski :
>> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
 Hi Kukjin,

 Pinctrl for v4.5.

 Best regards,
 Krzysztof


 The following changes since commit 
 8005c49d9aea74d382f474ce11afbbc7d7130bec:

   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

 are available in the git repository at:

   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
 tags/samsung-drivers-4.5

 for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:

   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
 +0900)
>>>
>>> Hi,
>>>
>>> This should either go in through the pinctrl tree, or have an 
>>> acked/reviewed-by
>>> one of the pinctrl maintainers.
>>
>> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
>> https://patchwork.ozlabs.org/patch/450340/
>
> Actually, is there any reason to send this through ARM SoC? Looks like
> this pull request contains only pinctrl changes which could normally
> go through pinctrl tree. Maybe Linus W. could simply pull it?

Except that his email address was mistyped in original message... Fixed now.

Best regards,
Tomasz
--
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 6/9] ARM: EXYNOS: clk: Another clock dependency, ARMv7, for v4.5

2015-12-23 Thread Krzysztof Kozlowski
W dniu 22.12.2015 o 13:51, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:43AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> This is also clock dependency. I put it in separate tag in case clock
>> folks want to pull it also.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-clk-exynos4-4.5
>>
>> for you to fetch changes up to 94af7a3c310f5877dc6f756179b92f24f89a9b08:
>>
>>   clk: samsung: exynos4: Add SSS gate clock (2015-11-18 22:02:02 +0900)
> 
> Again, this should probably go through the clk maintainer (or have an ack).
> It's just two one-line changes though, so if they're slow to respond we can
> take it as a fallback. Resend if that's the case.
> 

Wait, I am missing something. This contains only one patch which has the
Stephen's Boyd ack:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/379230.html
(this is in commit message already)

What kind of ack do you expect here? Ack for pull-request?

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 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Krzysztof Kozlowski
W dniu 23.12.2015 o 19:54, Tomasz Figa pisze:
> Hi,
> 
> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski :
>> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
 Hi Kukjin,

 Pinctrl for v4.5.

 Best regards,
 Krzysztof


 The following changes since commit 
 8005c49d9aea74d382f474ce11afbbc7d7130bec:

   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

 are available in the git repository at:

   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
 tags/samsung-drivers-4.5

 for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:

   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
 +0900)
>>>
>>> Hi,
>>>
>>> This should either go in through the pinctrl tree, or have an 
>>> acked/reviewed-by
>>> one of the pinctrl maintainers.
>>
>> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
>> https://patchwork.ozlabs.org/patch/450340/
> 
> Actually, is there any reason to send this through ARM SoC? Looks like
> this pull request contains only pinctrl changes which could normally
> go through pinctrl tree. Maybe Linus W. could simply pull it?

Of course, I would be happy with it.

But apparently I am the only one who continuously tracks all of these
patches for Exynos (also for subsystems different than arch/arm/mach*).
Yeah, I could ping everyone for every patch (not mine patch I mean)...
but it is easier just to grab it after acking and send it. I really
don't care about the method, just apply the damned patch ;)

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 v5 5/5] ARM: amba: Properly handle devices with power domains

2015-12-23 Thread Marek Szyprowski
To read pid/cid registers, the probed device need to be properly turned on.
When it is inside a power domain, the bus code should ensure that the
given power domain is enabled before trying to access device's registers.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Ulf Hansson 
---
 drivers/amba/bus.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 643127f..570033b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -60,6 +60,10 @@ static int amba_read_periphid(struct amba_device *dev)
if (!tmp)
return -ENOMEM;
 
+   ret = dev_pm_domain_attach(>dev, true);
+   if (ret == -EPROBE_DEFER)
+   goto err_unmap;
+
ret = amba_get_enable_pclk(dev);
if (ret == 0) {
u32 pid, cid;
@@ -84,6 +88,8 @@ static int amba_read_periphid(struct amba_device *dev)
ret = -ENODEV;
}
 
+   dev_pm_domain_detach(>dev, true);
+err_unmap:
iounmap(tmp);
 
return ret;
-- 
1.9.2

--
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 v5 3/5] driver core: handle -EPROBE_DEFER from bus_type.match()

2015-12-23 Thread Marek Szyprowski
From: Tomeu Vizoso 

Allow implementations of the match() callback in struct bus_type to
return errors and if it's -EPROBE_DEFER then queue the device for
deferred probing.

This is useful to buses such as AMBA in which devices are registered
before their matching information can be retrieved from the HW
(typically because a clock driver hasn't probed yet).

Signed-off-by: Tomeu Vizoso 
[changed if-else code structure, adjusted documentation to match the code,
extended comments]
Signed-off-by: Marek Szyprowski 
Reviewed-by: Ulf Hansson 
---
 Documentation/driver-model/porting.txt |  6 --
 drivers/base/dd.c  | 24 ++--
 include/linux/device.h |  7 +--
 3 files changed, 31 insertions(+), 6 deletions(-)

diff --git a/Documentation/driver-model/porting.txt 
b/Documentation/driver-model/porting.txt
index 92d86f7..453053f 100644
--- a/Documentation/driver-model/porting.txt
+++ b/Documentation/driver-model/porting.txt
@@ -340,8 +340,10 @@ comparison:
 
   int (*match)(struct device * dev, struct device_driver * drv);
 
-match should return '1' if the driver supports the device, and '0'
-otherwise. 
+match should return positive value if the driver supports the device,
+and zero otherwise. It may also return error code (for example
+-EPROBE_DEFER) if determining that given driver supports the device is
+not possible.
 
 When a device is registered, the bus's list of drivers is iterated
 over. bus->match() is called for each one until a match is found. 
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 7399be7..7c3f1f1 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -544,6 +544,7 @@ static int __device_attach_driver(struct device_driver 
*drv, void *_data)
struct device_attach_data *data = _data;
struct device *dev = data->dev;
bool async_allowed;
+   int ret;
 
/*
 * Check if device has already been claimed. This may
@@ -554,8 +555,17 @@ static int __device_attach_driver(struct device_driver 
*drv, void *_data)
if (dev->driver)
return -EBUSY;
 
-   if (!driver_match_device(drv, dev))
+   ret = driver_match_device(drv, dev);
+   if (ret == 0) {
+   /* no match */
return 0;
+   } else if (ret == -EPROBE_DEFER) {
+   dev_dbg(dev, "Device match requests probe deferral\n");
+   driver_deferred_probe_add(dev);
+   } else if (ret < 0) {
+   dev_dbg(dev, "Bus failed to match device: %d", ret);
+   return ret;
+   } /* ret > 0 means positive match */
 
async_allowed = driver_allows_async_probing(drv);
 
@@ -675,6 +685,7 @@ void device_initial_probe(struct device *dev)
 static int __driver_attach(struct device *dev, void *data)
 {
struct device_driver *drv = data;
+   int ret;
 
/*
 * Lock device and try to bind to it. We drop the error
@@ -686,8 +697,17 @@ static int __driver_attach(struct device *dev, void *data)
 * is an error.
 */
 
-   if (!driver_match_device(drv, dev))
+   ret = driver_match_device(drv, dev);
+   if (ret == 0) {
+   /* no match */
return 0;
+   } else if (ret == -EPROBE_DEFER) {
+   dev_dbg(dev, "Device match requests probe deferral\n");
+   driver_deferred_probe_add(dev);
+   } else if (ret < 0) {
+   dev_dbg(dev, "Bus failed to match device: %d", ret);
+   return ret;
+   } /* ret > 0 means positive match */
 
if (dev->parent)/* Needed for USB */
device_lock(dev->parent);
diff --git a/include/linux/device.h b/include/linux/device.h
index f627ba2..75a2cde 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -70,8 +70,11 @@ extern void bus_remove_file(struct bus_type *, struct 
bus_attribute *);
  * @dev_groups:Default attributes of the devices on the bus.
  * @drv_groups: Default attributes of the device drivers on the bus.
  * @match: Called, perhaps multiple times, whenever a new device or driver
- * is added for this bus. It should return a nonzero value if the
- * given device can be handled by the given driver.
+ * is added for this bus. It should return a positive value if the
+ * given device can be handled by the given driver and zero
+ * otherwise. It may also return error code if determining that
+ * the driver supports the device is not possible. In case of
+ * -EPROBE_DEFER it will queue the device for deferred probing.
  * @uevent:Called when a device is added, removed, or a few other things
  * that generate uevents to add the environment variables.
  * @probe: Called when a new device or driver add to this bus, and callback
-- 

Re: [GIT PULL 4/9] ARM64: EXYNOS: Soc specific code for v4.5

2015-12-23 Thread Krzysztof Kozlowski
W dniu 22.12.2015 o 13:49, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:41AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> ARM64 change touch also defconfig.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-soc64-4.5
>>
>> for you to fetch changes up to db44c07a3f0b32815bd1f3e731db9e043e57cf9c:
>>
>>   arm64: EXYNOS: Consolidate ARCH_EXYNOS7 symbol into ARCH_EXYNOS 
>> (2015-11-22 19:31:30 +0900)
> 
> Given that Arnd started splitting out config64 separately, there's a small
> chance we'll get a conflict here. We can deal with that if needed though.
> 
> Still, since this branch contains the previous clock branch I can't apply it
> as it is. Can you respin without that for now?

This depends on the clock change because:
1. Clock change removes last usage of ARCH_EXYNOS7,
2. This patch removes the ARCH_EXYNOS7 itself.

So if #1 has to wait, then skip this as well.

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 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Krzysztof Kozlowski
W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> Pinctrl for v4.5.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-drivers-4.5
>>
>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>
>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>> +0900)
> 
> Hi,
> 
> This should either go in through the pinctrl tree, or have an 
> acked/reviewed-by
> one of the pinctrl maintainers.

It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
https://patchwork.ozlabs.org/patch/450340/

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 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Tomasz Figa
Hi,

2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski :
> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
>> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>>> Hi Kukjin,
>>>
>>> Pinctrl for v4.5.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>>
>>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>>> tags/samsung-drivers-4.5
>>>
>>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>>
>>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>>> +0900)
>>
>> Hi,
>>
>> This should either go in through the pinctrl tree, or have an 
>> acked/reviewed-by
>> one of the pinctrl maintainers.
>
> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
> https://patchwork.ozlabs.org/patch/450340/

Actually, is there any reason to send this through ARM SoC? Looks like
this pull request contains only pinctrl changes which could normally
go through pinctrl tree. Maybe Linus W. could simply pull it?

Best regards,
Tomasz
--
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 v5 1/5] drivers: nvdimm: ensure no negative value gets returned on positive match

2015-12-23 Thread Marek Szyprowski
From: Dan Williams 

This patch ensures that existing bus match callbacks don't return
negative values (which might be interpreted as potential errors in the
future) in case of positive match.

Signed-off-by: Dan Williams 
Signed-off-by: Marek Szyprowski 
---
 drivers/nvdimm/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c
index 7e2c43f..2b2181c 100644
--- a/drivers/nvdimm/bus.c
+++ b/drivers/nvdimm/bus.c
@@ -62,7 +62,7 @@ static int nvdimm_bus_match(struct device *dev, struct 
device_driver *drv)
 {
struct nd_device_driver *nd_drv = to_nd_device_driver(drv);
 
-   return test_bit(to_nd_device_type(dev), _drv->type);
+   return !!test_bit(to_nd_device_type(dev), _drv->type);
 }
 
 static struct module *to_bus_provider(struct device *dev)
-- 
1.9.2

--
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 v5 2/5] ARM: sa1111: ensure no negative value gets returned on positive match

2015-12-23 Thread Marek Szyprowski
This patch ensures that existing bus match callbacks don't return
negative values (which might be interpreted as potential errors in the
future) in case of positive match.

Signed-off-by: Marek Szyprowski 
---
 arch/arm/common/sa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 3d22494..fb0a0a4 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -1290,7 +1290,7 @@ static int sa_match(struct device *_dev, struct 
device_driver *_drv)
struct sa_dev *dev = SA_DEV(_dev);
struct sa_driver *drv = SA_DRV(_drv);
 
-   return dev->devid & drv->devid;
+   return !!(dev->devid & drv->devid);
 }
 
 static int sa_bus_suspend(struct device *dev, pm_message_t state)
-- 
1.9.2

--
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 v5 2/5] ARM: sa1111: ensure no negative value gets returned on positive match

2015-12-23 Thread Russell King - ARM Linux
On Wed, Dec 23, 2015 at 11:59:25AM +0100, Marek Szyprowski wrote:
> This patch ensures that existing bus match callbacks don't return
> negative values (which might be interpreted as potential errors in the
> future) in case of positive match.

This actually can't return a negative number - only valid devid bits
are 0 to 9 inclusive, and this isn't going to ever change.  So the
patch isn't strictly necessary, but is good from the point of view
of ensuring consistency.  Hence:

> Signed-off-by: Marek Szyprowski 

Acked-by: Russell King 

> ---
>  arch/arm/common/sa.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
> index 3d22494..fb0a0a4 100644
> --- a/arch/arm/common/sa.c
> +++ b/arch/arm/common/sa.c
> @@ -1290,7 +1290,7 @@ static int sa_match(struct device *_dev, struct 
> device_driver *_drv)
>   struct sa_dev *dev = SA_DEV(_dev);
>   struct sa_driver *drv = SA_DRV(_drv);
>  
> - return dev->devid & drv->devid;
> + return !!(dev->devid & drv->devid);
>  }
>  
>  static int sa_bus_suspend(struct device *dev, pm_message_t state)
> -- 
> 1.9.2
> 

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 7/9] ARM: EXYNOS: dts: DeviceTree for v4.5

2015-12-23 Thread Krzysztof Kozlowski
W dniu 22.12.2015 o 13:52, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:44AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> A lot of stuff here, mostly cleanups. Description in tag.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-dt-4.5
>>
>> for you to fetch changes up to 2cf107f1033e0343d45b59d06f16487c8362702f:
>>
>>   ARM: dts: Unify G2D device node with other devices on exynos4 (2015-11-30 
>> 17:00:43 +0900)
>>
>> 
>> Samsung DeviceTree updates and improvements for 4.5:
>> 1. Pinctrl for Exynos5410.
>> 2. eMMC/SDIO minor fixes usage of bindings on Snow and Peach
>>Chromebooks.
>> 3. Remove FIMD from Odroid XU3-family because on XU3 it cannot be used
>>yet and on XU3-Lite and XU4 it is not supported.
>> 4. Remove deprecated since June 2013 samsung,exynos5-hdmi.
>> 5. Add support for Pseudo Random Generator on Exynos4 (Trats2 for now).
>>This depends on new SSS clock.
>> 6. Add rotator nodes for Exynos4 and Exynos5.
>> 7. Switch DWC3_1 on Odroid XU3 and XU3-Lite to peripheral mode because
>>now it cannot be used as OTG.
>> 8. Cleanup the G2D usage on Exynos4 and add it to a proper domain
>>in case of Exynos4210.
>> 9. Put MDMA1 in proper domain on Exynos4210 as well.
>> 10. Minor cleanups.
> 
> Given the request to get acks for the pinctrl changes, can you respin this
> branch without those pieces so we can merge in the rest of it?
> 
The pinctrl changes here are only DTS changes. I reviewed the pinctrl
DTSI. Why do you want an additional ack for them?

However this contains the previous clock dependency (the SSS clock acked
by Stephen Boyd). I responded about this already so let's don't
duplicate the discussion.

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 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Tomasz Figa
2015-12-23 19:58 GMT+09:00 Krzysztof Kozlowski :
> W dniu 23.12.2015 o 19:54, Tomasz Figa pisze:
>> Hi,
>>
>> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski :
>>> W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
 On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
> Hi Kukjin,
>
> Pinctrl for v4.5.
>
> Best regards,
> Krzysztof
>
>
> The following changes since commit 
> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-drivers-4.5
>
> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>
>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
> +0900)

 Hi,

 This should either go in through the pinctrl tree, or have an 
 acked/reviewed-by
 one of the pinctrl maintainers.
>>>
>>> It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
>>> https://patchwork.ozlabs.org/patch/450340/
>>
>> Actually, is there any reason to send this through ARM SoC? Looks like
>> this pull request contains only pinctrl changes which could normally
>> go through pinctrl tree. Maybe Linus W. could simply pull it?
>
> Of course, I would be happy with it.
>
> But apparently I am the only one who continuously tracks all of these
> patches for Exynos (also for subsystems different than arch/arm/mach*).
> Yeah, I could ping everyone for every patch (not mine patch I mean)...
> but it is easier just to grab it after acking and send it. I really
> don't care about the method, just apply the damned patch ;)

My intention was by no means to belittle your effort, really thanks
for doing this. :)

I was just wondering if Linus couldn't pull this just as is, without
causing further commotion and unnecessarily introducing field for
potential conflicts between trees.

Best regards,
Tomasz
--
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 5/9] ARM: EXYNOS: Drivers for v4.5

2015-12-23 Thread Krzysztof Kozlowski
W dniu 23.12.2015 o 20:06, Tomasz Figa pisze:
> 2015-12-23 19:58 GMT+09:00 Krzysztof Kozlowski :
>> W dniu 23.12.2015 o 19:54, Tomasz Figa pisze:
>>> Hi,
>>>
>>> 2015-12-23 19:51 GMT+09:00 Krzysztof Kozlowski :
 W dniu 22.12.2015 o 13:50, Olof Johansson pisze:
> On Wed, Dec 02, 2015 at 10:39:42AM +0900, Krzysztof Kozlowski wrote:
>> Hi Kukjin,
>>
>> Pinctrl for v4.5.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 
>> 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>>
>>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>>
>> are available in the git repository at:
>>
>>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
>> tags/samsung-drivers-4.5
>>
>> for you to fetch changes up to 023e06dfa6882f500b9c86fd61f0b1913aa07f36:
>>
>>   pinctrl: exynos: add exynos5410 SoC specific data (2015-11-16 10:54:43 
>> +0900)
>
> Hi,
>
> This should either go in through the pinctrl tree, or have an 
> acked/reviewed-by
> one of the pinctrl maintainers.

 It was acked by Tomasz Figa - Samsung Pin Controller maintainer:
 https://patchwork.ozlabs.org/patch/450340/
>>>
>>> Actually, is there any reason to send this through ARM SoC? Looks like
>>> this pull request contains only pinctrl changes which could normally
>>> go through pinctrl tree. Maybe Linus W. could simply pull it?
>>
>> Of course, I would be happy with it.
>>
>> But apparently I am the only one who continuously tracks all of these
>> patches for Exynos (also for subsystems different than arch/arm/mach*).
>> Yeah, I could ping everyone for every patch (not mine patch I mean)...
>> but it is easier just to grab it after acking and send it. I really
>> don't care about the method, just apply the damned patch ;)
> 
> My intention was by no means to belittle your effort, really thanks
> for doing this. :)
> 
> I was just wondering if Linus couldn't pull this just as is, without
> causing further commotion and unnecessarily introducing field for
> potential conflicts between trees.

That makes sense. The pinctrl driver change is not a direct dependency
for anything in this pull request so from my side:

Acked-by: Krzysztof Kozlowski 

Linus,
The patch can be cherry-picked from:
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=samsung-drivers-4.5

(the only commit in tag: samsung-drivers-4.5)

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