Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hi Javier,
2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
>
> I found that v2 of this patch is alredy in your exynos-drm for-next branch so
> so I had to revert it in linux-next to apply this one to test. You shouldn't
> push patches that were still not reviewed (specially the ones that weren't
> tested like this one) to your branch that gets pulled by -next. The idea of
> -next is to have some test coverage but it should be as stable as possible.
exynos-drm/for-next branch is not really for-next branch. This branch is used
only for integration test. As you know, there are many exynos maintainers
and they have their own repository. So we would need to test the integration.
For this, exynos-drm/for-next is merged to linux-next not Dave's tree.
Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and
tested patches will be merged to exynos-drm-next.
>
> On 12/03/2015 06:30 AM, Inki Dae wrote:
>> This patch adds of_graph dt binding support for panel device
>> and also keeps the backward compatibility.
>>
>> i.e.,
>> The dts file for Exynos5800 based peach pi board
>> has a panel property so we need to keep the backward compatibility.
>>
>> Changelog v3:
>> - bind only one of two nodes outbound - panel or bridge.
>>
>
> This patch fixes one of the comments I had for v2 but I've another
> comment below.
>
>> Changelog v2:
>> - return -EINVAL if getting a port node failed.
>>
>> Signed-off-by: Inki Dae
>> ---
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 21 -
>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 94f02a0..60260a0 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
>> static int exynos_dp_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> -struct device_node *panel_node, *bridge_node, *endpoint;
>> +struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
>> struct exynos_dp_device *dp;
>> int ret;
>>
>> @@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device
>> *pdev)
>>
>> platform_set_drvdata(pdev, dp);
>>
>> +/* This is for the backward compatibility. */
>> panel_node = of_parse_phandle(dev->of_node, "panel", 0);
>> if (panel_node) {
>> dp->panel = of_drm_find_panel(panel_node);
>> of_node_put(panel_node);
>> if (!dp->panel)
>> return -EPROBE_DEFER;
>> +} else {
>> +endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>> +if (endpoint) {
>> +panel_node = of_graph_get_remote_port_parent(endpoint);
>
> Here is asssumed that the endpoint will be a panel but it could be that there
> is no "panel" phandle but the port is for a bridge chip (i.e: Peach Pit) so
> this assumption seems fragile to me.
>
> That's what I meant when I said "Assuming you can make a distinction if the
> endpoint is a panel or a bridge" in the other thread.
>
>> +if (panel_node) {
>> +dp->panel = of_drm_find_panel(panel_node);
>> +of_node_put(panel_node);
>> +if (!dp->panel)
>> +return -EPROBE_DEFER;
>> +} else {
>> +DRM_ERROR("no port node for panel device.\n");
>> +return -EINVAL;
>> +}
>> +}
>> }
>>
>> +if (endpoint)
>> +goto out;
>> +
>
> Ok, so IIUC what's done here is to test if the panel lookup failed, then the
> endpoint is looked up again but this time a call to of_drm_find_bridge() is
> made instead of a call to of_drm_find_panel(). I wonder if there is a better
> way to do this...
>
> In any case then I think you should test if (panel_node) instead of endpoint.
>
>> endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
>> if (endpoint) {
>> bridge_node = of_graph_get_remote_port_parent(endpoint);
>> @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device
>> *pdev)
>> return -EPROBE_DEFER;
>> }
>>
>> +out:
>> pm_runtime_enable(dev);
>>
>> ret = component_add(&pdev->dev, &exynos_dp_ops);
>>
>
> I can't think of a better way to lookup either a panel or a bridge though
> and I'm not that familiar with DRM so with the correct check, the patch
> looks good to me.
>
> Reviewed-by: Javier Martinez Canillas
>
> Also on an Exynos5800 Peach Pi with the DTS patch I shared, the display
> is working correctly and also I tested without the DTS patch to make
> sure that it does not cause a regression for older DTBs.
>
> Tested-by: Javier M
Re: [PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel
Hi Javier,
2015년 12월 03일 22:29에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
>
> On 12/03/2015 06:30 AM, Inki Dae wrote:
>> This patch updates a ports node binding for panel.
>>
>> With this, dp node can have a ports node which describes
>> a remote endpoint node that can be connected to panel or bridge
>> node.
>>
>> Signed-off-by: Inki Dae
>> ---
>> .../bindings/display/exynos/exynos_dp.txt | 28
>> ++
>> 1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> index 64693f2..15b52cb 100644
>> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>> Hotplug detect GPIO.
>> Indicates which GPIO should be used for hotplug
>> detection
>> --video interfaces: Device node can contain video interface port
>> -nodes according to [1].
>> +Video interfaces:
>> + Device node can contain video interface port nodes according to [1].
>> + The following are properties specific to those nodes:
>> +
>> + endpoint node connected to bridge or panel node:
>> + - remote-endpoint: specifies the endpoint in panel or bridge node.
>> + This node is required in all kinds of exynos dp
>> + to represent the connection between dp and bridge
>> + ,or dp and panel.
>>
>
> This is nice but I think the DT binding should also document that it uses
> a phandle to define the connection with the panel (but explain that is
> deprecated). If only so people looking at a DTS and then going to the DT
> binding can understand why there is two ways to define the same.
>
>> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>
>> @@ -111,9 +118,22 @@ Board Specific portion:
>> };
>>
>> ports {
>> -port@0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>
> These two properties are only needed when there is more than 2 ports and
> a reg property is used to number the port nodes but I don't think that's
> the case for Exynos DP and certainly is not the case in this example so
> I think you should just remove them.
Right. I found out that the dp can have only one port outbound. Will remove
them.
>
>> +port {
>> dp_out: endpoint {
>> -remote-endpoint = <&bridge_in>;
>> +remote-endpoint = <&dp_in>;
>> +};
>> +};
>> +};
>> +
>> +panel@0 {
>> +reg = <0>;
>> +...
>> +port {
>> +dp_in: endpoint {
>> +remote-endpoint = <&dp_out>;
>> };
>> };
>> };
>>
>
> The rest looks good to me so with the two changes feel free to add:
>
> Reviewed-by: Javier Martinez Canillas
Thanks,
Inki Dae
>
> Best regards,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel
Hi Rob,
2015년 12월 04일 08:38에 Rob Herring 이(가) 쓴 글:
> On Thu, Dec 03, 2015 at 06:30:10PM +0900, Inki Dae wrote:
>> This patch updates a ports node binding for panel.
>>
>> With this, dp node can have a ports node which describes
>> a remote endpoint node that can be connected to panel or bridge
>> node.
>>
>> Signed-off-by: Inki Dae
>> ---
>> .../bindings/display/exynos/exynos_dp.txt | 28
>> ++
>> 1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> index 64693f2..15b52cb 100644
>> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
>> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
>> Hotplug detect GPIO.
>> Indicates which GPIO should be used for hotplug
>> detection
>> --video interfaces: Device node can contain video interface port
>> -nodes according to [1].
>> +Video interfaces:
>> + Device node can contain video interface port nodes according to [1].
>> + The following are properties specific to those nodes:
>> +
>> + endpoint node connected to bridge or panel node:
>> + - remote-endpoint: specifies the endpoint in panel or bridge node.
>> + This node is required in all kinds of exynos dp
>> + to represent the connection between dp and bridge
>> + ,or dp and panel.
>
> Fix your punctuation.
Right.
>
>>
>> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>
>> @@ -111,9 +118,22 @@ Board Specific portion:
>> };
>>
>> ports {
>> -port@0 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>
> You don't need these.
Ditto.
>
>> +
>> +port {
>> dp_out: endpoint {
>> -remote-endpoint = <&bridge_in>;
>> +remote-endpoint = <&dp_in>;
>> +};
>> +};
>> +};
>> +
>> +panel@0 {
>> +reg = <0>;
>
> Drop the @0 and reg as you only have 1.
Ditto.
Thanks,
Inki Dae
>
>> +...
>> +port {
>> +dp_in: endpoint {
>> +remote-endpoint = <&dp_out>;
>> };
>> };
>> };
>> --
>> 1.9.1
>>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
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 Fri, Dec 04, 2015 at 10:10:03AM +0900, Krzysztof Kozlowski wrote: > Bindings for Samsung S2M and S5M family PMICs are in mess. They are > spread over different files and subdirectories in a non-consistent way. > The devices and respective drivers for them share a lot in common so > everything could be organized in a more readable way. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH 2/3] dt-bindings: regulator/mfd: Reorganize S5M8767 bindings
On Fri, Dec 04, 2015 at 10:10:04AM +0900, Krzysztof Kozlowski wrote: > The regulator/s5m8767-regulator.txt duplicates some of the information > about bindings with old mfd/s2mps11.txt. Now common part exists entirely > in mfd/samsung,sec-core.txt so: Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH 3/3] dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings
On Fri, Dec 04, 2015 at 10:10:05AM +0900, Krzysztof Kozlowski wrote: > The mfd/s2mpa01.txt duplicates some of the information about bindings > with old mfd/s2mps11.txt. Now common part exists entirely in > mfd/samsung,sec-core.txt so: Acked-by: Mark Brown > - add company prefix to file name (regulator/samsung,s2mpa01.txt), I'm not 100% convinced about these prefixes BTW, the duplication isn't usually an issue within a subsystem. They don't do any harm either though. signature.asc Description: PGP signature
Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hello Inki, On 12/04/2015 06:00 AM, Inki Dae wrote: > Hi Javier, > > 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글: >> Hello Inki, >> >> I found that v2 of this patch is alredy in your exynos-drm for-next branch so >> so I had to revert it in linux-next to apply this one to test. You shouldn't >> push patches that were still not reviewed (specially the ones that weren't >> tested like this one) to your branch that gets pulled by -next. The idea of >> -next is to have some test coverage but it should be as stable as possible. > > exynos-drm/for-next branch is not really for-next branch. This branch is used Well, it is a for-next branch because is pulled by -next. It is listed in: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees drm-exynos git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next > only for integration test. As you know, there are many exynos maintainers > and they have their own repository. So we would need to test the integration. Integration testing is of course very needed and linux-next is for that but what should be tested are the patches that are targeted to mainline. > For this, exynos-drm/for-next is merged to linux-next not Dave's tree. > Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and > tested patches will be merged to exynos-drm-next. > In that case, exynos-drm-next is what should be pulled by linux-next, no the for-next branch. Linux-next is a simulation of what Torvalds would do next so problems are found earlier, ideally before the patches land into mainline. 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 v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hi Javier, 2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas : > Hello Inki, > > On 12/04/2015 06:00 AM, Inki Dae wrote: >> Hi Javier, >> >> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글: >>> Hello Inki, >>> >>> I found that v2 of this patch is alredy in your exynos-drm for-next branch >>> so >>> so I had to revert it in linux-next to apply this one to test. You shouldn't >>> push patches that were still not reviewed (specially the ones that weren't >>> tested like this one) to your branch that gets pulled by -next. The idea of >>> -next is to have some test coverage but it should be as stable as possible. >> >> exynos-drm/for-next branch is not really for-next branch. This branch is used > > Well, it is a for-next branch because is pulled by -next. It is listed in: > http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees > > drm-exynos git > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next > >> only for integration test. As you know, there are many exynos maintainers >> and they have their own repository. So we would need to test the integration. > > Integration testing is of course very needed and linux-next is for that but > what should be tested are the patches that are targeted to mainline. > >> For this, exynos-drm/for-next is merged to linux-next not Dave's tree. >> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed >> and >> tested patches will be merged to exynos-drm-next. >> > > In that case, exynos-drm-next is what should be pulled by linux-next, no the > for-next branch. Linux-next is a simulation of what Torvalds would do next > so problems are found earlier, ideally before the patches land into mainline. Seems I didn't comment enough. exynos-drm/for-next branch includes all patches of exynos-drm-next and actually, they keep same patches for most time but sometimes, I merge additional patches only to exynos-drm/for-next, which should be more tested with other trees before going to Dave's tree. One more thing, there is other difference between exynos-drm-next and exynos-drm/for-next. That is all patches of exynos-drm-next are merged on top of based on Dave's drm-next branch. On the other hand, all of exynos-drm/for-next are merged on top of mainline. So if exynos-drm-next is merged to linux-next then all patches will be conflicted with Dave's tree because his branch is also merged to linux-next. I'm not sure that other maintainers always keep only the for-next branch in their repository but in my case, I use exynos-drm/for-next branch for the test before going to drm-next. Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree will also be pulled by linux-next, which would allow exynos-drm-next to be tested altogether again before going to mainline. Thanks, Inki Dae > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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 Fri, Dec 04, 2015 at 10:10:03AM +0900, Krzysztof Kozlowski wrote:
> Bindings for Samsung S2M and S5M family PMICs are in mess. They are
> spread over different files and subdirectories in a non-consistent way.
> The devices and respective drivers for them share a lot in common so
> everything could be organized in a more readable way.
>
> Reorganize the S2MPS11/13/14/15 Device Tree bindings to match the
> drivers for this family of devices:
> - move mfd/s2mps11.txt to mfd/samsung,sec-core.txt for the main MFD
>driver (common for entire family),
> - split clock block to clock/samsung,s2mps11.txt,
> - split regulator block to regulator/samsung,s2mps11.txt.
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Rob Herring
> ---
> .../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
> +--
> +32KhzAP 0S2MPS11/13/14/15, S5M8767
> +32KhzCP 1S2MPS11/13/15, S5M8767
> +32KhzBT 2S2MPS11/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: Interrupt specifiers for interrupt sources.
> -- samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of
Re: [PATCH 2/3] dt-bindings: regulator/mfd: Reorganize S5M8767 bindings
On Fri, Dec 04, 2015 at 10:10:04AM +0900, Krzysztof Kozlowski wrote: > The regulator/s5m8767-regulator.txt duplicates some of the information > about bindings with old mfd/s2mps11.txt. Now common part exists entirely > in mfd/samsung,sec-core.txt so: > - add company prefix to file name (regulator/samsung,s5m8767.txt), > - remove duplicated information, > - reorganize the contents to match style of >regulator/samsung,s2mps11.txt. > > Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring > --- > .../devicetree/bindings/mfd/samsung,sec-core.txt | 4 +- > .../bindings/regulator/s5m8767-regulator.txt | 163 > - > .../bindings/regulator/samsung,s5m8767.txt | 145 ++ > MAINTAINERS| 2 +- > 4 files changed, 149 insertions(+), 165 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > create mode 100644 > Documentation/devicetree/bindings/regulator/samsung,s5m8767.txt > > diff --git a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt > b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt > index ef0166d0f643..4aeb95c82304 100644 > --- a/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt > +++ b/Documentation/devicetree/bindings/mfd/samsung,sec-core.txt > @@ -14,6 +14,7 @@ addressed by the host system using different I2C slave > addresses. > This document describes bindings for main device node. Optional sub-blocks > must be a sub-nodes to it. Bindings for them can be found in: > - bindings/regulator/samsung,s2mps11.txt > + - bindings/regulator/samsung,s5m8767.txt > - bindings/clock/samsung,s2mps11.txt > > > @@ -23,7 +24,8 @@ Required properties: > - "samsung,s2mps13-pmic", > - "samsung,s2mps14-pmic", > - "samsung,s2mps15-pmic", > - - "samsung,s2mpu02-pmic". > + - "samsung,s2mpu02-pmic", > + - "samsung,s5m8767-pmic". > - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. > > Optional properties: > diff --git > a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > deleted file mode 100644 > index 20191315e444.. > --- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt > +++ /dev/null > @@ -1,163 +0,0 @@ > -* Samsung S5M8767 Voltage and Current Regulator > - > -The Samsung S5M8767 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 a i2c interface. Each sub-block is > -addressed by the host system using different i2c slave address. This document > -describes the bindings for 'pmic' sub-block of s5m8767. > - > -Required properties: > -- compatible: Should be "samsung,s5m8767-pmic". > -- reg: Specifies the i2c slave address of the pmic block. It should be 0x66. > - > -- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt > (uV) > - units for buck2 when changing voltage using gpio dvs. Refer to [1] below > - for additional information. > - > -- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt > (uV) > - units for buck3 when changing voltage using gpio dvs. Refer to [1] below > - for additional information. > - > -- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt > (uV) > - units for buck4 when changing voltage using gpio dvs. Refer to [1] below > - for additional information. > - > -- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used > - for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines. > - > -[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional > -property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage' > -property should specify atleast one voltage level (which would be a > -safe operating voltage). > - > -If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional > -property is specified, then all the eight voltage values for the > -'s5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified. > - > -Optional properties: > -- interrupt-parent: Specifies the phandle of the interrupt controller to > which > - the interrupts from s5m8767 are delivered to. > -- interrupts: Interrupt specifiers for two interrupt sources. > - - First interrupt specifier is for 'irq1' interrupt. > - - Second interrupt specifier is for 'alert' interrupt. > -- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs. > -- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs. > -- s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs. > - > -Additional properties required if either of the optional properties are used: > - > -- s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from > - the possible 8 option
Re: [PATCH 3/3] dt-bindings: regulator/mfd: Reorganize S2MPA01 bindings
On Fri, Dec 04, 2015 at 10:10:05AM +0900, Krzysztof Kozlowski wrote:
> The mfd/s2mpa01.txt duplicates some of the information about bindings
> with old mfd/s2mps11.txt. Now common part exists entirely in
> mfd/samsung,sec-core.txt so:
> - add company prefix to file name (regulator/samsung,s2mpa01.txt),
> - remove duplicated information,
> - reorganize the contents to match style of
>regulator/samsung,s2mps11.txt.
>
> Signed-off-by: Krzysztof Kozlowski
Next time, use git format-patch -M option.
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/mfd/s2mpa01.txt | 90
> --
> .../devicetree/bindings/mfd/samsung,sec-core.txt | 4 +-
> .../bindings/regulator/samsung,s2mpa01.txt | 79 +++
> 3 files changed, 82 insertions(+), 91 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt
> create mode 100644
> Documentation/devicetree/bindings/regulator/samsung,s2mpa01.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> deleted file mode 100644
> index c13d3d8c3947..
> --- a/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> +++ /dev/null
> @@ -1,90 +0,0 @@
> -
> -* Samsung S2MPA01 Voltage and Current Regulator
> -
> -The Samsung S2MPA01 is a multi-function device which includes high
> -efficiency buck converters including Dual-Phase buck converter, various LDOs,
> -and an RTC. 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 "samsung,s2mpa01-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 s2mpa01 are delivered to.
> -- interrupts: An interrupt specifier for the sole interrupt generated by the
> - device.
> -
> -Optional nodes:
> -- regulators: The regulators of s2mpa01 that have to be instantiated should
> be
> - included in a sub-node named 'regulators'. Regulator nodes and constraints
> - included in this sub-node use the standard regulator bindings which are
> - documented elsewhere.
> -
> -Properties for BUCK regulator nodes:
> -- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
> - (default), 25000, or 5. May be 0 for disabling the ramp delay on
> - BUCK{1,2,3,4}.
> -
> - In the absence of the regulator-ramp-delay property, the default ramp
> - delay will be used.
> -
> - NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be
> set
> - for a particular group of BUCKs. So provide same
> regulator-ramp-delay=.
> -
> - The following BUCKs share ramp settings:
> - * 1 and 6
> - * 2 and 4
> - * 8, 9, and 10
> -
> -The following are the names of the regulators that the s2mpa01 PMIC block
> -supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
> -as per the datasheet of s2mpa01.
> -
> - - LDOn
> - - valid values for n are 1 to 26
> - - Example: LDO1, LD02, LDO26
> - - BUCKn
> - - valid values for n are 1 to 10.
> - - Example: BUCK1, BUCK2, BUCK9
> -
> -Example:
> -
> - s2mpa01_pmic@66 {
> - compatible = "samsung,s2mpa01-pmic";
> - reg = <0x66>;
> -
> - regulators {
> - ldo1_reg: LDO1 {
> - regulator-name = "VDD_ALIVE";
> - regulator-min-microvolt = <100>;
> - regulator-max-microvolt = <100>;
> - };
> -
> - ldo2_reg: LDO2 {
> - regulator-name = "VDDQ_MMC2";
> - regulator-min-microvolt = <280>;
> - regulator-max-microvolt = <280>;
> - regulator-always-on;
> - };
> -
> - buck1_reg: BUCK1 {
> - regulator-name = "vdd_mif";
> - regulator-min-microvolt = <95>;
> - regulator-max-microvolt = <135>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -
> - buck2_reg: BUCK2 {
> - regulator-name = "vdd_arm";
> - regulator-min-microvolt = <95>;
> - regulator-max-microvolt = <135>;
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-ramp-delay = <5>;
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/binding
Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hello Inki, On 12/04/2015 11:57 AM, Inki Dae wrote: > Hi Javier, > > 2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas : >> Hello Inki, >> >> On 12/04/2015 06:00 AM, Inki Dae wrote: >>> Hi Javier, >>> >>> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글: Hello Inki, I found that v2 of this patch is alredy in your exynos-drm for-next branch so so I had to revert it in linux-next to apply this one to test. You shouldn't push patches that were still not reviewed (specially the ones that weren't tested like this one) to your branch that gets pulled by -next. The idea of -next is to have some test coverage but it should be as stable as possible. >>> >>> exynos-drm/for-next branch is not really for-next branch. This branch is >>> used >> >> Well, it is a for-next branch because is pulled by -next. It is listed in: >> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees >> >> drm-exynos git >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next >> >>> only for integration test. As you know, there are many exynos maintainers >>> and they have their own repository. So we would need to test the >>> integration. >> >> Integration testing is of course very needed and linux-next is for that but >> what should be tested are the patches that are targeted to mainline. >> >>> For this, exynos-drm/for-next is merged to linux-next not Dave's tree. >>> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed >>> and >>> tested patches will be merged to exynos-drm-next. >>> >> >> In that case, exynos-drm-next is what should be pulled by linux-next, no the >> for-next branch. Linux-next is a simulation of what Torvalds would do next >> so problems are found earlier, ideally before the patches land into mainline. > > Seems I didn't comment enough. exynos-drm/for-next branch includes all > patches of exynos-drm-next > and actually, they keep same patches for most time but sometimes, I > merge additional patches only to > exynos-drm/for-next, which should be more tested with other trees > before going to Dave's tree. > Ok, but unreviewed and more importantly untested patches should not go to to exynos-drm/for-next because those will be made available in linux-next and can cause issues. Only patches that are known to be good and have been reviewed/acked should go there. > One more thing, there is other difference between exynos-drm-next and > exynos-drm/for-next. > That is all patches of exynos-drm-next are merged on top of based on > Dave's drm-next branch. > On the other hand, all of exynos-drm/for-next are merged on top of > mainline. So if exynos-drm-next It's OK if you keep a different branch because you need a different base before sending your pull request but IMHO the patches in both branches should always be the same. > is merged to linux-next then all patches will be conflicted with > Dave's tree because his branch > is also merged to linux-next. > > I'm not sure that other maintainers always keep only the for-next > branch in their repository but > in my case, I use exynos-drm/for-next branch for the test before going > to drm-next. > Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree > will also be pulled by > linux-next, which would allow exynos-drm-next to be tested altogether > again before going to mainline. > This should be a common problem for subsystems with different levels of maintainership. I'm not a subsystem maintainer so I don't know how this should be solved but I thought that git merge would take care of this when both trees are pulled by linux-next. Maybe Krzysztof can comment on this since he has to do the same for the Exynos SoC support? He maintains a for-next branch and has to send pull request to Kukjin (and sometimes may need to rebase on top of Kukjin's tree) but both trees are pulled by linux-next to test. > Thanks, > Inki Dae > 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
[PATCH v3 01/10] cpufreq: arm_big_little: add cluster regulator support
Add cluster regulator support as a preparation to adding
generic arm_big_little_dt cpufreq_dt driver support for
ODROID-XU3 board. This allows arm_big_little[_dt] driver
to set not only the frequency but also the voltage (which
is obtained from operating point's voltage value) for CPU
clusters.
Cc: Kukjin Kim
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Cc: Sachin Kamat
Cc: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
.../bindings/cpufreq/arm_big_little_dt.txt | 4 +
drivers/cpufreq/arm_big_little.c | 175 +
2 files changed, 151 insertions(+), 28 deletions(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
index 0715695..8ca4a12 100644
--- a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
+++ b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
@@ -18,6 +18,10 @@ Required properties:
Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
+- cpu-cluster.0-supply: Provides the regulator node supplying voltage to CPU
+ cluster 0.
+- cpu-cluster.1-supply: Provides the regulator node supplying voltage to CPU
+ cluster 1.
Examples:
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index c5d256c..8b05137 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "arm_big_little.h"
@@ -57,6 +58,9 @@ static bool bL_switching_enabled;
static struct cpufreq_arm_bL_ops *arm_bL_ops;
static struct clk *clk[MAX_CLUSTERS];
+static struct regulator *reg[MAX_CLUSTERS];
+static struct device *cpu_devs[MAX_CLUSTERS];
+static int transition_latencies[MAX_CLUSTERS];
static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
static atomic_t cluster_usage[MAX_CLUSTERS + 1];
@@ -125,30 +129,53 @@ static unsigned int bL_cpufreq_get_rate(unsigned int cpu)
}
}
-static unsigned int
-bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 new_cluster, u32 rate)
+static int
+bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
{
- u32 new_rate, prev_rate;
+ unsigned long volt = 0, volt_old = 0;
+ long freq_Hz;
+ u32 old_rate;
int ret;
- bool bLs = is_bL_switching_enabled();
- mutex_lock(&cluster_lock[new_cluster]);
+ freq_Hz = new_rate * 1000;
+ old_rate = clk_get_rate(clk[cluster]) / 1000;
- if (bLs) {
- prev_rate = per_cpu(cpu_last_req_freq, cpu);
- per_cpu(cpu_last_req_freq, cpu) = rate;
- per_cpu(physical_cluster, cpu) = new_cluster;
+ if (!IS_ERR(reg[cluster])) {
+ struct dev_pm_opp *opp;
+ unsigned long opp_freq;
- new_rate = find_cluster_maxfreq(new_cluster);
- new_rate = ACTUAL_FREQ(new_cluster, new_rate);
- } else {
- new_rate = rate;
+ rcu_read_lock();
+ opp = dev_pm_opp_find_freq_ceil(cpu_devs[cluster], &freq_Hz);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ pr_err("%s: cpu %d, cluster: %d, failed to find OPP for
%ld\n",
+ __func__, cpu, cluster, freq_Hz);
+ return PTR_ERR(opp);
+ }
+ volt = dev_pm_opp_get_voltage(opp);
+ opp_freq = dev_pm_opp_get_freq(opp);
+ rcu_read_unlock();
+ volt_old = regulator_get_voltage(reg[cluster]);
+ pr_debug("%s: cpu %d, cluster: %d, Found OPP: %ld kHz, %ld
uV\n",
+ __func__, cpu, cluster, opp_freq / 1000, volt);
}
- pr_debug("%s: cpu: %d, old cluster: %d, new cluster: %d, freq: %d\n",
- __func__, cpu, old_cluster, new_cluster, new_rate);
+ pr_debug("%s: cpu %d, cluster: %d, %u MHz, %ld mV --> %u MHz, %ld mV\n",
+ __func__, cpu, cluster,
+ old_rate / 1000, (volt_old > 0) ? volt_old / 1000 : -1,
+ new_rate / 1000, volt ? volt / 1000 : -1);
- ret = clk_set_rate(clk[new_cluster], new_rate * 1000);
+ /* scaling up? scale voltage before frequency */
+ if (!IS_ERR(reg[cluster]) && new_rate > old_rate) {
+ ret = regulator_set_voltage_tol(reg[cluster], volt, 0);
+ if (ret) {
+ pr_err("%s: cpu: %d, cluster: %d, failed to scale
voltage up: %d\n",
+ __func__, cpu, cluster, ret);
+ return ret;
+ }
+ }
+
+ ret = clk_set_rate(clk[cluster], new_rate * 1000);
if (!ret) {
/*
* FIXME: clk_set_rate hasn't returned an error here however it
@@ -158,25 +185,66
[PATCH v3 09/10] ARM: Exynos: use generic cpufreq driver for Exynos5800
From: Thomas Abraham
The new CPU clock type allows the use of generic arm_big_little_dt
cpufreq driver for Exynos5800.
Changes by Bartlomiej:
- split Exynos5800 support from the original patch
- disable cpufreq if big.LITTLE switcher support is enabled
Cc: Tomasz Figa
Cc: Kukjin Kim
Cc: Javier Martinez Canillas
Signed-off-by: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 6d97145..73853de 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -236,6 +236,7 @@ static const struct of_device_id exynos_cpufreq_matches[] =
{
*/
#ifndef CONFIG_BL_SWITCHER
{ .compatible = "samsung,exynos5420", .data = "arm-bL-cpufreq-dt" },
+ { .compatible = "samsung,exynos5800", .data = "arm-bL-cpufreq-dt" },
#endif
{ /* sentinel */ }
};
--
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 v3 07/10] ARM: dts: Exynos5800: fix CPU OPP
Fix CPU operating points for Exynos5800 (it uses different
voltages than Exynos5420 and supports additional frequencies).
However don't use 2000MHz & 1900MHz OPPs (for A15 cores) and
1400MHz OPP (for A7 cores) until there is a separate DTS for
ODROID-XU3 Lite board (which doesn't support these higher
OPPs).
Based on Hardkernel's kernel for ODROID-XU3 board.
Changes by Ben Gamari:
- Port to operating-points-v2
Cc: Kukjin Kim
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Cc: Sachin Kamat
Cc: Thomas Abraham
Signed-off-by: Ben Gamari
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/boot/dts/exynos5800.dtsi | 165 ++
1 file changed, 165 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800.dtsi
b/arch/arm/boot/dts/exynos5800.dtsi
index c0bb356..e417218 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -17,8 +17,173 @@
/ {
compatible = "samsung,exynos5800", "samsung,exynos5";
+
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+ opp00@18 {
+ opp-hz = /bits/ 64 <18>;
+ opp-microvolt = <125>;
+ clock-latency-ns = <14>;
+ };
+ opp01@17 {
+ opp-hz = /bits/ 64 <17>;
+ opp-microvolt = <125>;
+ clock-latency-ns = <14>;
+ };
+ opp02@16 {
+ opp-hz = /bits/ 64 <16>;
+ opp-microvolt = <125>;
+ clock-latency-ns = <14>;
+ };
+ opp03@15 {
+ opp-hz = /bits/ 64 <15>;
+ opp-microvolt = <110>;
+ clock-latency-ns = <14>;
+ };
+ opp04@14 {
+ opp-hz = /bits/ 64 <14>;
+ opp-microvolt = <110>;
+ clock-latency-ns = <14>;
+ };
+ opp05@13 {
+ opp-hz = /bits/ 64 <13>;
+ opp-microvolt = <110>;
+ clock-latency-ns = <14>;
+ };
+ opp06@12 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <14>;
+ };
+ opp07@11 {
+ opp-hz = /bits/ 64 <11>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <14>;
+ };
+ opp08@10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <14>;
+ };
+ opp09@9 {
+ opp-hz = /bits/ 64 <9>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <14>;
+ };
+ opp10@8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp11@7 {
+ opp-hz = /bits/ 64 <7>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp12@6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp13@5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp14@4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp15@3 {
+ opp-hz = /bits/ 64 <3>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp16@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ };
+
+ cpu1_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+ opp00@13 {
+ opp-hz = /bits/ 64 <13>;
+
[PATCH v3 06/10] clk: samsung: exynos5800: fix cpu clock configuration data
Fix cpu clock configuration data for Exynos5800 (it uses
higher PCLK_DBG divider values than Exynos5420 and supports
additional frequencies).
Based on Hardkernel's kernel for ODROID-XU3 board.
Cc: Tomasz Figa
Cc: Mike Turquette
Cc: Javier Martinez Canillas
Cc: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/clk/samsung/clk-exynos5420.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 2a92546..837329d 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1274,10 +1274,34 @@ static const struct exynos_cpuclk_cfg_data
exynos5420_eglclk_d[] __initconst = {
{ 0 },
};
+static const struct exynos_cpuclk_cfg_data exynos5800_eglclk_d[] __initconst =
{
+ { 200, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 190, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 100, E5420_EGL_DIV0(3, 7, 6, 2), },
+ { 90, E5420_EGL_DIV0(3, 7, 6, 2), },
+ { 80, E5420_EGL_DIV0(3, 7, 5, 2), },
+ { 70, E5420_EGL_DIV0(3, 7, 5, 2), },
+ { 60, E5420_EGL_DIV0(3, 7, 4, 2), },
+ { 50, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 40, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 30, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 20, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 0 },
+};
+
#define E5420_KFC_DIV(kpll, pclk, aclk)
\
kpll) << 24) | ((pclk) << 20) | ((aclk) << 4)))
static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[] __initconst =
{
+ { 140, E5420_KFC_DIV(3, 5, 3), }, /* for Exynos5800 */
{ 130, E5420_KFC_DIV(3, 5, 2), },
{ 120, E5420_KFC_DIV(3, 5, 2), },
{ 110, E5420_KFC_DIV(3, 5, 2), },
@@ -1357,9 +1381,15 @@ static void __init exynos5x_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos5800_gate_clks));
}
- exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
- mout_cpu_p[0], mout_cpu_p[1], 0x200,
- exynos5420_eglclk_d, ARRAY_SIZE(exynos5420_eglclk_d), 0);
+ if (soc == EXYNOS5420) {
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5420_eglclk_d, ARRAY_SIZE(exynos5420_eglclk_d),
0);
+ } else {
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5800_eglclk_d, ARRAY_SIZE(exynos5800_eglclk_d),
0);
+ }
exynos_register_cpu_clock(ctx, CLK_KFC_CLK, "kfcclk",
mout_kfc_p[0], mout_kfc_p[1], 0x28200,
exynos5420_kfcclk_d, ARRAY_SIZE(exynos5420_kfcclk_d), 0);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 08/10] ARM: dts: Exynos5422: fix OPP tables
From: Ben Gamari
The Exynos 5422 is identical to the 5800 except for the fact that it
boots from the A7 cores. Consequently, the core numbering is different:
cores 0-3 are A7s whereas 4-7 are A15s.
We can reuse the device tree of the 5800 for the 5422 but we must take
care to override the OPP tables and CPU clocks. These are otherwise
inherited from the exynos5800 devicetree, which has the CPU clusters
reversed compared to the 5422. This results in the A15 cores only
reaching 1.4GHz, the maximum rate of the KFC clock.
Cc: Javier Martinez Canillas
Signed-off-by: Ben Gamari
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi
b/arch/arm/boot/dts/exynos5422-cpus.dtsi
index b7f60c8..9a5131d 100644
--- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
+++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
@@ -20,8 +20,10 @@
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
+ clocks = <&clock CLK_KFC_CLK>;
clock-frequency = <10>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu1 {
@@ -30,6 +32,7 @@
reg = <0x101>;
clock-frequency = <10>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu2 {
@@ -38,6 +41,7 @@
reg = <0x102>;
clock-frequency = <10>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu3 {
@@ -46,14 +50,17 @@
reg = <0x103>;
clock-frequency = <10>;
cci-control-port = <&cci_control0>;
+ operating-points-v2 = <&cpu1_opp_table>;
};
&cpu4 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
+ clocks = <&clock CLK_ARM_CLK>;
clock-frequency = <18>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
&cpu5 {
@@ -62,6 +69,7 @@
reg = <0x1>;
clock-frequency = <18>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
&cpu6 {
@@ -70,6 +78,7 @@
reg = <0x2>;
clock-frequency = <18>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
&cpu7 {
@@ -78,4 +87,5 @@
reg = <0x3>;
clock-frequency = <18>;
cci-control-port = <&cci_control1>;
+ operating-points-v2 = <&cpu0_opp_table>;
};
--
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 v3 10/10] cpufreq: arm-big-little: accept operating-points-v2 nodes
From: Ben Gamari
The arm_big_little cpufreq driver can use operating points from
operating-points-v2 nodes without any trouble.
Cc: Javier Martinez Canillas
Signed-off-by: Ben Gamari
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/cpufreq/arm_big_little_dt.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/cpufreq/arm_big_little_dt.c
b/drivers/cpufreq/arm_big_little_dt.c
index 16ddeef..be7f632 100644
--- a/drivers/cpufreq/arm_big_little_dt.c
+++ b/drivers/cpufreq/arm_big_little_dt.c
@@ -35,12 +35,16 @@ static struct device_node *get_cpu_node_with_valid_op(int
cpu)
{
struct device_node *np = of_cpu_device_node_get(cpu);
- if (!of_get_property(np, "operating-points", NULL)) {
- of_node_put(np);
- np = NULL;
+ if (of_get_property(np, "operating-points-v2", NULL)) {
+ return np;
}
- return np;
+ if (of_get_property(np, "operating-points", NULL)) {
+ return np;
+ }
+
+ of_node_put(np);
+ return NULL;
}
static int dt_init_opp_table(struct device *cpu_dev)
--
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 v3 05/10] ARM: Exynos: use generic cpufreq driver for Exynos5420
From: Thomas Abraham
The new CPU clock type allows the use of generic arm_big_little_dt
cpufreq driver for Exynos5420.
Changes by Bartlomiej:
- split Exynos5420 support from the original patch
- disable cpufreq if big.LITTLE switcher support is enabled
Cc: Tomasz Figa
Cc: Kukjin Kim
Cc: Javier Martinez Canillas
Signed-off-by: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/mach-exynos/exynos.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 1c47aee..6d97145 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -230,6 +230,13 @@ static const struct of_device_id exynos_cpufreq_matches[]
= {
{ .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
{ .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
{ .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
+/*
+ * FIXME: When big.LITTLE switcher is enabled system lockups during
+ * ondemand governor stress testing (observed on ODROID-XU3 board).
+ */
+#ifndef CONFIG_BL_SWITCHER
+ { .compatible = "samsung,exynos5420", .data = "arm-bL-cpufreq-dt" },
+#endif
{ /* sentinel */ }
};
--
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 v3 03/10] clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock
From: Thomas Abraham
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos5420.
Changes by Bartlomiej:
- split Exynos5420 support from the original patches
- moved E5420_[EGL,KFC]_DIV0() macros to clk-exynos5420.c
Cc: Tomasz Figa
Cc: Mike Turquette
Cc: Javier Martinez Canillas
Signed-off-by: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/clk/samsung/clk-exynos5420.c | 58 --
include/dt-bindings/clock/exynos5420.h | 2 ++
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 389af3c..2a92546 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -18,6 +18,7 @@
#include
#include "clk.h"
+#include "clk-cpu.h"
#define APLL_LOCK 0x0
#define APLL_CON0 0x100
@@ -616,9 +617,11 @@ static struct samsung_mux_clock exynos5x_mux_clks[]
__initdata = {
MUX(0, "mout_mspll_kfc", mout_mspll_cpu_p, SRC_TOP7, 8, 2),
MUX(0, "mout_mspll_cpu", mout_mspll_cpu_p, SRC_TOP7, 12, 2),
- MUX(0, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
+ MUX_F(0, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
+ CLK_SET_RATE_PARENT | CLK_RECALC_NEW_RATES, 0),
MUX(0, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1),
- MUX(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1),
+ MUX_F(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1,
+ CLK_SET_RATE_PARENT | CLK_RECALC_NEW_RATES, 0),
MUX(0, "mout_kfc", mout_kfc_p, SRC_KFC, 16, 1),
MUX(0, "mout_aclk200", mout_group1_p, SRC_TOP0, 8, 2),
@@ -1246,6 +1249,50 @@ static struct samsung_pll_clock exynos5x_plls[nr_plls]
__initdata = {
KPLL_CON0, NULL),
};
+#define E5420_EGL_DIV0(apll, pclk_dbg, atb, cpud) \
+ apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \
+((cpud) << 4)))
+
+static const struct exynos_cpuclk_cfg_data exynos5420_eglclk_d[] __initconst =
{
+ { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 100, E5420_EGL_DIV0(3, 6, 6, 2), },
+ { 90, E5420_EGL_DIV0(3, 6, 6, 2), },
+ { 80, E5420_EGL_DIV0(3, 5, 5, 2), },
+ { 70, E5420_EGL_DIV0(3, 5, 5, 2), },
+ { 60, E5420_EGL_DIV0(3, 4, 4, 2), },
+ { 50, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 40, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 30, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 20, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 0 },
+};
+
+#define E5420_KFC_DIV(kpll, pclk, aclk)
\
+ kpll) << 24) | ((pclk) << 20) | ((aclk) << 4)))
+
+static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[] __initconst =
{
+ { 130, E5420_KFC_DIV(3, 5, 2), },
+ { 120, E5420_KFC_DIV(3, 5, 2), },
+ { 110, E5420_KFC_DIV(3, 5, 2), },
+ { 100, E5420_KFC_DIV(3, 5, 2), },
+ { 90, E5420_KFC_DIV(3, 5, 2), },
+ { 80, E5420_KFC_DIV(3, 5, 2), },
+ { 70, E5420_KFC_DIV(3, 4, 2), },
+ { 60, E5420_KFC_DIV(3, 4, 2), },
+ { 50, E5420_KFC_DIV(3, 4, 2), },
+ { 40, E5420_KFC_DIV(3, 3, 2), },
+ { 30, E5420_KFC_DIV(3, 3, 2), },
+ { 20, E5420_KFC_DIV(3, 3, 2), },
+ { 0 },
+};
+
static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = "samsung,exynos5420-oscclk", .data = (void *)0, },
{ },
@@ -1310,6 +1357,13 @@ static void __init exynos5x_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos5800_gate_clks));
}
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5420_eglclk_d, ARRAY_SIZE(exynos5420_eglclk_d), 0);
+ exynos_register_cpu_clock(ctx, CLK_KFC_CLK, "kfcclk",
+ mout_kfc_p[0], mout_kfc_p[1], 0x28200,
+ exynos5420_kfcclk_d, ARRAY_SIZE(exynos5420_kfcclk_d), 0);
+
exynos5420_clk_sleep_init();
samsung_clk_of_add_provider(np, ctx);
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 99da0d1..dde9664 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -25,6 +25,8 @@
#define CLK_FOUT_MPLL 10
#define CLK_FOUT_BPLL 11
#define CLK_FOUT_KPLL
[PATCH v3 02/10] ARM: dts: Exynos5420/5800: add cluster regulator supply properties
Add cluster regulator supply properties as a preparation to
adding generic arm_big_little_dt cpufreq driver support for
Exynos5420 and Exynos5800 based boards.
Cc: Kukjin Kim
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Cc: Sachin Kamat
Cc: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 8
arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
arch/arm/boot/dts/exynos5420-smdk5420.dts | 8
arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts | 8
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 8
arch/arm/boot/dts/exynos5422-odroidxu4.dts | 8
arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
7 files changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 4ecef69..24b8a35 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -52,6 +52,14 @@
};
};
+&cpu0 {
+ cpu-cluster.0-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-cluster.1-supply = <&buck6_reg>;
+};
+
&usbdrd_dwc3_1 {
dr_mode = "host";
};
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..2b74230 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -676,6 +676,14 @@
};
};
+&cpu0 {
+ cpu-cluster.0-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-cluster.1-supply = <&buck6_reg>;
+};
+
&i2c_2 {
status = "okay";
samsung,i2c-sda-delay = <100>;
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..9e2dc5f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -423,3 +423,11 @@
&usbdrd_phy1 {
vbus-supply = <&usb301_vbus_reg>;
};
+
+&cpu0 {
+ cpu-cluster.0-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-cluster.1-supply = <&buck6_reg>;
+};
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
index 2ae1cf4..6f1de7c 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
@@ -54,6 +54,14 @@
};
};
+&cpu0 {
+ cpu-cluster.1-supply = <&buck6_reg>;
+};
+
+&cpu4 {
+ cpu-cluster.0-supply = <&buck2_reg>;
+};
+
&pwm {
/*
* PWM 0 -- fan
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index 432406d..6b64122 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -53,6 +53,14 @@
};
};
+&cpu0 {
+ cpu-cluster.1-supply = <&buck6_reg>;
+};
+
+&cpu4 {
+ cpu-cluster.0-supply = <&buck2_reg>;
+};
+
&i2c_0 {
status = "okay";
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf886..516a40f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -32,6 +32,14 @@
};
};
+&cpu0 {
+ cpu-cluster.1-supply = <&buck6_reg>;
+};
+
+&cpu4 {
+ cpu-cluster.0-supply = <&buck2_reg>;
+};
+
&pwm {
/*
* PWM 0 -- fan
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e4..34cd 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -638,6 +638,14 @@
};
};
+&cpu0 {
+ cpu-cluster.0-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-cluster.1-supply = <&buck6_reg>;
+};
+
&i2c_2 {
status = "okay";
samsung,i2c-sda-delay = <100>;
--
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 v3 0/10] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
Hi, This patch series adds generic arm_big_little_dt cpufreq driver support for Exynos542x/5800 (using the new CPU clock type which allows it). It also: - enhances arm_big_little[_dt] driver with CPU cluster regulator support - adds CPU clock configuration data and CPU operating points setup for Exynos542x/5800 - adds CPU cluster regulator supplies for Exynos542x/5800 boards This patch series has been tested on Exynos5422 based ODROID-XU3 Lite board. Please note that this is not a final version of the patchset. I just wanted to push out current work-in-progress patches that integrate changes from Anand, Ben and me. TODO: - porting the Exynos542x/5800 support over cpufreq-dt Depends on: - next-20151124 branch of linux-next kernel tree Changes since v2: - ported over next-20151124 branch - integrated missing CLK_RECALC_NEW_RATES flags fix to patch #3 (from Anand Moon) - added regulator supply properties for ODROID-XU3 Lite and ODROID-XU4 in patch #2 - ported CPU OPPs to operating-points-v2 (from Ben Gamari) - added "ARM: dts: Exynos5422: fix OPP tables" patch (from Ben Gamari) - added "cpufreq: arm-big-little: accept operating-points-v2 nodes" patch (from Ben Gamari) - renamed OPP nodes as opp@ Changes since v1: - added CPU cluster regulator supply properties to exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts, exynos5420-smdk5420.dts and exynos5800-peach-pi.dts Changes over Thomas' original v12 code: - split Exynos5420 and Exynos5800 support - moved E5420_[EGL,KFC]_DIV0() macros to clk-exynos5420.c - disabled cpufreq if big.LITTLE switcher support is enabled - enhanced arm_big_little[_dt] driver with CPU cluster regulator support - fixed CPU clock configuration data for Exynos5800 - fixed CPU operating points setup for Exynos5800 - added CPU cluster regulator supplies for ODROID-XU3 board Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (4): cpufreq: arm_big_little: add cluster regulator support ARM: dts: Exynos5420/5800: add cluster regulator supply properties clk: samsung: exynos5800: fix cpu clock configuration data ARM: dts: Exynos5800: fix CPU OPP Ben Gamari (2): ARM: dts: Exynos5422: fix OPP tables cpufreq: arm-big-little: accept operating-points-v2 nodes Thomas Abraham (4): clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock ARM: dts: Exynos5420: add CPU OPP and regulator supply property ARM: Exynos: use generic cpufreq driver for Exynos5420 ARM: Exynos: use generic cpufreq driver for Exynos5800 .../bindings/cpufreq/arm_big_little_dt.txt | 4 + arch/arm/boot/dts/exynos5420-arndale-octa.dts | 8 + arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 + arch/arm/boot/dts/exynos5420-smdk5420.dts | 8 + arch/arm/boot/dts/exynos5420.dtsi | 122 ++ arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++ arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts| 8 + arch/arm/boot/dts/exynos5422-odroidxu3.dts | 8 + arch/arm/boot/dts/exynos5422-odroidxu4.dts | 8 + arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 + arch/arm/boot/dts/exynos5800.dtsi | 165 +++ arch/arm/mach-exynos/exynos.c | 8 + drivers/clk/samsung/clk-exynos5420.c | 88 ++- drivers/cpufreq/arm_big_little.c | 175 + drivers/cpufreq/arm_big_little_dt.c| 12 +- include/dt-bindings/clock/exynos5420.h | 2 + 16 files changed, 608 insertions(+), 34 deletions(-) -- 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 1/3] Device tree binding documentation for gpio-switch
This patch adds documentation for the gpio-switch binding. This binding
provides a mechanism to bind named links to gpio, with the primary
purpose of enabling standardised access to switches that might be standard
across a group of devices but implemented differently on each device.
Signed-off-by: Martyn Welch
---
.../devicetree/bindings/misc/gpio-switch.txt | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/gpio-switch.txt
diff --git a/Documentation/devicetree/bindings/misc/gpio-switch.txt
b/Documentation/devicetree/bindings/misc/gpio-switch.txt
new file mode 100644
index 000..13528bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/gpio-switch.txt
@@ -0,0 +1,47 @@
+Device-Tree bindings for gpio attached switches.
+
+This provides a mechanism to provide a named link to specified gpios. This can
+be useful in instances such as when theres a need to monitor a switch, which is
+common across a family of devices, but attached to different gpios and even
+implemented in different ways on differnet devices.
+
+Required properties:
+ - compatible = "gpio-switch";
+
+Each signal is represented as a sub-node of "gpio-switch". The naming of
+sub-nodes is arbitrary.
+
+Required sub-node properties:
+
+ - label: Name to be given to gpio switch.
+ - gpios: OF device-tree gpio specification.
+
+Optional sub-node properties:
+
+ - read-only: Boolean flag to mark the gpio as read-only, i.e. the line
+ should not be driven by the host.
+
+Example nodes:
+
+gpio-switch {
+compatible = "gpio-switch";
+
+write-protect {
+label = "write-protect";
+gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+read-only;
+};
+
+developer-switch {
+label = "developer-switch";
+gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+read-only;
+};
+
+recovery-switch {
+label = "recovery-switch";
+gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+read-only;
+};
+};
+
--
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
[PATCH 3/3] ARM: dts: Addition of binding for gpio switches on peach-pi
The peach pi has a GPIO connected to the firmware write protect, developer
mode and recovery mode lines (which are primarily controlled via external
switches on developer test board). This patch adds the required nodes to
the device tree to configure the pinmuxing and allow these to be read from
user space.
Signed-off-by: Martyn Welch
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 46 +++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43..2937372 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -53,6 +53,31 @@
};
};
+ gpio-switch {
+ compatible = "gpio-switch";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&wp_gpio &dev_mode &rec_mode>;
+
+ write-protect {
+ label = "write-protect";
+ gpios = <&gpx3 0 GPIO_ACTIVE_LOW>;
+ read-only;
+ };
+
+ developer-switch {
+ label = "developer-switch";
+ gpios = <&gpx1 3 GPIO_ACTIVE_HIGH>;
+ read-only;
+ };
+
+ recovery-switch {
+ label = "recovery-switch";
+ gpios = <&gpx0 7 GPIO_ACTIVE_LOW>;
+ read-only;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -731,6 +756,13 @@
samsung,pin-val = <0>;
};
+ rec_mode: rec-mode {
+ samsung,pins = "gpx0-7";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
tpm_irq: tpm-irq {
samsung,pins = "gpx1-0";
samsung,pin-function = <0>;
@@ -752,6 +784,13 @@
samsung,pin-drv = <0>;
};
+ dev_mode: dev-mode {
+ samsung,pins = "gpx1-3";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <3>;
+ samsung,pin-drv = <0>;
+ };
+
ec_irq: ec-irq {
samsung,pins = "gpx1-5";
samsung,pin-function = <0>;
@@ -773,6 +812,13 @@
samsung,pin-drv = <0>;
};
+ wp_gpio: wp_gpio {
+ samsung,pins = "gpx3-0";
+ samsung,pin-function = <0>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
+
max77802_irq: max77802-irq {
samsung,pins = "gpx3-1";
samsung,pin-function = <0>;
--
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
Add support for monitoring gpio switches
This driver was written to expose a read only interface to a number of gpios on Chromebooks. These gpios are attached to signals which cause the firmware on Chromebooks to enter alternative modes of operation and/or control other device characteristics (such as write protection on flash devices). It was originally posted as "Add support for monitoring Chrome OS firmware signals". A request was made to make it more generic. In addition this patch series provides the required bindings for this to the peach-pi Chromebook. This is a new binding, but the driver is based (now some what loosely) on functionality in the kernel shipped on Chromebooks. -- 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 2/3] Add support for monitoring gpio switches
Select Chromebooks have gpio attached to switches used to cause the
firmware to enter alternative modes of operation and/or control other
device characteristics (such as write protection on flash devices). This
patch adds a driver that exposes a read-only interface to allow these
signals to be read from user space.
This functionality has been generalised to provide support for any device
with device tree support which needs to identify a gpio as being used for a
specific task.
Signed-off-by: Martyn Welch
---
drivers/misc/Kconfig | 11
drivers/misc/Makefile | 1 +
drivers/misc/gpio-switch.c | 160 +
3 files changed, 172 insertions(+)
create mode 100644 drivers/misc/gpio-switch.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 22892c7..d24367c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -525,6 +525,17 @@ config VEXPRESS_SYSCFG
bus. System Configuration interface is one of the possible means
of generating transactions on this bus.
+config GPIO_SWITCH
+ tristate "GPIO Switch driver"
+ depends on GPIO_SYSFS
+ ---help---
+Some devices have gpio attached to dedicated switches, an example of
+this are chromebooks (where connection to some switches for predefined
+purposes are provided on the generic development card). This driver
+provides the ability to create consistently named sysfs entries to the
+functionally equivalent signals across a range of devices. This
+functionality currently requires a device which supports device tree.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 537d7f3..7a7e11a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,3 +56,4 @@ obj-$(CONFIG_GENWQE) += genwqe/
obj-$(CONFIG_ECHO) += echo/
obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
obj-$(CONFIG_CXL_BASE) += cxl/
+obj-$(CONFIG_GPIO_SWITCH) += gpio-switch.o
diff --git a/drivers/misc/gpio-switch.c b/drivers/misc/gpio-switch.c
new file mode 100644
index 000..1f381d6
--- /dev/null
+++ b/drivers/misc/gpio-switch.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2015 Collabora Ltd.
+ *
+ * based on vendor driver,
+ *
+ * Copyright (C) 2011 The Chromium OS Authors
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct gpio_switch_gpio_info {
+ int gpio;
+ const char *link;
+};
+
+static int dt_gpio_init(struct platform_device *pdev, struct device_node
*child,
+ struct gpio_switch_gpio_info *gpio)
+{
+ int err;
+ enum of_gpio_flags of_flags;
+ unsigned long flags = GPIOF_DIR_IN | GPIOF_EXPORT;
+ const char *name;
+
+ err = of_property_read_string(child, "label", &name);
+ if (err)
+ return err;
+
+ gpio->gpio = of_get_named_gpio_flags(child, "gpios", 0, &of_flags);
+ if (!gpio_is_valid(gpio->gpio)) {
+ err = -EINVAL;
+ goto err_prop;
+ }
+
+ if (of_flags & OF_GPIO_ACTIVE_LOW)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ if (!of_property_read_bool(child, "read-only"))
+ flags |= GPIOF_EXPORT_CHANGEABLE;
+
+ err = gpio_request_one(gpio->gpio, flags, name);
+ if (err)
+ goto err_prop;
+
+ err = gpio_export_link(&pdev->dev, name, gpio->gpio);
+ if (err)
+ goto err_gpio;
+
+ gpio->link = name;
+
+ return 0;
+
+err_gpio:
+ gpio_free(gpio->gpio);
+err_prop:
+ of_node_put(child);
+
+ return err;
+}
+
+static void gpio_switch_rem(struct device *dev,
+ struct gpio_switch_gpio_info *gpio)
+{
+ sysfs_remove_link(&dev->kobj, gpio->link);
+
+ gpio_unexport(gpio->gpio);
+
+ gpio_free(gpio->gpio);
+}
+
+static int gpio_switch_probe(struct platform_device *pdev)
+{
+ struct gpio_switch_gpio_info *gpios;
+ struct device_node *child;
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+ int i;
+
+ i = of_get_child_count(np);
+ if (i < 1)
+ return i;
+
+ gpios = devm_kmalloc(&pdev->dev, sizeof(gpios) * i, GFP_KERNEL);
+ if (!gpios)
+ return -ENOMEM;
+
+ i = 0;
+
+
[PATCH v3 04/10] ARM: dts: Exynos5420: add CPU OPP and regulator supply property
From: Thomas Abraham
For Exynos5420 platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific
cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- split Exynos5420 support from the original patch
Changes by Ben Gamari:
- Port to operating-points-v2
Cc: Kukjin Kim
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Cc: Sachin Kamat
Cc: Thomas Abraham
Signed-off-by: Ben Gamari
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/boot/dts/exynos5420.dtsi | 122 ++
1 file changed, 122 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 48a0a55..f8f70a5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -50,6 +50,116 @@
usbdrdphy1 = &usbdrd_phy1;
};
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+ opp00@18 {
+ opp-hz = /bits/ 64 <18>;
+ opp-microvolt = <125>;
+ clock-latency-ns = <14>;
+ };
+ opp01@17 {
+ opp-hz = /bits/ 64 <17>;
+ opp-microvolt = <1212500>;
+ clock-latency-ns = <14>;
+ };
+ opp02@16 {
+ opp-hz = /bits/ 64 <16>;
+ opp-microvolt = <1175000>;
+ clock-latency-ns = <14>;
+ };
+ opp03@15 {
+ opp-hz = /bits/ 64 <15>;
+ opp-microvolt = <1137500>;
+ clock-latency-ns = <14>;
+ };
+ opp04@14 {
+ opp-hz = /bits/ 64 <14>;
+ opp-microvolt = <1112500>;
+ clock-latency-ns = <14>;
+ };
+ opp05@13 {
+ opp-hz = /bits/ 64 <13>;
+ opp-microvolt = <1062500>;
+ clock-latency-ns = <14>;
+ };
+ opp06@12 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt = <1037500>;
+ clock-latency-ns = <14>;
+ };
+ opp07@11 {
+ opp-hz = /bits/ 64 <11>;
+ opp-microvolt = <1012500>;
+ clock-latency-ns = <14>;
+ };
+ opp08@10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = < 987500>;
+ clock-latency-ns = <14>;
+ };
+ opp09@9 {
+ opp-hz = /bits/ 64 <9>;
+ opp-microvolt = < 962500>;
+ clock-latency-ns = <14>;
+ };
+ opp10@8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = < 937500>;
+ clock-latency-ns = <14>;
+ };
+ opp11@7 {
+ opp-hz = /bits/ 64 <7>;
+ opp-microvolt = < 912500>;
+ clock-latency-ns = <14>;
+ };
+ };
+
+ cpu1_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+ opp00@13 {
+ opp-hz = /bits/ 64 <13>;
+ opp-microvolt = <1275000>;
+ clock-latency-ns = <14>;
+ };
+ opp01@12 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt = <1212500>;
+ clock-latency-ns = <14>;
+ };
+ opp02@11 {
+ opp-hz = /bits/ 64 <11>;
+ opp-microvolt = <1162500>;
+ clock-latency-ns = <14>;
+ };
+ opp03@10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = <1112500>;
+ clock-latency-ns = <14>;
+ };
+ opp04@9 {
+ opp-hz = /bits/ 64 <9>;
+ opp-microvolt = <1062500>;
+ clock-latency-ns = <14>;
+ };
+ opp05@8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <1025000>;
+ clock-latency-ns = <14>;
+
Re: [PATCH 2/3] Add support for monitoring gpio switches
Hi Martyn, [auto build test WARNING on char-misc/char-misc-testing] [also build test WARNING on v4.4-rc3 next-20151203] url: https://github.com/0day-ci/linux/commits/Martyn-Welch/Device-tree-binding-documentation-for-gpio-switch/20151205-014105 coccinelle warnings: (new ones prefixed by >>) >> drivers/misc/gpio-switch.c:98:34-40: ERROR: application of sizeof to pointer Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- 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] fix noderef.cocci warnings
drivers/misc/gpio-switch.c:98:34-40: ERROR: application of sizeof to pointer sizeof when applied to a pointer typed expression gives the size of the pointer Generated by: scripts/coccinelle/misc/noderef.cocci CC: Martyn Welch Signed-off-by: Fengguang Wu --- gpio-switch.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/misc/gpio-switch.c +++ b/drivers/misc/gpio-switch.c @@ -95,7 +95,7 @@ static int gpio_switch_probe(struct plat if (i < 1) return i; - gpios = devm_kmalloc(&pdev->dev, sizeof(gpios) * i, GFP_KERNEL); + gpios = devm_kmalloc(&pdev->dev, sizeof(*gpios) * i, GFP_KERNEL); if (!gpios) return -ENOMEM; -- 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 2/3] Add support for monitoring gpio switches
On Fri, Dec 04, 2015 at 05:31:14PM +, Martyn Welch wrote: > Select Chromebooks have gpio attached to switches used to cause the > firmware to enter alternative modes of operation and/or control other > device characteristics (such as write protection on flash devices). This > patch adds a driver that exposes a read-only interface to allow these > signals to be read from user space. > > This functionality has been generalised to provide support for any device > with device tree support which needs to identify a gpio as being used for a > specific task. > > Signed-off-by: Martyn Welch > --- > drivers/misc/Kconfig | 11 > drivers/misc/Makefile | 1 + > drivers/misc/gpio-switch.c | 160 > + Why isn't this in drivers/gpio/ ? why make it a misc driver? thanks, greg k-h -- 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] [media] exynos4-is: make VIDEO_SAMSUNG_EXYNOS4_IS tristate
With CONFIG_V4L2=m and VIDEO_SAMSUNG_EXYNOS4_IS=y, we can select the individual drivers as built-in code when that should not be possible: drivers/built-in.o: In function `s5pcsis_set_fmt': policy.c:(.text+0x13afdc): undefined reference to `v4l_bound_align_image' drivers/built-in.o: In function `s5pcsis_probe': policy.c:(.text+0x13b440): undefined reference to `v4l2_of_parse_endpoint' policy.c:(.text+0x13b72c): undefined reference to `v4l2_subdev_init' Changing VIDEO_SAMSUNG_EXYNOS4_IS to tristate means that the dependency from CONFIG_V4L2 propates to the individual Kconfig symbols and they can only be built as loadable modules if V4L2 or any other of the dependencies itself is a module. Signed-off-by: Arnd Bergmann diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index 40423c6c5324..57d42c6172c5 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -1,6 +1,6 @@ config VIDEO_SAMSUNG_EXYNOS4_IS - bool "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver" + tristate "Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST depends on OF && COMMON_CLK -- 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/2] power: Fix unmet dependency on POWER_SUPPLY by POWER_RESET by uncoupling them
Hi, On Wed, Dec 02, 2015 at 02:59:06PM +0900, Krzysztof Kozlowski wrote: > Actually reset/power off handlers do not really depend on power supply. > Move the power reset out of power supply block so it will appear in main > drivers section. This fixes following build warning (encountered on ARM > exynos defconfig when POWER_SUPPLY is disabled manually): > > warning: (ARCH_HISI && ARCH_INTEGRATOR && ARCH_EXYNOS && ARCH_VEXPRESS && > REALVIEW_DT) selects POWER_RESET which has unmet direct dependencies > (POWER_SUPPLY) > warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON which has unmet direct > dependencies (POWER_SUPPLY && POWER_RESET && OF) > warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON_POWEROFF which has unmet > direct dependencies (POWER_SUPPLY && POWER_RESET && OF) nice catch. I don't really like the Makefile changes, though. I think it would be better to make the power/ entry in drivers/Makefile into "obj-y" and handle the details in drivers/power/Makefile. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH v3 0/10] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 04-12-15, 18:30, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds generic arm_big_little_dt cpufreq driver > support for Exynos542x/5800 (using the new CPU clock type which > allows it). It also: > - enhances arm_big_little[_dt] driver with CPU cluster regulator > support > - adds CPU clock configuration data and CPU operating points > setup for Exynos542x/5800 > - adds CPU cluster regulator supplies for Exynos542x/5800 boards > > This patch series has been tested on Exynos5422 based ODROID-XU3 > Lite board. > > Please note that this is not a final version of the patchset. > I just wanted to push out current work-in-progress patches that > integrate changes from Anand, Ben and me. What's going on guys, Ben tried exactly same thing few days back: http://marc.info/?l=linux-kernel&m=144909193925508&w=2 And the comments given there applies to you as well. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/10] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
Hi, On Saturday, December 05, 2015 09:24:44 AM Viresh Kumar wrote: > On 04-12-15, 18:30, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > > > This patch series adds generic arm_big_little_dt cpufreq driver > > support for Exynos542x/5800 (using the new CPU clock type which > > allows it). It also: > > - enhances arm_big_little[_dt] driver with CPU cluster regulator > > support > > - adds CPU clock configuration data and CPU operating points > > setup for Exynos542x/5800 > > - adds CPU cluster regulator supplies for Exynos542x/5800 boards > > > > This patch series has been tested on Exynos5422 based ODROID-XU3 > > Lite board. > > > > Please note that this is not a final version of the patchset. > > I just wanted to push out current work-in-progress patches that > > integrate changes from Anand, Ben and me. > > What's going on guys, Ben tried exactly same thing few days back: > > http://marc.info/?l=linux-kernel&m=144909193925508&w=2 Why I appreciate Ben's work this not exactly the same thing as the above patchset lacks critical CLK_RECALC_NEW_RATES bugfix and few other minor fixes. > And the comments given there applies to you as well. Yes, sure. That's why I wrote that this is work-in-progress and put the TODO in the cover letter. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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
