Re: [RFC PATCH 02/15] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
Hi Rob,
On Sat, Nov 28, 2015 at 5:30 AM, Rob Herring wrote:
> On Thu, Nov 26, 2015 at 10:47:26PM +0900, Chanwoo Choi wrote:
>> This patch adds the documentation for generic exynos bus frequency
>> driver.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> .../devicetree/bindings/devfreq/exynos-bus.txt | 92
>> ++
>> 1 file changed, 92 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> new file mode 100644
>> index ..5d90623bd173
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -0,0 +1,92 @@
>> +* Generic Exynos Bus frequency device
>> +
>> +The Samsung Exynos SoC have many buses for data transfer between DRAM
>> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture
>> +for buses. Generally, the each bus of Exynos SoC includes the source clock
>> +and power line and then is able to change the clock according to the usage
>> +of each buses on runtime. When gathering the usage of each buses on runtime,
>> +thie driver uses the exynos-ppmu.c driver with DEVFREQ-EVENT framework.
>
> Please don't refer to Linux subsystem specifics in bindings. It looks
> like you are creating devices to match what you have for drivers, not
> what the h/w looks like.
OK. I'll modify it on next patchiest.
>
>
>> +There are a little different composition among Exynos SoC because each
>> Exynos
>> +SoC has the different sub-blocks. So, this difference should be specified
>> +in devicetree file instead of each device driver. In result, this driver
>> +is able to support the bus frequency for all Exynos SoCs.
>> +
>> +Required properties for bus device:
>> +- compatible: Should be "samsung,exynos-bus".
>> +- clock-names : the name of clock used by the bus, "bus".
>> +- clocks : phandles for clock specified in "clock-names" property.
>> +- #clock-cells: should be 1.
>> +- operating-points-v2: the OPP table including frequency/voltage information
>> + to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
>> +- vdd-supply: the regulator to provide the buses with the voltage.
>> +- devfreq-events: the devfreq-event device to monitor the curret utilization
>> + of buses.
>> +
>> +Optional properties for bus device:
>> +- exynos,saturation-ratio: the percentage value which is used to calibrate
>> + the performance count againt total cycle count.
>> +
>> +Example1:
>> + Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
>> + power line (regulator). The MIF (Memory Interface) AXI bus is used to
>> + transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>> +
>> + - power line(VDD_MIF) --> bus for DMC block (dmc clock)
>> +
>> + - MIF bus's frequency/voltage table
>> + ---
>> + |Lv| Freq | Voltage |
>> + ---
>> + |L1| 5 |80 |
>> + |L2| 10 |80 |
>> + |L3| 133000 |80 |
>> + |L4| 20 |80 |
>> + |L5| 40 |875000 |
>> + ---
>> +
>> +Example2 :
>> + The bus of DMC block in exynos3250.dtsi are listed below:
>
> What is DMC?
DMC (DRAM Memory Controller)
>
>> +
>> + bus_dmc: bus_dmc {
>> + compatible = "samsung,exynos-bus";
>
> I would expect the children of this bus to be under this node.
I add the detailed description on patch9 which is included in this
patch-set as follwoing.
- [RFC PATCH 09/15] PM / devfreq: exynos: Update documentation for bus
devices usingpassive governor
This patch-set don' include the the list of children node in parent dt node.
Instead, I add the separate node and then each children node has the
the phandle of parent node
>
>> + clocks = <&cmu_dmc CLK_DIV_DMC>;
>> + clock-names = "bus";
>> + operating-points-v2 = <&bus_dmc_opp_table>;
>> + status = "disabled";
>> + };
>> +
>> + bus_dmc_opp_table: opp_table0 {
>> + compatible = "operating-points-v2";
>> + opp-shared;
>> +
>> + opp00 {
>> + opp-hz = /bits/ 64 <5000>;
>> + opp-microvolt = <80>;
>> + };
>> + opp01 {
>> + opp-hz = /bits/ 64 <1>;
>> + opp-microvolt = <80>;
>> + };
>> + opp02 {
>> + opp-hz = /bits/ 64 <13300>;
>> + opp-microvolt = <80>;
>> + };
>> + opp03 {
>> + opp-hz = /bits/ 64 <2>;
>> + opp-microvolt = <80>;
>> + };
>> + opp04 {
>> + opp-hz = /bits/ 64 <4>;
>> + opp-microvolt = <875000>;
>> + };
>> + };
>> +
Re: [RFC PATCH 02/15] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
On Thu, Nov 26, 2015 at 10:47:26PM +0900, Chanwoo Choi wrote:
> This patch adds the documentation for generic exynos bus frequency
> driver.
>
> Signed-off-by: Chanwoo Choi
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 92
> ++
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> new file mode 100644
> index ..5d90623bd173
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -0,0 +1,92 @@
> +* Generic Exynos Bus frequency device
> +
> +The Samsung Exynos SoC have many buses for data transfer between DRAM
> +and sub-blocks in SoC. Almost Exynos SoC have the common architecture
> +for buses. Generally, the each bus of Exynos SoC includes the source clock
> +and power line and then is able to change the clock according to the usage
> +of each buses on runtime. When gathering the usage of each buses on runtime,
> +thie driver uses the exynos-ppmu.c driver with DEVFREQ-EVENT framework.
Please don't refer to Linux subsystem specifics in bindings. It looks
like you are creating devices to match what you have for drivers, not
what the h/w looks like.
> +There are a little different composition among Exynos SoC because each Exynos
> +SoC has the different sub-blocks. So, this difference should be specified
> +in devicetree file instead of each device driver. In result, this driver
> +is able to support the bus frequency for all Exynos SoCs.
> +
> +Required properties for bus device:
> +- compatible: Should be "samsung,exynos-bus".
> +- clock-names : the name of clock used by the bus, "bus".
> +- clocks : phandles for clock specified in "clock-names" property.
> +- #clock-cells: should be 1.
> +- operating-points-v2: the OPP table including frequency/voltage information
> + to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +- vdd-supply: the regulator to provide the buses with the voltage.
> +- devfreq-events: the devfreq-event device to monitor the curret utilization
> + of buses.
> +
> +Optional properties for bus device:
> +- exynos,saturation-ratio: the percentage value which is used to calibrate
> + the performance count againt total cycle count.
> +
> +Example1:
> + Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
> + power line (regulator). The MIF (Memory Interface) AXI bus is used to
> + transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
> +
> + - power line(VDD_MIF) --> bus for DMC block (dmc clock)
> +
> + - MIF bus's frequency/voltage table
> + ---
> + |Lv| Freq | Voltage |
> + ---
> + |L1| 5 |80 |
> + |L2| 10 |80 |
> + |L3| 133000 |80 |
> + |L4| 20 |80 |
> + |L5| 40 |875000 |
> + ---
> +
> +Example2 :
> + The bus of DMC block in exynos3250.dtsi are listed below:
What is DMC?
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
I would expect the children of this bus to be under this node.
> + clocks = <&cmu_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13300>;
> + opp-microvolt = <80>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <875000>;
> + };
> + };
> +
> + Usage case to handle the frequency and voltage of bus on runtime
> + in exynos3250-rinato.dts are listed below:
> +
> + &bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
What do these phandles point to exactly?
> + vdd-supply = <&buck1_reg>; /* VDD_MIF */
> + status = "okay";
> + };
> --
> 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] drm/exynos: simplify sleep PM ops
PM ops in exynos_drm_drv were split into two separate function as they were
used also by drm device. Since PM ops have been removed from drm device, the
functions can be merged together.
Signed-off-by: Andrzej Hajda
---
Hi Inki,
This is the patch I have promised during our discussion about
PM callbcks in components.
Regards
Andrzej
drivers/gpu/drm/exynos/exynos_drm_drv.c | 76 +
1 file changed, 30 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2c6019d..9756797a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -304,45 +304,6 @@ int exynos_atomic_commit(struct drm_device *dev, struct
drm_atomic_state *state,
return 0;
}
-#ifdef CONFIG_PM_SLEEP
-static int exynos_drm_suspend(struct drm_device *dev, pm_message_t state)
-{
- struct drm_connector *connector;
-
- drm_modeset_lock_all(dev);
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- int old_dpms = connector->dpms;
-
- if (connector->funcs->dpms)
- connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
-
- /* Set the old mode back to the connector for resume */
- connector->dpms = old_dpms;
- }
- drm_modeset_unlock_all(dev);
-
- return 0;
-}
-
-static int exynos_drm_resume(struct drm_device *dev)
-{
- struct drm_connector *connector;
-
- drm_modeset_lock_all(dev);
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->funcs->dpms) {
- int dpms = connector->dpms;
-
- connector->dpms = DRM_MODE_DPMS_OFF;
- connector->funcs->dpms(connector, dpms);
- }
- }
- drm_modeset_unlock_all(dev);
-
- return 0;
-}
-#endif
-
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
@@ -476,31 +437,54 @@ static struct drm_driver exynos_drm_driver = {
};
#ifdef CONFIG_PM_SLEEP
-static int exynos_drm_sys_suspend(struct device *dev)
+static int exynos_drm_suspend(struct device *dev)
{
struct drm_device *drm_dev = dev_get_drvdata(dev);
- pm_message_t message;
+ struct drm_connector *connector;
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
- message.event = PM_EVENT_SUSPEND;
- return exynos_drm_suspend(drm_dev, message);
+ drm_modeset_lock_all(drm_dev);
+ drm_for_each_connector(connector, drm_dev) {
+ int old_dpms = connector->dpms;
+
+ if (connector->funcs->dpms)
+ connector->funcs->dpms(connector, DRM_MODE_DPMS_OFF);
+
+ /* Set the old mode back to the connector for resume */
+ connector->dpms = old_dpms;
+ }
+ drm_modeset_unlock_all(drm_dev);
+
+ return 0;
}
-static int exynos_drm_sys_resume(struct device *dev)
+static int exynos_drm_resume(struct device *dev)
{
struct drm_device *drm_dev = dev_get_drvdata(dev);
+ struct drm_connector *connector;
if (pm_runtime_suspended(dev) || !drm_dev)
return 0;
- return exynos_drm_resume(drm_dev);
+ drm_modeset_lock_all(drm_dev);
+ drm_for_each_connector(connector, drm_dev) {
+ if (connector->funcs->dpms) {
+ int dpms = connector->dpms;
+
+ connector->dpms = DRM_MODE_DPMS_OFF;
+ connector->funcs->dpms(connector, dpms);
+ }
+ }
+ drm_modeset_unlock_all(drm_dev);
+
+ return 0;
}
#endif
static const struct dev_pm_ops exynos_drm_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_sys_suspend, exynos_drm_sys_resume)
+ SET_SYSTEM_SLEEP_PM_OPS(exynos_drm_suspend, exynos_drm_resume)
};
/* forward declaration */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/13] drm/exynos: async G2D and g2d_move()
On 27 November 2015 at 02:11, Hyungwon Hwang wrote: > Dear All, > > On Thu, 26 Nov 2015 16:35:29 + > Emil Velikov wrote: > >> Hi Tobias, >> >> On 22 November 2015 at 18:48, Tobias Jakobi >> wrote: >> > Hello, >> > >> > this series mostly touches G2D code. It introduces the following: >> > >> > (1) drmHandleEvent2() is added to enable processing of >> > vendor-specific events. This will be used to expose asynchronous >> > operation of the G2D. The necessary kernel infrastructure is >> > already there since a lot of kernel versions. [This touches libdrm >> > core code!] >> > >> Considering the shortage of input on this can you please respin the >> series without it (and related work mentioned below). This way we can >> pick merge the remaining work now and discuss (ping) about the rest. > > I am confused a little here. Did you mean that adding drmHandleEvent2() > is not necessary, and the related code which uses drmHandleEvent2() must > be re-implemented? > I mean that there has been no interest/collaboration from anyone else. The shortage of userspace, doesn't help much either. Both of these can be hand-waved, somewhat, if this was exynos only change, but it isn't :-( Thus in order to not stall the remaining patches, I'm suggesting that we split this [and other patches that depend on it] into a separate/parallel series. >> >> > (2) The necessary infrastructure to handle G2D events. This includes >> > adding g2d_config_event() and g2d_exec2() to the public API. >> > A test application is provided to ensure that everything works >> > as expected. >> > >> With above in mind the g2d event will need to be split out, although >> g2d_exec2() should be ok (although of limited use), imho. >> >> > (3) A small performance test application which can be used to >> > measure the speed of solid color clear operations. Interesting for >> > benchmarking and plotting colorful graphs (e.g. through >> > Mathematica). >> > >> > (4) g2d_move() which works similar to g2d_copy() but like the C >> > memmove() properly handles overlapping buffer copies. >> > Again a test application is present to check that this >> > indeed does what it should. >> > >> > (5) Various small changes. A framebuffer colorformat fix for the >> > general G2D test application. Moving the currently unused >> > g2d_reset() to the public API. >> I am more of a "add API when it's needed" kind of person, although I >> cannot see anything serious misuse that can arise from g2d_reset(). >> >> > Adding a counterpart to >> > exynos_bo_map() to unmap buffers again. >> > >> The exynos bo map compatibility was broken a few times already so I'm >> wondering if we really want this one. I guess that with the lack of >> any (outside of tizen) user space things cannot go that wrong :-P >> > > Yes. I agree that adding them at this time is not needed and it would > be OK to add them, when the userspace using them comes. > You guys/gals are paving the way for exynos - so it's not my call to decide. I was just pointing out some questionable bits from the past. As I mentioned Tizen, do you plan on cleaning up your libdrm (and other?) patches and sending them over ? In case I haven't mentioned this before - feel free to come and join us on IRC channel #dri-devel (at FreeNode). Many kernel and userspace DRM developers hang out in there and you can poke, collaborate and discuss things in real time :-) This invite includes youself, other exynos DRM developers and everyone else interested. Thanks for the picking up Tobias' work, Hyungwon! Regards Emil -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 14/17] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288
Am Mittwoch, 28. Oktober 2015, 16:56:01 schrieb Yakir Yang:
> There are some IP limit on rk3288 that only support 4 physical lanes
> of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
>
> Tested-by: Javier Martinez Canillas
> Signed-off-by: Yakir Yang
> ---
[...]
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c index
> 6307060..563ffb1d 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device
> *dp) return;
> }
>
> - ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
> - dp->video_info.link_rate);
> + ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
> + dp->video_info.max_link_rate);
> if (ret) {
> dev_err(dp->dev, "unable to do link train\n");
> return;
> @@ -1156,16 +1156,25 @@ static int analogix_dp_dt_parse_pdata(struct
> analogix_dp_device *dp) struct device_node *dp_node = dp->dev->of_node;
> struct video_info *video_info = &dp->video_info;
>
> - if (of_property_read_u32(dp_node, "samsung,link-rate",
> - &video_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",
> - &video_info->lane_count)) {
> - dev_err(dp->dev, "failed to get lane-count\n");
> - return -EINVAL;
> + switch (dp->plat_data && dp->plat_data->dev_type) {
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c: In function
‘analogix_dp_dt_parse_pdata’:
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c:1191:10: warning: switch
condition has boolean value [-Wswitch-bool]
switch (dp->plat_data && dp->plat_data->dev_type) {
^
As I think we always will need to distinguish between implementations,
I guess it should be safe to exit with an error, it that implementation-data
is not available, like just doing before the switch a:
if (!dp->plat_data)
return -EINVAL;
Heiko
--
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] drm/exynos: atomic check only enabled crtc states
Hello Andrzej, On 11/27/2015 03:57 AM, Andrzej Hajda wrote: > Since atomic check is called also for disabled crtcs it should skip > mode checking as it can be uninitialized. The patch fixes it. > > Signed-off-by: Andrzej Hajda > Suggested-by: Daniel Vetter > --- > Hi Javier, > > Could you check with this patch. > The patch fixes the issue I reported. The display mode is correctly set with and without a HDMI monitor plugged. So on an Exynos5800 Peach Pi: Tested-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 08/17] drm: rockchip: dp: add rockchip platform dp driver
Hi Yakir, Am Mittwoch, 28. Oktober 2015, 16:27:45 schrieb Yakir Yang: > Rockchip have three clocks for dp controller, we leave pclk_edp > to analogix_dp driver control, and keep the sclk_edp_24m and > sclk_edp in platform driver. > > Tested-by: Javier Martinez Canillas > Signed-off-by: Yakir Yang > --- > diff --git a/drivers/gpu/drm/rockchip/Kconfig > b/drivers/gpu/drm/rockchip/Kconfig index 35215f6..c2ba945 100644 > --- a/drivers/gpu/drm/rockchip/Kconfig > +++ b/drivers/gpu/drm/rockchip/Kconfig > @@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI > for the Synopsys DesignWare HDMI driver. If you want to > enable HDMI on RK3288 based SoC, you should selet this > option. > + > +config ROCKCHIP_ANALOGIX_DP > +tristate "Rockchip specific extensions for Analogix DP driver" > +depends on DRM_ROCKCHIP > +select DRM_ANALOGIX_DP > +help the indentation should probably be tabs here, ROCKCHIP_DW_HDMI also does it wrong it seems, but DRM_ROCKCHIP looks correct :-) Heiko -- 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
