[PATCH 3/3] clockevents/exynos_mct: Implement ->set_state_oneshot_stopped()
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
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
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
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
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
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
On Thu, Dec 3, 2015 at 5:10 PM, Krzysztof Kozlowskiwrote: > 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
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
Fix some obvious alignment problems, like alignment and line over 80 characters problems, make this easy to be maintained later. Signed-off-by: Yakir YangAcked-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
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 YangReviewed-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
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 YangTested-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
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 YangReviewed-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
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 YangAcked-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
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
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 YangAcked-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
Add phy driver for the Rockchip DisplayPort PHY module. This is required to get DisplayPort working in Rockchip SoCs. Signed-off-by: Yakir YangReviewed-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
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
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 YangTested-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
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 YangAcked-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
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 YangTested-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
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 YangTested-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
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
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
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
From: Krzysztof KozlowskiFor 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
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 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
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
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
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 SzyprowskiReviewed-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()
From: Tomeu VizosoAllow 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
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
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
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
From: Dan WilliamsThis 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
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
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 SzyprowskiAcked-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
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 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
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