Re: [PATCH v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device
On 10.12.2015 16:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 22:58, Marek Szyprowski wrote:
>> Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
... and one more finding: I think the abbreviation is Multi Format Codec.
BR,
Krzysztof
>> Odroid boards.
>>
>> Signed-off-by: Marek Szyprowski
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24
>>
>> 1 file changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index edf0fc8..5825abf 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -18,6 +18,24 @@
>> stdout-path = &serial_1;
>> };
>>
>> +reserved-memory {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges;
>> +
>> +mfc_left: region@7700 {
>> +compatible = "shared-dma-pool";
>> +reusable;
>> +reg = <0x7700 0x100>;
>
> Doesn't this exceed the memory of Odroid X?
>
> For other Exynos4412 boards the length is 0x80. I am curious: any
> particular reason for the difference?
>
> Best regards,
> Krzysztof
>
>
--
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
Re: [PATCH v2 2/7] ARM: dts: exynos4412-odroid*: enable MFC device
On 09.12.2015 22:58, Marek Szyprowski wrote:
> Enable support for Multimedia Codec (MFC) device for all Exynos4412-based
> Odroid boards.
>
> Signed-off-by: Marek Szyprowski
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index edf0fc8..5825abf 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -18,6 +18,24 @@
> stdout-path = &serial_1;
> };
>
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + mfc_left: region@7700 {
> + compatible = "shared-dma-pool";
> + reusable;
> + reg = <0x7700 0x100>;
Doesn't this exceed the memory of Odroid X?
For other Exynos4412 boards the length is 0x80. I am curious: any
particular reason for the difference?
Best regards,
Krzysztof
--
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
Re: [PATCH] net/macb: add support for resetting PHY using GPIO
Hi Gregory, On Wed, Dec 09, 2015 at 06:49:43PM +0100, Gregory CLEMENT wrote: > With device tree it is no more possible to reset the PHY at board > level. Furthermore, doing in the driver allow to power down the PHY when > the network interface is no more used. > > The patch introduces a new optional property "phy-reset-gpio" inspired > from the one use for the FEC. I don't think it's a good idea to further extend the usage of this binding. The driver should use the phy-handle property and of_phy_connect() which gives you a proper device node for the phy. Then the phy device node should get the reset gpio. I know it's more work, but doing it like this gives you additional goodies like proper handling of the max-speed property, a fixed-link if necessary and picking the correct phy if there are muliple phys on the bus. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
Re: [PATCH v2 1/2] usb: renesas_usbhs: add fallback compatibility strings
Hi Simon
Thank you for your patch
> Add fallback compatibility strings for R-Car Gen2 and Gen3.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Also add SoC names.
>
> Signed-off-by: Simon Horman
> ---
(snip)
> Required properties:
>- compatible: Must contain one of the following:
> - - "renesas,usbhs-r8a7790"
> - - "renesas,usbhs-r8a7791"
> - - "renesas,usbhs-r8a7794"
> - - "renesas,usbhs-r8a7795"
> +
> + - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
> + - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
> + - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
> + - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
> + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatibile device
> + - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatibile device
> +
> + When compatible with the generic version, nodes must list the
> + SoC-specific version corresponding to the platform first followed
> + by the generic version.
I think these can be separated ?
1. document update for "renesas,usbhs-r8a77xx"
2. add new "rcar-genX" (this patch)
> Example:
> usbhs: usb@e659 {
> - compatible = "renesas,usbhs-r8a7790";
> + compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
I think you want
- compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
+ compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
--
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
Re: [PATCH v2 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 2015년 12월 10일 15:58, Krzysztof Kozlowski wrote: > On 09.12.2015 13:08, Chanwoo Choi wrote: >> This patch adds the bus device-tree node of INT (internal) block >> to enable the bus frequency. The following sub-blocks share > > "to enable the bus frequency scaling" > >> the VDD_INT power source: >> - LEFTBUS (parent device) >> - RIGHTBUS >> - PERIL >> - LCD0 >> - FSYS >> - MCUISP / ISP >> - MFC >> >> The LEFTBUS is parent device with devfreq ondemand governor >> and the rest devices has the dependency on LEFTBUS bus. > > How about: > "and the rest of devices depend on the LEFTBUS device." > ? OK, I'll modify it. > > The patch is good: > > Reviewed-by: Krzysztof Kozlowski Thanks for your review. Best Regards, Chanwoo Choi -- 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
Re: [PATCH v2 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
On 2015년 12월 10일 16:08, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
>> (Internal) block to enable the bus frequency.
>>
>> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
>> bus is parent device in INT block using VDD_INT.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
>> +
>> arch/arm/boot/dts/exynos4412-trats2.dts | 47
>> +
>> 2 files changed, 94 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index 171dea1e3e4a..12d08242a179 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -544,3 +544,50 @@
>> };
>> };
>> };
>> +
>> +&bus_dmc {
>> +devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
>> +vdd-supply = <&buck1_reg>;
>> +status = "okay";
>> +};
>> +
>> +&bus_acp {
>> +devfreq = <&bus_dmc>;
>> +status = "okay";
>> +};
>> +
>> +&bus_c2c {
>> +devfreq = <&bus_dmc>;
>> +status = "okay";
>> +};
>> +
>> +&bus_leftbus {
>> +devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
>> +vdd-supply = <&buck3_reg>;
>> +status = "okay";
>> +};
>> +
>> +&bus_rightbus {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_display {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_fsys {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_peri {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_mfc {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
>> b/arch/arm/boot/dts/exynos4412-trats2.dts
>> index 40a474c4374b..aecd545803ad 100644
>> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> @@ -1286,3 +1286,50 @@
>> vtmu-supply = <&ldo10_reg>;
>> status = "okay";
>> };
>> +
>> +&bus_dmc {
>> +devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
>> +vdd-supply = <&buck1_reg>;
>> +status = "okay";
>> +};
>> +
>> +&bus_acp {
>> +devfreq = <&bus_dmc>;
>> +status = "okay";
>> +};
>> +
>> +&bus_c2c {
>> +devfreq = <&bus_dmc>;
>> +status = "okay";
>> +};
>> +
>> +&bus_leftbus {
>> +devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
>> +vdd-supply = <&buck3_reg>;
>> +status = "okay";
>> +};
>> +
>> +&bus_rightbus {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_display {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_fsys {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_peri {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>> +
>> +&bus_mfc {
>> +devfreq = <&bus_leftbus>;
>> +status = "okay";
>> +};
>
> The nodes in both files are mostly sorted alphabetically. Could you
> place them in such order as well?
Okay. I'll sort them alphabetically.
Best Regards,
Chanwoo Choi
--
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
Re: [PATCH v2 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
On 2015년 12월 10일 16:02, Krzysztof Kozlowski wrote: > On 09.12.2015 13:08, Chanwoo Choi wrote: >> This patch expands the voltage range of buck1/3 regulator due to as >> following: >> - MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V. >> - INT (Internal) bus frequency needs 9uV ~ 100uV. > > 9->90 and duplicated "uV V". Maybe just: > 900 - 1050 mV > 900 - 1000 mV > ? OK. I'll modify the patch description. > >> >> Signed-off-by: Chanwoo Choi >> --- >> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++--- >> 1 file changed, 3 insertions(+), 3 deletions(-) >> > > For the contents of patch: > > Reviewed-by: Krzysztof Kozlowski Best Regards, Chanwoo CHoi -- 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
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 16:12, Krzysztof Kozlowski wrote:
> On 10.12.2015 16:07, Chanwoo Choi wrote:
>> On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 15:43, Chanwoo Choi wrote:
On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:08, Chanwoo Choi wrote:
>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>>> On 09.12.2015 13:08, Chanwoo Choi wrote:
This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and
sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4x12.dtsi | 112
++
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 3bcf0939755e..8bc4aee156b5 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -354,6 +354,118 @@
opp-microvolt = <95>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
>>>
>>> These two nodes are symmetrical. The MFC below and other buses in other
>>> DTS share opps. How about changing the binding so multiple clocks could
>>> be specified at once ("bus0", "bus1")? I think there is no need for a
>>> bus device for each clock.
>>
>> The your commented method is possible.
>>
>> But, I focus on implementing the generic bus frequency driver.
>>
>> If specific bus device-tree node includes the one more clocks,
>> when adding the new Exynos SoC, the exynos-bus.c should be added
>> for new Exynos SoC. Because, each Exynos SoC has the different
>> set of bus device.
>>
>> If we use my approach, we don't need to modify the exynos-bus.c
>> driver to support for the bus frequency of new Exynos SoC.
>
> This won't change. The driver will just support from 1 to N clocks for
> given bus device and set the same OPP to all of them. This will only
> limit the number of duplicated entries. This won't affect the generic
> approach of driver itself.
You're right aspect of only implementation of device driver.
But,
If we use your commented approach, we can show the information
of only parent device through sysfs. We cannot see the information
of passive device. The some information includes the current
frequency and correlation of parent device. (But, current patchset
don' include the topology information between parent device and
passive device. I'll do it on later patches).
For example,
We can see the following bus device through /sys/class/devfreq.
drwxr-xr-x 2 root root 0 Dec 31 17:00 .
drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
../../devices/platform/bus_display/devfreq/bus_display
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
../../devices/platform/bus_fsys/devfreq/bus_fsys
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
../../devices/platform/bus_leftbus/devfreq/bus_leftbus
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
../../devices/platform/bus_peri/devfreq/bus_peri
We don't see the following bus device because of following bus device
has the same frequency table with bus_leftbus device.
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
../../devices/platform/bus_mfc/devfreq/bus_mfc
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>>>
>>> Right, but why do you want to see these bus devices? AFAIU, they will
>>
>>
Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
Hi Bjorn, On 10.12.2015 00:19, Bjorn Helgaas wrote: > [+cc Michal, Paul, Thierry, Stephen, Alexandre (see irq_dispose_mapping > questions below)] > > On Sun, Nov 29, 2015 at 05:33:53PM +0530, Bharat Kumar Gogada wrote: >> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP. >> >> Signed-off-by: Bharat Kumar Gogada >> Signed-off-by: Ravi Kiran Gummaluri >> Acked-by: Rob Herring > > This needs either a MAINTAINERS update or an ack from Michal (whose > MAINTAINERS entry matches anything containing "xilinx"). We have done it in this way because driver owners are changing time to time and my entry cover it that I can pass it to appropriate person who is responsible for it. For this Maintainers part here is my: Acked-by: Michal Simek Thanks, Michal -- 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
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 10.12.2015 16:07, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:43, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
On 10.12.2015 15:08, Chanwoo Choi wrote:
> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>> Exynos4x12 has the following AXI buses to translate data between
>>> DRAM and sub-blocks.
>>>
>>> Following list specifies the detailed relation between DRAM and
>>> sub-blocks:
>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>> - ACLK160 clock for CAM/TV/LCD
>>> : The minimum clock of ACLK160 should be over 160MHz.
>>> When drop the clock under 160MHz, show the broken image.
>>> - ACLK133 clock for FSYS
>>> - GDL clock for LEFTBUS
>>> - GDR clock for RIGHTBUS
>>> - SCLK_MFC clock for MFC
>>>
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>>> ++
>>> 1 file changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 3bcf0939755e..8bc4aee156b5 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -354,6 +354,118 @@
>>> opp-microvolt = <95>;
>>> };
>>> };
>>> +
>>> + bus_leftbus: bus_leftbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = <&clock CLK_DIV_GDL>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <&bus_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + bus_rightbus: bus_rightbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = <&clock CLK_DIV_GDR>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <&bus_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>
>> These two nodes are symmetrical. The MFC below and other buses in other
>> DTS share opps. How about changing the binding so multiple clocks could
>> be specified at once ("bus0", "bus1")? I think there is no need for a
>> bus device for each clock.
>
> The your commented method is possible.
>
> But, I focus on implementing the generic bus frequency driver.
>
> If specific bus device-tree node includes the one more clocks,
> when adding the new Exynos SoC, the exynos-bus.c should be added
> for new Exynos SoC. Because, each Exynos SoC has the different
> set of bus device.
>
> If we use my approach, we don't need to modify the exynos-bus.c
> driver to support for the bus frequency of new Exynos SoC.
This won't change. The driver will just support from 1 to N clocks for
given bus device and set the same OPP to all of them. This will only
limit the number of duplicated entries. This won't affect the generic
approach of driver itself.
>>>
>>> You're right aspect of only implementation of device driver.
>>>
>>> But,
>>> If we use your commented approach, we can show the information
>>> of only parent device through sysfs. We cannot see the information
>>> of passive device. The some information includes the current
>>> frequency and correlation of parent device. (But, current patchset
>>> don' include the topology information between parent device and
>>> passive device. I'll do it on later patches).
>>>
>>> For example,
>>> We can see the following bus device through /sys/class/devfreq.
>>>
>>> drwxr-xr-x 2 root root 0 Dec 31 17:00 .
>>> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
>>> ../../devices/platform/bus_display/devfreq/bus_display
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
>>> ../../devices/platform/bus_fsys/devfreq/bus_fsys
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
>>> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
>>> ../../devices/platform/bus_peri/devfreq/bus_peri
>>>
>>>
>>> We don't see the following bus device because of following bus device
>>> has the same frequency table with bus_leftbus device.
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
>>> ../../devices/platform/bus_mfc/devfreq/bus_mfc
>>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
>>> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>>
>> Right, but why do you want to see these bus devices? AFAIU, they will
>
> I think that the framework should show the accurate information of H/w device
> through sysfs. On the exynos-bus.c driver, it is important the sh
Re: [PATCH v2 19/19] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
On 09.12.2015 13:08, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
>
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
> +
> arch/arm/boot/dts/exynos4412-trats2.dts | 47
> +
> 2 files changed, 94 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 171dea1e3e4a..12d08242a179 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -544,3 +544,50 @@
> };
> };
> };
> +
> +&bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>;
> + status = "okay";
> +};
> +
> +&bus_acp {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
> +
> +&bus_c2c {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
> +
> +&bus_leftbus {
> + devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
> + vdd-supply = <&buck3_reg>;
> + status = "okay";
> +};
> +
> +&bus_rightbus {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_display {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_fsys {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_peri {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_mfc {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 40a474c4374b..aecd545803ad 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -1286,3 +1286,50 @@
> vtmu-supply = <&ldo10_reg>;
> status = "okay";
> };
> +
> +&bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>;
> + status = "okay";
> +};
> +
> +&bus_acp {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
> +
> +&bus_c2c {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
> +
> +&bus_leftbus {
> + devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
> + vdd-supply = <&buck3_reg>;
> + status = "okay";
> +};
> +
> +&bus_rightbus {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_display {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_fsys {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_peri {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_mfc {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
The nodes in both files are mostly sorted alphabetically. Could you
place them in such order as well?
Best regards,
Krzysztof
--
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
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 15:53, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:43, Chanwoo Choi wrote:
>> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 15:08, Chanwoo Choi wrote:
On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>> Exynos4x12 has the following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and
>> sub-blocks:
>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>> - ACLK160 clock for CAM/TV/LCD
>> : The minimum clock of ACLK160 should be over 160MHz.
>> When drop the clock under 160MHz, show the broken image.
>> - ACLK133 clock for FSYS
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>> ++
>> 1 file changed, 112 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 3bcf0939755e..8bc4aee156b5 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -354,6 +354,118 @@
>> opp-microvolt = <95>;
>> };
>> };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>
> These two nodes are symmetrical. The MFC below and other buses in other
> DTS share opps. How about changing the binding so multiple clocks could
> be specified at once ("bus0", "bus1")? I think there is no need for a
> bus device for each clock.
The your commented method is possible.
But, I focus on implementing the generic bus frequency driver.
If specific bus device-tree node includes the one more clocks,
when adding the new Exynos SoC, the exynos-bus.c should be added
for new Exynos SoC. Because, each Exynos SoC has the different
set of bus device.
If we use my approach, we don't need to modify the exynos-bus.c
driver to support for the bus frequency of new Exynos SoC.
>>>
>>> This won't change. The driver will just support from 1 to N clocks for
>>> given bus device and set the same OPP to all of them. This will only
>>> limit the number of duplicated entries. This won't affect the generic
>>> approach of driver itself.
>>
>> You're right aspect of only implementation of device driver.
>>
>> But,
>> If we use your commented approach, we can show the information
>> of only parent device through sysfs. We cannot see the information
>> of passive device. The some information includes the current
>> frequency and correlation of parent device. (But, current patchset
>> don' include the topology information between parent device and
>> passive device. I'll do it on later patches).
>>
>> For example,
>> We can see the following bus device through /sys/class/devfreq.
>>
>> drwxr-xr-x 2 root root 0 Dec 31 17:00 .
>> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
>> ../../devices/platform/bus_display/devfreq/bus_display
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
>> ../../devices/platform/bus_fsys/devfreq/bus_fsys
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
>> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
>> ../../devices/platform/bus_peri/devfreq/bus_peri
>>
>>
>> We don't see the following bus device because of following bus device
>> has the same frequency table with bus_leftbus device.
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
>> ../../devices/platform/bus_mfc/devfreq/bus_mfc
>> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
>> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
>
> Right, but why do you want to see these bus devices? AFAIU, they will
I think that the framework should show the accurate information of H/w device
through sysfs. On the exynos-bus.c driver, it is important the show the
accurate set of handled bus devices which are included in Exynos SoC.
> always behave exactly the same as LEFTBUS. Their PPMU coun
Re: [PATCH 05/13] ARM: shmobile: genmai dts: Update console parameters
On Tue, Dec 08, 2015 at 06:54:10PM +0100, Geert Uytterhoeven wrote:
> Change the console alias to "serial0", for consistency with other
> boards (the first unlabeled serial port is always called "serial0").
> Add serial port config to chosen/stdout-path.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> arch/arm/boot/dts/r7s72100-genmai.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r7s72100-genmai.dts
> b/arch/arm/boot/dts/r7s72100-genmai.dts
> index a9da7a89fc4ba65a..47533c2c419e164d 100644
> --- a/arch/arm/boot/dts/r7s72100-genmai.dts
> +++ b/arch/arm/boot/dts/r7s72100-genmai.dts
> @@ -17,12 +17,12 @@
> compatible = "renesas,genmai", "renesas,r7s72100";
>
> aliases {
> - serial2 = &scif2;
> + serial0 = &scif2;
> };
>
> chosen {
> bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
> - stdout-path = &scif2;
> + stdout-path = "serial0:115200n8";
> };
>
> memory {
As noted elsewhere the serial2 -> serial0 portion of
this patch seems to result in no console.
I am wary about that change as it is user-space visible
but I didn't expect it to also have an impact on the kernel console.
In case it helps anyone now or in the future the output with earlyprintk
follows.
-- after with early printk --
[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 4.4.0-rc4-00017-gb298a5a501ed-dirty
(ho...@ayumi.isobedori.kobe.vergenet.net) (gcc version 4.6.3 (GCC) ) #1213 SMP
Thu Dec 10 15:05:11 JST 2015
[0.00] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5307d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: Genmai
[0.00] debug: ignoring loglevel setting.
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 32768
[0.00] free_area_init_node: node 0, pgdat c0829180, node_mem_map
c7ef8000
[0.00] Normal zone: 256 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 32768 pages, LIFO batch:7
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] PERCPU: Embedded 10 pages/cpu @c7ee s17984 r0 d22976 u40960
[0.00] pcpu-alloc: s17984 r0 d22976 u40960 alloc=10*4096
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 32512
[0.00] Kernel command line: console=ttySC2,115200 root=/dev/nfs rw
ip=dhcp ignore_loglevel earlyprintk=sh-sci.2,115200
[0.00] PID hash table entries: 512 (order: -1, 2048 bytes)
[0.00] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.00] Memory: 121208K/131072K available (4976K kernel code, 242K
rwdata, 1360K rodata, 1744K init, 268K bss, 9864K reserved, 0K cma-reserved, 0K
highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xc880 - 0xff80 ( 880 MB)
[0.00] lowmem : 0xc000 - 0xc800 ( 128 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] .text : 0xc0008000 - 0xc063904c (6341 kB)
[0.00] .init : 0xc063a000 - 0xc07ee000 (1744 kB)
[0.00] .data : 0xc07ee000 - 0xc082aa20 ( 243 kB)
[0.00].bss : 0xc082d000 - 0xc0870354 ( 269 kB)
[0.00] Hierarchical RCU implementation.
[0.00] Build-time adjustment of leaf fanout to 32.
[0.00] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=32, nr_cpu_ids=1
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] clocksource_probe: no matching clocksources found
[0.00] sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps
every 2147483647500ns
[0.00] Console: colour dummy device 80x30
[0.00] Calibrating delay loop (skipped) preset value.. 266.66 BogoMIPS
(lpj=133)
[0.00] pid_max: default: 32768 minimum: 301
[0.00] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] CPU: Testing write buffer coherency: ok
[0.00] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.00] Setting up static identity map for 0x8009000 - 0x8009058
[0.00] Brought up 1 CPUs
[0.00] SMP: Total of 1 processors activated (266.66 BogoMIPS).
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] devtmpfs: initialized
[0.00] VFP support v0.3: implementor 41 architecture 3 part 30 variant
9 rev 4
[0.00] c
Re: [PATCH v2 18/19] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
On 09.12.2015 13:08, Chanwoo Choi wrote: > This patch expands the voltage range of buck1/3 regulator due to as following: > - MIF (Memory Interface) bus frequency needs the 9uV ~ 105uV V. > - INT (Internal) bus frequency needs 9uV ~ 100uV. 9->90 and duplicated "uV V". Maybe just: 900 - 1050 mV 900 - 1000 mV ? > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > For the contents of patch: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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
Re: [PATCH 00/13] ARM: shmobile: dts: Update console parameters
On Tue, Dec 08, 2015 at 06:54:05PM +0100, Geert Uytterhoeven wrote: > Hi Simon, Magnus, > > This patch series updates the console parameters in the DTSes for > various Renesas ARM boards. > > - For all of them, the serial port config is added to > chosen/stdout-path, as per current best practices, > - On some boards (armadillo, bockw, kzm9d, kzm9g), "console=" > parameters are removed from the kernel command lines, as they're no > longer needed for DT-only platforms, > - On some boards (genmai, kzm9g), the console alias is changed to > "serial0", for consistency with other boards (the first serial port > is always called "serial0", unless labeled otherwise); this does > mean the device changes its name to /dev/ttySC0 in userspace, which > also happened on R-Car Gen2 before, > - On kzm9d, a console alias is added. > > Tested on r8a73a4/ape6evm, r8a7740/armadillo, r8a7778/bockw, > r8a7779/marzen, r8a7791/koelsch, and sh73a0/kzm9g. > > Thanks for applying! > > Geert Uytterhoeven (13): > ARM: shmobile: alt dts: Add serial port config to chosen/stdout-path > ARM: shmobile: ape6evm dts: Add serial port config to > chosen/stdout-path alt and ape6evm tested ok. I have queued up the changes for those boards. > ARM: shmobile: armadillo800eva dts: Update console parameters I would prefer not to take the serial1 -> serial0 portion of this change at this time as it causes a user-space visible change: the console moves from ttySC1 to ttySC0. I noticed this because I no longer made it all the way to user-space which was expecting a console on ttySC1. -- start before -- [0.05] e6c5.serial: ttySC1 at MMIO 0xe6c5 (irq = 25, base_baud = 0) is a scifa [0.78] console [ttySC1] enabled -- end before -- -- start after -- [0.05] e6c5.serial: ttySC0 at MMIO 0xe6c5 (irq = 25, base_baud = 0) is a scifa [0.78] console [ttySC0] enabled -- end after -- > ARM: shmobile: bockw dts: Update console parameters bockw tested ok. I have queued up the change for that board. > ARM: shmobile: genmai dts: Update console parameters As per my remarks regarding the armadillo800eva I would prefer not to make the serial2 -> serial0 portion of this change. As a bonus the serial2 -> serial0 portion of this change seems to prevent console output during boot too. I've posted some debuging using earlyprintk in reply to this patch in case its useful. > ARM: shmobile: gose dts: Add serial port config to chosen/stdout-path > ARM: shmobile: koelsch dts: Add serial port config to > chosen/stdout-path gose and koelsch tested ok. I have queued up the change for those boards. > ARM: shmobile: kzm9d dts: Update console parameters I am wary of the new serial1 alias. Have you checked to see if there is any user-space visible change as a result of this? > ARM: shmobile: kzm9g dts: Update console parameters As per my remarks regarding the armadillo800eva I would prefer not to make the serial4 -> serial0 portion of this change. > ARM: shmobile: lager dts: Add serial port config to chosen/stdout-path lager tested ok. I have queued up the change for this board. > ARM: shmobile: marzen dts: Add serial port config to > chosen/stdout-path Changing &scif2 to serial0 creates a user-space visible change: the console moves from ttySC2 to ttySC0. I'm unsure how we can update to use the new syntax without encountering this problem. > ARM: shmobile: porter dts: Add serial port config to > chosen/stdout-path > ARM: shmobile: silk dts: Add serial port config to chosen/stdout-path I'm unable to test porter and silk but they look ok to me. I have queued up the changes for those boards. -- 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
Re: [PATCH v2 17/19] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 09.12.2015 13:08, Chanwoo Choi wrote: > This patch adds the bus device-tree node of INT (internal) block > to enable the bus frequency. The following sub-blocks share "to enable the bus frequency scaling" > the VDD_INT power source: > - LEFTBUS (parent device) > - RIGHTBUS > - PERIL > - LCD0 > - FSYS > - MCUISP / ISP > - MFC > > The LEFTBUS is parent device with devfreq ondemand governor > and the rest devices has the dependency on LEFTBUS bus. How about: "and the rest of devices depend on the LEFTBUS device." ? The patch is good: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 10.12.2015 15:43, Chanwoo Choi wrote:
> On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
>> On 10.12.2015 15:08, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
>
> Following list specifies the detailed relation between DRAM and
> sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
> When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 112
> ++
> 1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 3bcf0939755e..8bc4aee156b5 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -354,6 +354,118 @@
> opp-microvolt = <95>;
> };
> };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
These two nodes are symmetrical. The MFC below and other buses in other
DTS share opps. How about changing the binding so multiple clocks could
be specified at once ("bus0", "bus1")? I think there is no need for a
bus device for each clock.
>>>
>>> The your commented method is possible.
>>>
>>> But, I focus on implementing the generic bus frequency driver.
>>>
>>> If specific bus device-tree node includes the one more clocks,
>>> when adding the new Exynos SoC, the exynos-bus.c should be added
>>> for new Exynos SoC. Because, each Exynos SoC has the different
>>> set of bus device.
>>>
>>> If we use my approach, we don't need to modify the exynos-bus.c
>>> driver to support for the bus frequency of new Exynos SoC.
>>
>> This won't change. The driver will just support from 1 to N clocks for
>> given bus device and set the same OPP to all of them. This will only
>> limit the number of duplicated entries. This won't affect the generic
>> approach of driver itself.
>
> You're right aspect of only implementation of device driver.
>
> But,
> If we use your commented approach, we can show the information
> of only parent device through sysfs. We cannot see the information
> of passive device. The some information includes the current
> frequency and correlation of parent device. (But, current patchset
> don' include the topology information between parent device and
> passive device. I'll do it on later patches).
>
> For example,
> We can see the following bus device through /sys/class/devfreq.
>
> drwxr-xr-x 2 root root 0 Dec 31 17:00 .
> drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
> ../../devices/platform/bus_display/devfreq/bus_display
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
> ../../devices/platform/bus_fsys/devfreq/bus_fsys
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
> ../../devices/platform/bus_leftbus/devfreq/bus_leftbus
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
> ../../devices/platform/bus_peri/devfreq/bus_peri
>
>
> We don't see the following bus device because of following bus device
> has the same frequency table with bus_leftbus device.
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
> ../../devices/platform/bus_mfc/devfreq/bus_mfc
> lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
> ../../devices/platform/bus_rightbus/devfreq/bus_rightbus
Right, but why do you want to see these bus devices? AFAIU, they will
always behave exactly the same as LEFTBUS. Their PPMU counters will be
the same... or not? The MFC does not have its own PPMU counter. There
are separate counters for left and right bus... but they are attached to
the "&bus_leftbus" node. The "&bus_rightbus" does not use the PPMU
counter and it follows the parent governor decisions... so this is
purely an artificial creation just to handle one clock.
I just can't see the benefit of such additional bus device.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devi
Re: [PATCH v2 16/19] ARM: dts: Add PPMU node for exynos4412-odroidu3
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
> exynos4412-odroidu3 board. Each PPMU dt node includes one event of
> 'PPMU Count3'.
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 40
> +
> 1 file changed, 40 insertions(+)
>
The patch itself is good but now I see that it is duplicated with
Rinato, Monk and Trats2. Probably for all other Exynos4 and
one-cluster-Exynos5 boards this would be exactly the same as well.
How about making a DTSI file with common PPMU events configuration?
Best regards,
Krzysztof
--
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
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 15:32, Krzysztof Kozlowski wrote:
> On 10.12.2015 15:08, Chanwoo Choi wrote:
>> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>>> On 09.12.2015 13:08, Chanwoo Choi wrote:
This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4x12.dtsi | 112
++
1 file changed, 112 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 3bcf0939755e..8bc4aee156b5 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -354,6 +354,118 @@
opp-microvolt = <95>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
>>>
>>> These two nodes are symmetrical. The MFC below and other buses in other
>>> DTS share opps. How about changing the binding so multiple clocks could
>>> be specified at once ("bus0", "bus1")? I think there is no need for a
>>> bus device for each clock.
>>
>> The your commented method is possible.
>>
>> But, I focus on implementing the generic bus frequency driver.
>>
>> If specific bus device-tree node includes the one more clocks,
>> when adding the new Exynos SoC, the exynos-bus.c should be added
>> for new Exynos SoC. Because, each Exynos SoC has the different
>> set of bus device.
>>
>> If we use my approach, we don't need to modify the exynos-bus.c
>> driver to support for the bus frequency of new Exynos SoC.
>
> This won't change. The driver will just support from 1 to N clocks for
> given bus device and set the same OPP to all of them. This will only
> limit the number of duplicated entries. This won't affect the generic
> approach of driver itself.
You're right aspect of only implementation of device driver.
But,
If we use your commented approach, we can show the information
of only parent device through sysfs. We cannot see the information
of passive device. The some information includes the current
frequency and correlation of parent device. (But, current patchset
don' include the topology information between parent device and
passive device. I'll do it on later patches).
For example,
We can see the following bus device through /sys/class/devfreq.
drwxr-xr-x 2 root root 0 Dec 31 17:00 .
drwxr-xr-x 44 root root 0 Dec 31 17:00 ..
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_display ->
../../devices/platform/bus_display/devfreq/bus_display
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_fsys ->
../../devices/platform/bus_fsys/devfreq/bus_fsys
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_leftbus ->
../../devices/platform/bus_leftbus/devfreq/bus_leftbus
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_peri ->
../../devices/platform/bus_peri/devfreq/bus_peri
We don't see the following bus device because of following bus device
has the same frequency table with bus_leftbus device.
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_mfc ->
../../devices/platform/bus_mfc/devfreq/bus_mfc
lrwxrwxrwx 1 root root 0 Dec 31 17:00 bus_rightbus ->
../../devices/platform/bus_rightbus/devfreq/bus_rightbus
Best Regards,
Chanwoo Choi
--
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
Re: [PATCH v2 4/9] ARM: dts: add dts files for hi3519-demb board
On 2015/12/9 23:31, Arnd Bergmann wrote: > On Tuesday 08 December 2015 11:54:51 xuejiancheng wrote: >> On 2015/12/7 14:37, xuejiancheng wrote: >>> >>> On 2015/12/4 18:49, Arnd Bergmann wrote: On Friday 04 December 2015 10:27:58 xuejiancheng wrote: >> Maybe split out the sysctrl binding from Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt, as it has you already have a couple of those, and it's not clear how they relate to one another. If we introduce a string for all hip04 compatible sysctrl devices, we should document that and use it consistently, so hi3519 becomes compatible = "hisilicon,hi3519-sysctrl", "hisilicon,hip04-sysctrl", "hisilicon,sysctrl"; but I'd clarify in the binding documentation that "hisilicon,sysctrl" should only be used for hip04 and hi3519 but not the others. As this seems to be a standard part, we can also think about making a high-level driver for in in drivers/soc rather than relying on the syscon driver which we tend to use more for one-off devices with random register layouts. >>>Sorry. I didn't understand your meaning well and maybe I gave you a >>> wrong description. >>> Please allow me to clarify it again. >>>The "sysctrl" nodes here is just used for the "reboot" function. It is >>> corresponding to >>> the driver "drivers/power/reset/hisi-reboot.c". The compatible string in >>> the driver is >>> "hisilicon,sysctrl". >>>The layout of this block is also different from the one in HiP04. >> >> I'll use "syscon" as the compatible value for sysctrl node and >> "syscon-reboot" for a new reboot node. >> >> > > This is not what I meant. You have to use "syscon" as the most generic > "compatible" value here, but should add a machine specific string > as a more specific one. "hisilicon,sysctrl" is not appropriate because > it does not identify the IP block uniquely, you can only use that > in combination with another more specific string. OK. I will use "hisilicon,hi3519-syscon" and "syscon" as the compatible value for the sysctrl node in hi3519.dtsi. Thank you! > > That way, we have to option to create a high-level driver for the IP > block later if it turns out that we need some more generic functionality > that is provided by those registers. > > Arnd > > . > -- 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
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 10.12.2015 15:08, Chanwoo Choi wrote:
> On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:08, Chanwoo Choi wrote:
>>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>>> Exynos4x12 has the following AXI buses to translate data between
>>> DRAM and sub-blocks.
>>>
>>> Following list specifies the detailed relation between DRAM and sub-blocks:
>>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>>> - ACLK160 clock for CAM/TV/LCD
>>> : The minimum clock of ACLK160 should be over 160MHz.
>>> When drop the clock under 160MHz, show the broken image.
>>> - ACLK133 clock for FSYS
>>> - GDL clock for LEFTBUS
>>> - GDR clock for RIGHTBUS
>>> - SCLK_MFC clock for MFC
>>>
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>>> ++
>>> 1 file changed, 112 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>>> b/arch/arm/boot/dts/exynos4x12.dtsi
>>> index 3bcf0939755e..8bc4aee156b5 100644
>>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>>> @@ -354,6 +354,118 @@
>>> opp-microvolt = <95>;
>>> };
>>> };
>>> +
>>> + bus_leftbus: bus_leftbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = <&clock CLK_DIV_GDL>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <&bus_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + bus_rightbus: bus_rightbus {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = <&clock CLK_DIV_GDR>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <&bus_leftbus_opp_table>;
>>> + status = "disabled";
>>> + };
>>
>> These two nodes are symmetrical. The MFC below and other buses in other
>> DTS share opps. How about changing the binding so multiple clocks could
>> be specified at once ("bus0", "bus1")? I think there is no need for a
>> bus device for each clock.
>
> The your commented method is possible.
>
> But, I focus on implementing the generic bus frequency driver.
>
> If specific bus device-tree node includes the one more clocks,
> when adding the new Exynos SoC, the exynos-bus.c should be added
> for new Exynos SoC. Because, each Exynos SoC has the different
> set of bus device.
>
> If we use my approach, we don't need to modify the exynos-bus.c
> driver to support for the bus frequency of new Exynos SoC.
This won't change. The driver will just support from 1 to N clocks for
given bus device and set the same OPP to all of them. This will only
limit the number of duplicated entries. This won't affect the generic
approach of driver itself.
Best regards,
Krzysztof
--
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
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 2015년 12월 10일 14:57, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
>> Exynos4x12 has the following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and sub-blocks:
>> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
>> - ACLK160 clock for CAM/TV/LCD
>> : The minimum clock of ACLK160 should be over 160MHz.
>> When drop the clock under 160MHz, show the broken image.
>> - ACLK133 clock for FSYS
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 112
>> ++
>> 1 file changed, 112 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index 3bcf0939755e..8bc4aee156b5 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -354,6 +354,118 @@
>> opp-microvolt = <95>;
>> };
>> };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>
> These two nodes are symmetrical. The MFC below and other buses in other
> DTS share opps. How about changing the binding so multiple clocks could
> be specified at once ("bus0", "bus1")? I think there is no need for a
> bus device for each clock.
The your commented method is possible.
But, I focus on implementing the generic bus frequency driver.
If specific bus device-tree node includes the one more clocks,
when adding the new Exynos SoC, the exynos-bus.c should be added
for new Exynos SoC. Because, each Exynos SoC has the different
set of bus device.
If we use my approach, we don't need to modify the exynos-bus.c
driver to support for the bus frequency of new Exynos SoC.
Best Regards,
Chanwoo Choi
>
> Best regards,
> Krzysztof
>
>> +
>> +bus_display: bus_display {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_ACLK160>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_display_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_fsys: bus_fsys {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_ACLK133>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_fsys_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_peri: bus_peri {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_ACLK100>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_peri_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_mfc: bus_mfc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_SCLK_MFC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_leftbus_opp_table: opp_table3 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <925000>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <95>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_display_opp_table: opp_table4 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <95>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_fsys_opp_table: opp_table5 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +
Re: [PATCH v2 14/19] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
> Exynos4x12 has the following AXI buses to translate data between
> DRAM and sub-blocks.
>
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK100 clock for PERIL/PERIR/MFC(PCLK)
> - ACLK160 clock for CAM/TV/LCD
> : The minimum clock of ACLK160 should be over 160MHz.
> When drop the clock under 160MHz, show the broken image.
> - ACLK133 clock for FSYS
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 112
> ++
> 1 file changed, 112 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 3bcf0939755e..8bc4aee156b5 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -354,6 +354,118 @@
> opp-microvolt = <95>;
> };
> };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
These two nodes are symmetrical. The MFC below and other buses in other
DTS share opps. How about changing the binding so multiple clocks could
be specified at once ("bus0", "bus1")? I think there is no need for a
bus device for each clock.
Best regards,
Krzysztof
> +
> + bus_display: bus_display {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_ACLK160>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_display_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_fsys: bus_fsys {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_ACLK133>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_fsys_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_peri: bus_peri {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_ACLK100>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_peri_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_SCLK_MFC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_leftbus_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_display_opp_table: opp_table4 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <95>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_fsys_opp_table: opp_table5 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <925000>;
> + };
> + };
> +
> + bus_peri_opp_table: opp_table6 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
[PATCH 3/3] arm: dts: rockchip: move the public part to rk3288-evb common
Rk3288-evb-act8846 and rk3288-evb-rk808 are the power boards of
rk3288-evb, they provide the same power supply interface to the
motherboard. Sort out them, put the public part to rk3288-evb.dtsi,
such as gmac and cpu-supply, leaving only the power section.
Signed-off-by: Chris Zhong
---
arch/arm/boot/dts/rk3288-evb-act8846.dts | 4
arch/arm/boot/dts/rk3288-evb-rk808.dts | 27 ---
arch/arm/boot/dts/rk3288-evb.dtsi| 37 +++-
3 files changed, 32 insertions(+), 36 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 7b768b7..e662147 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -65,10 +65,6 @@
};
};
-&cpu0 {
- cpu0-supply = <&vdd_cpu>;
-};
-
&i2c0 {
clock-frequency = <40>;
diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts
b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index 18eb6cb..736b08b 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -43,17 +43,6 @@
/ {
compatible = "rockchip,rk3288-evb-rk808", "rockchip,rk3288";
-
- ext_gmac: external-gmac-clock {
- compatible = "fixed-clock";
- clock-frequency = <12500>;
- clock-output-names = "ext_gmac";
- #clock-cells = <0>;
- };
-};
-
-&cpu0 {
- cpu0-supply = <&vdd_cpu>;
};
&i2c0 {
@@ -244,19 +233,3 @@
};
};
};
-
-&gmac {
- phy-supply = <&vcc_phy>;
- phy-mode = "rgmii";
- clock_in_out = "input";
- snps,reset-gpio = <&gpio4 7 0>;
- snps,reset-active-low;
- snps,reset-delays-us = <0 1 100>;
- assigned-clocks = <&cru SCLK_MAC>;
- assigned-clock-parents = <&ext_gmac>;
- pinctrl-names = "default";
- pinctrl-0 = <&rgmii_pins>;
- tx_delay = <0x30>;
- rx_delay = <0x10>;
- status = "ok";
-};
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index f6d2e78..4faabdb 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -89,6 +89,13 @@
pwms = <&pwm0 0 100 PWM_POLARITY_INVERTED>;
};
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "ext_gmac";
+ #clock-cells = <0>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
#address-cells = <1>;
@@ -160,6 +167,10 @@
};
};
+&cpu0 {
+ cpu0-supply = <&vdd_cpu>;
+};
+
&emmc {
broken-cd;
bus-width = <8>;
@@ -172,11 +183,6 @@
status = "okay";
};
-&hdmi {
- ddc-i2c-bus = <&i2c5>;
- status = "okay";
-};
-
&sdmmc {
bus-width = <4>;
cap-mmc-highspeed;
@@ -191,6 +197,27 @@
vqmmc-supply = <&vccio_sd>;
};
+&gmac {
+ phy-supply = <&vcc_phy>;
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+ snps,reset-gpio = <&gpio4 7 0>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 1 100>;
+ assigned-clocks = <&cru SCLK_MAC>;
+ assigned-clock-parents = <&ext_gmac>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ tx_delay = <0x30>;
+ rx_delay = <0x10>;
+ status = "ok";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c5>;
+ status = "okay";
+};
+
&i2c0 {
status = "okay";
};
--
2.6.3
--
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
[PATCH 2/3] ARM: dts: rockchip: add 2 regulators for rk3288-evb-act8846
vcc_wl and vcc_lcd are 2 gpio switches for rk3288-evb-act8846 board.
Signed-off-by: Chris Zhong
---
arch/arm/boot/dts/rk3288-evb-act8846.dts | 34
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 53d8b08..7b768b7 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -43,6 +43,26 @@
/ {
compatible = "rockchip,rk3288-evb-act8846", "rockchip,rk3288";
+
+ vcc_lcd: vcc-lcd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio7 3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_en>;
+ regulator-name = "vcc_lcd";
+ vin-supply = <&vcc_io>;
+ };
+
+ vcc_wl: vcc-wl {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio7 9 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_pwr>;
+ regulator-name = "vcc_wl";
+ vin-supply = <&vcc_18>;
+ };
};
&cpu0 {
@@ -189,3 +209,17 @@
};
};
};
+
+&pinctrl {
+ lcd {
+ lcd_en: lcd-en {
+ rockchip,pins = <7 3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wifi {
+ wifi_pwr: wifi-pwr {
+ rockchip,pins = <7 9 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
--
2.6.3
--
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
[PATCH 1/3] ARM: dts: rockchip: correct the name of REG8 for rk3288-evb-act8846
According to the schematic, the name of REG8 should be vcc_tp, rather
than vcca_tp.
Signed-off-by: Chris Zhong
---
arch/arm/boot/dts/rk3288-evb-act8846.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-evb-act8846.dts
b/arch/arm/boot/dts/rk3288-evb-act8846.dts
index 43949a6..53d8b08 100644
--- a/arch/arm/boot/dts/rk3288-evb-act8846.dts
+++ b/arch/arm/boot/dts/rk3288-evb-act8846.dts
@@ -152,7 +152,7 @@
regulator-always-on;
};
- vcca_tp: REG8 {
+ vcc_tp: REG8 {
regulator-name = "VCCA_TP";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
--
2.6.3
--
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
[PATCH v2 0/2] usb: renesas_usbhs: More compat strings
Hi, this short series adds generic, and soc-specific r8a7792 and r8a7793 compat strings to the Renesas USBHS driver. The intention is to provide a complete set of compat strings for known R-Car SoCs. Changes since v1: * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than a single compatibility string for all of R-Car. *** BLURB HERE *** Simon Horman (2): usb: renesas_usbhs: add fallback compatibility strings usb: renesas_usbhs: add device tree support for r8a779[23] .../devicetree/bindings/usb/renesas_usbhs.txt| 20 +++- drivers/usb/renesas_usbhs/common.c | 9 + 2 files changed, 24 insertions(+), 5 deletions(-) -- 2.1.4 -- 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
[PATCH v2 1/2] usb: renesas_usbhs: add fallback compatibility strings
Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Also add SoC names.
Signed-off-by: Simon Horman
---
v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
a single compatibility string for all of R-Car.
---
.../devicetree/bindings/usb/renesas_usbhs.txt | 18 +-
drivers/usb/renesas_usbhs/common.c | 9 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index 7d48f63db44e..b959059826cd 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver
Required properties:
- compatible: Must contain one of the following:
- - "renesas,usbhs-r8a7790"
- - "renesas,usbhs-r8a7791"
- - "renesas,usbhs-r8a7794"
- - "renesas,usbhs-r8a7795"
+
+ - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
+ - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
+ - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
+ - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
+ - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatibile device
+ - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatibile device
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: Base address and length of the register for the USBHS
- interrupts: Interrupt specifier for the USBHS
- clocks: A list of phandle + clock specifier pairs
@@ -22,7 +30,7 @@ Optional properties:
Example:
usbhs: usb@e659 {
- compatible = "renesas,usbhs-r8a7790";
+ compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..db9a17bd8997 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+ {
+ .compatible = "renesas,rcar-gen2-usbhs",
+ .data = (void *)USBHS_TYPE_RCAR_GEN2,
+ },
+ {
+ /* Gen3 is compatible with Gen2 */
+ .compatible = "renesas,rcar-gen3-usbhs",
+ .data = (void *)USBHS_TYPE_RCAR_GEN2,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, usbhs_of_match);
--
2.1.4
--
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
[PATCH v2 2/2] usb: renesas_usbhs: add device tree support for r8a779[23]
Simply document new compatibility string. As a previous patch adds a generic R-Car Gen2 compatibility string there appears to be no need for a driver updates. Signed-off-by: Simon Horman Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index b959059826cd..efb3199a2a80 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -5,6 +5,8 @@ Required properties: - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device + - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device + - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatibile device -- 2.1.4 -- 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
Re: [PATCH v4 4/5] ARM: dts: DRA7: add entry for qspi mmap region
On 12/03/2015 03:51 PM, Vignesh R wrote:
>
>
> On 12/01/2015 10:09 PM, Tony Lindgren wrote:
>> * Vignesh R [151130 20:46]:
>>> On 12/01/2015 04:04 AM, Tony Lindgren wrote:
...
>>
>> OK. They are both on L3 main so that won't cause any issues for separate
>> interconnect driver instances. As they are still separate targets flushing
>> a posted write to one area will not flush anything to the other.
>>
>
> I didn't quite understand what you meant by interconnect driver instance.
> qspi_base and qspi_mmap region are tightly bound to each other and both
> needs to be accessed by ti-qspi driver (though different targets).
> Besides qspi_mmap region is only used to read data, there will not be
> any write accesses to this target. Are you saying this binding is not
> viable?
>
As I stated above qspi_base and qspi_mmap region are tightly bound,
there is no way to use qspi_mmap region w/o accessing qspi_base. So I am
planning to keep them as it is. I will move qspi_ctrlmod to use syscon.
Something like:
qspi: qspi@4b30 {
compatible = "ti,dra7xxx-qspi";
reg = <0x4b30 0x100>,
<0x5c00 0x400>,
reg-names = "qspi_base", "qspi_mmap";
syscon-chipselects = <&scm_conf 0x558>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <4800>;
ti,hwmods = "qspi";
};
Do you think this is not viable in future?
--
Regards
Vignesh
--
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
Re: [PATCH 0/8 v4] enable to use thermal-zone on r8a7790/1
On Tue, Dec 08, 2015 at 05:26:20AM +, Kuninori Morimoto wrote: > > Hi > > These are v4 of thermal-zone support for r8a7790/r8a7791. > Mainly, it cares return value of get_temp() > > I think 8) is needed on of-thermal (?) > > Kuninori Morimoto (8): > 1) thermal: rcar: move rcar_thermal_dt_ids to upside > 2) thermal: rcar: check every rcar_thermal_update_temp() return value > 3) thermal: rcar: check irq possibility in rcar_thermal_irq_xxx() > 4) thermal: rcar: retern error rcar_thermal_get_temp() if no ctemp > update > 5) thermal: rcar: enable to use thermal-zone on DT > 6) ARM: shmobile: r8a7790: enable to use thermal-zone > 7) ARM: shmobile: r8a7791: enable to use thermal-zone > 8) thermal: of-thermal: of_thermal_set_trip_temp() call > thermal_zone_device_update() > I have marked patches 6 and 7 as deferred pending acceptance of the driver changes. -- 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
Re: [PATCH v2 13/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12
On 2015년 12월 10일 12:17, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
>
> s/noes/nodes/
OK.
>
>> Exynos4x12 has the following AXI buses to translate data
>> between DRAM and DMC/ACP/C2C.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4x12.dtsi | 72
>> +++
>> 1 file changed, 72 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
>> b/arch/arm/boot/dts/exynos4x12.dtsi
>> index b77dac61ffb5..3bcf0939755e 100644
>> --- a/arch/arm/boot/dts/exynos4x12.dtsi
>> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
>> @@ -282,6 +282,78 @@
>> clocks = <&clock CLK_SMMU_LITE1>, <&clock CLK_FIMC_LITE1>;
>> #iommu-cells = <0>;
>> };
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_acp: bus_acp {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_DIV_ACP>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_acp_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_c2c: bus_c2c {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&clock CLK_DIV_C2C>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table1 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <90>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <16000>;
>> +opp-microvolt = <90>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <95>;
>
> The exyno4_bus.c (from mainline) uses 267 MHz here. Why choosing 200 MHz?
There is no special reason.
I'll change it (200MHz -> 267MHz).
Best Regards,
Chanwoo Choi
--
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
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Anand,
On 2015년 12월 10일 13:14, Anand Moon wrote:
> Hi Chanwoo Choi,
>
> On 10 December 2015 at 05:42, Chanwoo Choi wrote:
>> Hi Anand,
>>
>> First of all, thanks for trying to test this series.
>>
>> On 2015년 12월 10일 04:05, Anand Moon wrote:
>>> Hi Chanwoo Choi,
>>>
>>> On 9 December 2015 at 09:37, Chanwoo Choi wrote:
This patch-set includes the two features as following. The generic exynos
bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the
patch-set[1]
with the similiar concept. This is is revised version for exynos bus
frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework
Depends on:
- This patch-set is based on devfreq.git[2].
[1] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
[2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
for-rafael)
Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
when executing regulator_disable() because of only parent
devfreq device has the regulator instance. After fixing it,
the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3
Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.
There are the different buses according to Exynos SoC because Exynos SoC
has the differnt sub-blocks and bus speed. In spite of this difference
among Exynos SoCs, this driver is able to support almost Exynos SoC by
adding
unique data of each bus in the devicetree file.
In devicetree, each bus node has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
For example,
- The bus of DMC block in exynos3250.dtsi are listed below:
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
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 <13400>;
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>;
vdd-supply = <&buck1_reg>; /* VDD_MIF */
status = "okay";
};
2. Add new passive governor of DEVFREQ framework (patch5-patch7)
: This patch-set add the new passive governor for DEVFREQ framework.
The existing governors (ondemand, performance and so on) are used for DVFS
(Dynamic Voltage and Frequency Scaling) drivers. The existing governors
are independently used for specific device driver which don't
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Chanwoo Choi,
On 10 December 2015 at 05:42, Chanwoo Choi wrote:
> Hi Anand,
>
> First of all, thanks for trying to test this series.
>
> On 2015년 12월 10일 04:05, Anand Moon wrote:
>> Hi Chanwoo Choi,
>>
>> On 9 December 2015 at 09:37, Chanwoo Choi wrote:
>>> This patch-set includes the two features as following. The generic exynos
>>> bus
>>> frequency driver is able to support almost Exynos SoCs for bus frequency
>>> scaling. And the new passive governor is able to make the dependency on
>>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>>> with the similiar concept. This is is revised version for exynos bus
>>> frequency.
>>> - Generic exynos bus frequency driver
>>> - New passive governor of DEVFREQ framework
>>>
>>> Depends on:
>>> - This patch-set is based on devfreq.git[2].
>>> [1] https://lkml.org/lkml/2015/1/7/872
>>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
>>> for-rafael)
>>>
>>> Changes from v1:
>>> (https://lkml.org/lkml/2015/11/26/260)
>>> - Check whether the instance of regulator is NULL or not
>>> when executing regulator_disable() because of only parent
>>> devfreq device has the regulator instance. After fixing it,
>>> the wake-up from suspend state is well working. (patch1)
>>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>>> after calling devm_clk_get() (on patch1)
>>> - Update the documentation to remove the description about
>>> DEVFREQ-EVENT subsystem (on patch2)
>>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>>> - Modify the detailed correlation of buses for Exynos3250
>>> on documentation (patch2)
>>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>>> - Add the PPMU node for exynos4412-odroidu3
>>> - Add the support of bus frequency for exynos4412-odroidu3
>>>
>>> Detailed descirption for patch-set:
>>> 1. Add generic exynos bus frequency driver
>>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>>> architecture for bus between DRAM and sub-blocks in SoC.
>>>
>>> There are the different buses according to Exynos SoC because Exynos SoC
>>> has the differnt sub-blocks and bus speed. In spite of this difference
>>> among Exynos SoCs, this driver is able to support almost Exynos SoC by
>>> adding
>>> unique data of each bus in the devicetree file.
>>>
>>> In devicetree, each bus node has a bus clock, regulator, operation-point
>>> and devfreq-event devices which measure the utilization of each bus block.
>>>
>>> For example,
>>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>>
>>> bus_dmc: bus_dmc {
>>> compatible = "samsung,exynos-bus";
>>> 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 <13400>;
>>> 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>;
>>> vdd-supply = <&buck1_reg>; /* VDD_MIF */
>>> status = "okay";
>>> };
>>>
>>> 2. Add new passive governor of DEVFREQ framework (patch5-patch7)
>>> : This patch-set add the new passive governor for DEVFREQ framework.
>>> The existing governors (ondemand, performance and so on) are used for DVFS
>>> (Dynamic Voltage and Frequency Scaling) drivers. The existing governors
>>> are independently used for specific device driver which don't give the
>>> influence to other device drviers and also don't receive the effect from
>>> other device drivers.
>>>
>>> The passive governor depends on operation of parent
[PATCH v4 3/5] misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.
This commit implements bindings in the eeprom_93xx46 driver allowing
device word size and read-only attributes to be specified via
devicetree.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
---
drivers/misc/eeprom/eeprom_93xx46.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index e1bf0a5..cc27e11 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -13,6 +13,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -294,12 +296,58 @@ static ssize_t eeprom_93xx46_store_erase(struct device
*dev,
}
static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
+static const struct of_device_id eeprom_93xx46_of_table[] = {
+ { .compatible = "eeprom-93xx46", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+
+static int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+ struct device_node *np = spi->dev.of_node;
+ struct eeprom_93xx46_platform_data *pd;
+ u32 tmp;
+ int ret;
+
+ pd = devm_kzalloc(&spi->dev, sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+
+ ret = of_property_read_u32(np, "data-size", &tmp);
+ if (ret < 0) {
+ dev_err(&spi->dev, "data-size property not found\n");
+ return ret;
+ }
+
+ if (tmp == 8) {
+ pd->flags |= EE_ADDR8;
+ } else if (tmp == 16) {
+ pd->flags |= EE_ADDR16;
+ } else {
+ dev_err(&spi->dev, "invalid data-size (%d)\n", tmp);
+ return -EINVAL;
+ }
+
+ if (of_property_read_bool(np, "read-only"))
+ pd->flags |= EE_READONLY;
+
+ spi->dev.platform_data = pd;
+
+ return 0;
+}
+
static int eeprom_93xx46_probe(struct spi_device *spi)
{
struct eeprom_93xx46_platform_data *pd;
struct eeprom_93xx46_dev *edev;
int err;
+ if (spi->dev.of_node) {
+ err = eeprom_93xx46_probe_dt(spi);
+ if (err < 0)
+ return err;
+ }
+
pd = spi->dev.platform_data;
if (!pd) {
dev_err(&spi->dev, "missing platform data\n");
@@ -370,6 +418,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
static struct spi_driver eeprom_93xx46_driver = {
.driver = {
.name = "93xx46",
+ .of_match_table = of_match_ptr(eeprom_93xx46_of_table),
},
.probe = eeprom_93xx46_probe,
.remove = eeprom_93xx46_remove,
--
2.4.10
--
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
[PATCH v4 5/5] misc: eeprom_93xx46: Add support for a GPIO 'select' line.
This commit adds support to the eeprom_93x46 driver allowing a GPIO line
to function as a 'select' or 'enable' signal prior to accessing the
EEPROM.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
---
drivers/misc/eeprom/eeprom_93xx46.c | 35 +++
include/linux/eeprom_93xx46.h | 3 +++
2 files changed, 38 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index d50bc17..d28fac2 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -10,11 +10,13 @@
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -343,6 +345,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device
*dev,
}
static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
+static void select_assert(void *context)
+{
+ struct eeprom_93xx46_dev *edev = context;
+
+ gpiod_set_value_cansleep(edev->pdata->select, 1);
+}
+
+static void select_deassert(void *context)
+{
+ struct eeprom_93xx46_dev *edev = context;
+
+ gpiod_set_value_cansleep(edev->pdata->select, 0);
+}
+
static const struct of_device_id eeprom_93xx46_of_table[] = {
{ .compatible = "eeprom-93xx46", },
{ .compatible = "atmel,at93c46d", .data = &atmel_at93c46d_data, },
@@ -357,6 +373,8 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
struct device_node *np = spi->dev.of_node;
struct eeprom_93xx46_platform_data *pd;
u32 tmp;
+ int gpio;
+ enum of_gpio_flags of_flags;
int ret;
pd = devm_kzalloc(&spi->dev, sizeof(*pd), GFP_KERNEL);
@@ -381,6 +399,23 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
if (of_property_read_bool(np, "read-only"))
pd->flags |= EE_READONLY;
+ gpio = of_get_named_gpio_flags(np, "select-gpios", 0, &of_flags);
+ if (gpio_is_valid(gpio)) {
+ unsigned long flags =
+ of_flags == OF_GPIO_ACTIVE_LOW ? GPIOF_ACTIVE_LOW : 0;
+
+ ret = devm_gpio_request_one(&spi->dev, gpio, flags,
+ "eeprom_93xx46_select");
+ if (ret)
+ return ret;
+
+ pd->select = gpio_to_desc(gpio);
+ pd->prepare = select_assert;
+ pd->finish = select_deassert;
+
+ gpiod_direction_output(pd->select, 0);
+ }
+
if (of_id->data) {
const struct eeprom_93xx46_devtype_data *data = of_id->data;
diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
index 92fa4c3..03f3435 100644
--- a/include/linux/eeprom_93xx46.h
+++ b/include/linux/eeprom_93xx46.h
@@ -3,6 +3,8 @@
* platform description for 93xx46 EEPROMs.
*/
+#include
+
struct eeprom_93xx46_platform_data {
unsigned char flags;
#define EE_ADDR8 0x01/* 8 bit addr. cfg */
@@ -21,4 +23,5 @@ struct eeprom_93xx46_platform_data {
*/
void (*prepare)(void *);
void (*finish)(void *);
+ struct gpio_desc *select;
};
--
2.4.10
--
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
[PATCH v4 4/5] misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.
Atmel devices in this family have some quirks not found in other similar
chips - they do not support a sequential read of the entire EEPROM
contents, and the control word sent at the start of each operation
varies in bit length.
This commit adds quirk support to the driver and modifies the read
implementation to support non-sequential reads for consistency with
other misc/eeprom drivers.
Tested on a custom Freescale VF610-based platform, with an AT93C46D
device attached via dspi2. The spi-gpio driver was used to allow the
necessary non-byte-sized transfers.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
---
drivers/misc/eeprom/eeprom_93xx46.c | 126 ++--
include/linux/eeprom_93xx46.h | 6 ++
2 files changed, 97 insertions(+), 35 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index cc27e11..d50bc17 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -27,6 +27,15 @@
#define ADDR_ERAL 0x20
#define ADDR_EWEN 0x30
+struct eeprom_93xx46_devtype_data {
+ unsigned int quirks;
+};
+
+static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
+ .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
+ EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
+};
+
struct eeprom_93xx46_dev {
struct spi_device *spi;
struct eeprom_93xx46_platform_data *pdata;
@@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
int addrlen;
};
+static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
+{
+ return edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ;
+}
+
+static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev *edev)
+{
+ return edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH;
+}
+
static ssize_t
eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
struct bin_attribute *bin_attr,
@@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
*kobj,
{
struct eeprom_93xx46_dev *edev;
struct device *dev;
- struct spi_message m;
- struct spi_transfer t[2];
- int bits, ret;
- u16 cmd_addr;
+ ssize_t ret = 0;
dev = container_of(kobj, struct device, kobj);
edev = dev_get_drvdata(dev);
- cmd_addr = OP_READ << edev->addrlen;
+ mutex_lock(&edev->lock);
- if (edev->addrlen == 7) {
- cmd_addr |= off & 0x7f;
- bits = 10;
- } else {
- cmd_addr |= (off >> 1) & 0x3f;
- bits = 9;
- }
+ if (edev->pdata->prepare)
+ edev->pdata->prepare(edev);
- dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
- cmd_addr, edev->spi->max_speed_hz);
+ while (count) {
+ struct spi_message m;
+ struct spi_transfer t[2] = { { 0 } };
+ u16 cmd_addr = OP_READ << edev->addrlen;
+ size_t nbytes = count;
+ int bits;
+ int err;
+
+ if (edev->addrlen == 7) {
+ cmd_addr |= off & 0x7f;
+ bits = 10;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 1;
+ } else {
+ cmd_addr |= (off >> 1) & 0x3f;
+ bits = 9;
+ if (has_quirk_single_word_read(edev))
+ nbytes = 2;
+ }
- spi_message_init(&m);
- memset(t, 0, sizeof(t));
+ dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
+ cmd_addr, edev->spi->max_speed_hz);
- t[0].tx_buf = (char *)&cmd_addr;
- t[0].len = 2;
- t[0].bits_per_word = bits;
- spi_message_add_tail(&t[0], &m);
+ spi_message_init(&m);
- t[1].rx_buf = buf;
- t[1].len = count;
- t[1].bits_per_word = 8;
- spi_message_add_tail(&t[1], &m);
+ t[0].tx_buf = (char *)&cmd_addr;
+ t[0].len = 2;
+ t[0].bits_per_word = bits;
+ spi_message_add_tail(&t[0], &m);
- mutex_lock(&edev->lock);
+ t[1].rx_buf = buf;
+ t[1].len = count;
+ t[1].bits_per_word = 8;
+ spi_message_add_tail(&t[1], &m);
- if (edev->pdata->prepare)
- edev->pdata->prepare(edev);
+ err = spi_sync(edev->spi, &m);
+ /* have to wait at least Tcsl ns */
+ ndelay(250);
- ret = spi_sync(edev->spi, &m);
- /* have to wait at least Tcsl ns */
- ndelay(250);
- if (ret) {
- dev_err(&edev->spi->dev, "read %zu bytes at %d: err. %d\n",
- count, (int)off, ret);
+ if (err) {
+ dev_err(&edev->spi->dev, "read %zu bytes
[PATCH v4 2/5] Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver.
This commit documents bindings to be added to the eeprom_93xx46 driver
which will allow:
- Device word size and read-only attributes to be specified.
- A device-specific compatible string for use with Atmel AT93C46D
EEPROMs.
- Specifying a GPIO line to function as a 'select' or 'enable' signal
prior to accessing the EEPROM.
Signed-off-by: Cory Tusar
Acked-by: Rob Herring
Tested-by: Chris Healy
---
.../devicetree/bindings/misc/eeprom-93xx46.txt | 25 ++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
new file mode 100644
index 000..a8ebb46
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -0,0 +1,25 @@
+EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
+
+Required properties:
+- compatible : shall be one of:
+"atmel,at93c46d"
+"eeprom-93xx46"
+- data-size : number of data bits per word (either 8 or 16)
+
+Optional properties:
+- read-only : parameter-less property which disables writes to the EEPROM
+- select-gpios : if present, specifies the GPIO that will be asserted prior to
+ each access to the EEPROM (e.g. for SPI bus multiplexing)
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+
+Example:
+ eeprom@0 {
+ compatible = "eeprom-93xx46";
+ reg = <0>;
+ spi-max-frequency = <100>;
+ spi-cs-high;
+ data-size = <8>;
+ select-gpios = <&gpio4 4 GPIO_ACTIVE_HIGH>;
+ };
--
2.4.10
--
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
[PATCH v4 0/5] Devicetree support for misc/eeprom/eeprom_93xx46.
This series of patches adds an initial set of devicetree bindings to the eeprom_93xx46 driver which mirror the configuration options previously available as a platform device. These bindings are then extended to include support for specific Atmel devices in this family and also to support GPIO-based selection of the device (e.g. for use with an SPI bus mux). Additionally, an address aliasing issue with 16-bit read and write accesses in the eeprom_93xx46 driver discovered during testing is fixed. Changes since v3: - Tested-by: Chris Healy ...on a separate i.MX51 platform with Microchip 93LC46A EEPROM. Changes since v2: - Changed node name to 'eeprom' in DT bindings example. - Simplified several bits of return logic. - Removed #ifdef CONFIG_OF. - Allow compiler to handle promotion to bool return values. - Reworked GPIO handling to use gpiod_* functions throughout (and fixed an oversight where GPIO flags were being ignored). Changes since v1: - Consolidated all Documentation/devictree additions into a single patch. - Clarified compatible string shall be only one of the supported values. - Renamed the 'select-gpio' binding to 'select-gpios'. Cory Tusar (5): misc: eeprom_93xx46: Fix 16-bit read and write accesses. Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver. misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings. misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device. misc: eeprom_93xx46: Add support for a GPIO 'select' line. .../devicetree/bindings/misc/eeprom-93xx46.txt | 25 +++ drivers/misc/eeprom/eeprom_93xx46.c| 212 + include/linux/eeprom_93xx46.h | 9 + 3 files changed, 210 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt -- 2.4.10 -- 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
[PATCH v4 1/5] misc: eeprom_93xx46: Fix 16-bit read and write accesses.
Compatible at93xx46 devices from both Microchip and Atmel expect a
word-based address, regardless of whether the device is strapped for 8-
or 16-bit operation. However, the offset parameter passed in when
reading or writing at a specific location is always specified in terms
of bytes.
This commit fixes 16-bit read and write accesses by shifting the offset
parameter to account for this difference between a byte offset and a
word-based address.
Signed-off-by: Cory Tusar
Tested-by: Chris Healy
---
drivers/misc/eeprom/eeprom_93xx46.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
b/drivers/misc/eeprom/eeprom_93xx46.c
index ff63f05..e1bf0a5 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -54,7 +54,7 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject
*kobj,
cmd_addr |= off & 0x7f;
bits = 10;
} else {
- cmd_addr |= off & 0x3f;
+ cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
}
@@ -155,7 +155,7 @@ eeprom_93xx46_write_word(struct eeprom_93xx46_dev *edev,
bits = 10;
data_len = 1;
} else {
- cmd_addr |= off & 0x3f;
+ cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
data_len = 2;
}
--
2.4.10
--
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
Re: [PATCH v2] dmaengine: usb-dmac: Document SoC specific compatibility strings
On Wed, Dec 02, 2015 at 02:53:54PM +0900, Simon Horman wrote: > In general Renesas hardware is not documented to the extent where the > relationship between IP blocks on different SoCs can be assumed although > they may appear to operate the same way. Furthermore the documentation > typically does not specify a version for individual IP blocks. For these > reasons a convention of using the SoC name in place of a version and > providing SoC-specific compatibility strings has been adopted. > > Although not universally liked this convention is used in the bindings for > most drivers for Renesas hardware. The purpose of this patch is to > update the Renesas USB DMA Controller driver to follow this convention. Applied, thanks -- ~Vinod -- 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
Re: [PATCH v2 13/19] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
s/noes/nodes/
> Exynos4x12 has the following AXI buses to translate data
> between DRAM and DMC/ACP/C2C.
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 72
> +++
> 1 file changed, 72 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index b77dac61ffb5..3bcf0939755e 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -282,6 +282,78 @@
> clocks = <&clock CLK_SMMU_LITE1>, <&clock CLK_FIMC_LITE1>;
> #iommu-cells = <0>;
> };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_acp: bus_acp {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_ACP>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_acp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_c2c: bus_c2c {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_C2C>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <90>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <90>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <95>;
The exyno4_bus.c (from mainline) uses 267 MHz here. Why choosing 200 MHz?
Best regards,
Krzysztof
--
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
Re: [PATCH v5 0/4] stmmac: Fixed Phy & PTP fixes
Please fix the date and time on your computer. -- 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
Re: [GIT PULL for 4.4] DT/dmaengine: edma: Update for the new bindings
On Wed, Dec 09, 2015 at 01:10:18PM +0200, Peter Ujfalusi wrote: > Hi Arnd, Vinod, > > As Arnd suggested, the two patch from the following series: > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122201.html > > plus Acked-by from Arnd is available for pull if you prefer that way. Sorry saw this after I pushed out the fixes/edma.. > > > Regards, > Péter > > The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec: > > Linux 4.4-rc1 (2015-11-15 17:00:27 -0800) > > are available in the git repository at: > > https://github.com/omap-audio/linux-audio.git > for-4.4/peter/edma_binding_update > > for you to fetch changes up to af9089852e0ecd6ae7336992d29b04d7d82b404a: > > dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type > (2015-12-09 11:56:56 +0200) > > > Peter Ujfalusi (2): > dmaengine: edma: DT: Change memcpy channel array from 16bit to 32bit > type > dmaengine: edma: DT: Change reserved slot array from 16bit to 32bit type > > Documentation/devicetree/bindings/dma/ti-edma.txt | 10 -- > drivers/dma/edma.c| 53 > +++-- > include/linux/platform_data/edma.h| 2 +- > 3 files changed, 40 insertions(+), 25 deletions(-) -- ~Vinod -- 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
Re: [PATCH for 4.4 0/2] DT/dmaengine: edma: Convert 16bit arrays to 32bit
On Wed, Dec 09, 2015 at 12:12:27PM -0800, Tony Lindgren wrote: > * Peter Ujfalusi [151209 00:19]: > > Hi, > > > > Based on the discussion regarding to (convert am33xx to use the new eDMA > > bindings): > > https://www.mail-archive.com/linux-omap@vger.kernel.org/msg122117.html > > > > This two patch will convert the new eDMA binding to not use 16bit arrays for > > memcpy channel selection and for marking slots reserved. > > The '/bits/ 16' seams to be causing confusion so it is probably better to > > just > > use standard type for the arrays. > > > > The new bindings for the eDMA is introduced for 4.4 and we do not have > > users of > > it, which means that we can still change it w/o the risk of breaking > > anything > > and we do not need to maintain the compatibility with 16bit arrays. > > > > The changes in the eDMA driver is local to the DT parsing and should not > > conflict with other changes (like the filter function mapping support). Hrm, > > there might be trivial conflict in the include/linux/platform_data/edma.h > > with > > the "dmaengine 'universal' API". > > > > Tony, Arnd, Vinod: Can you agree on the practicalities on how these patches > > are > > going to be handled? I would like to send the updated am33xx/am437x > > conversion > > for 4.5 based on these changes. > > Yes this should go into v4.4 as discussed, otherwise it will be a mess. > For both, please feel free to add: > > Acked-by: Tony Lindgren > > I suggest Vinod sets up an immutable branch against v4.4-rc1 with just these > two patches. Then it can get merged into whichever branch needs it, I > certainly will need it as most of my v4.5 branches are v4.4-rc1 or -rc2 > based. > > Then the immutable branch can be merged into v4.4 by Vinod or Arnd. Applied to fix/edma. This is based on -rc1 and will not rebase. I am merging this to my fixes and will send to Linus in couple of days Thanks -- ~Vinod -- 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
Re: [PATCH 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701
On Wed, 2015-12-09 at 23:52 +0100, Linus Walleij wrote: > On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > > > Add mt2701 support using mediatek common pinctrl driver. > > MT2701 have some special pins need an extra setting register > > than other ICs, so adding this support to common code. > > > > Signed-off-by: Biao Huang > > This looks uncontroversial, but I would like to have some of the > other Mediatek driver authors send their Ack/Review tags, > so Hongzhou & Yingjoe: can you review this and the other > patch to the pin control driver? The v2 patch will be sent in next week, and there are some changes in mt2701 drivers. And I'll add Hongzhou & Yingjoe to review these patches. > > Yours, > Linus Walleij -- 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
Re: [PATCH linux-next (v2) 1/3] mtd: brcmnand: Add brcm,bcm6368-nand device tree binding
On Wed, Dec 09, 2015 at 01:01:42PM -0800, Florian Fainelli wrote:
> Le 09/12/2015 12:40, Simon Arlott a écrit :
> > Add device tree binding for NAND on the BCM6368.
> >
> > The BCM6368 has a NAND interrupt register with combined status and enable
> > registers. It also requires a clock, so add an optional clock to the
> > common brcmnand binding.
> >
>
> Reviewed-by: Florian Fainelli
Applied this and patches 2 and 3 to l2-mtd.git, with one small fix,
below.
> > Signed-off-by: Simon Arlott
> > ---
> > Changed "nand-intr-base" reg name to "nand-int-base".
> >
> > .../devicetree/bindings/mtd/brcm,brcmnand.txt | 32
> > ++
> > 1 file changed, 32 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> > b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> > index 4ff7128..ebfa6fc 100644
> > --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> > @@ -45,6 +45,8 @@ Required properties:
> > - #size-cells : <0>
> >
> > Optional properties:
> > +- clock : reference to the clock for the NAND
> > controller
> > +- clock-names : "nand" (required for the above clock)
> > - brcm,nand-has-wp : Some versions of this IP include a
> > write-protect
> >(WP) control bit. It is always available on
> > >=
> >v7.0. Use this property to describe the rare
> > @@ -72,6 +74,12 @@ we define additional 'compatible' properties and
> > associated register resources w
> > and enable registers
> > - reg-names: (required) "nand-int-base"
> >
> > + * "brcm,nand-bcm6368"
> > + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm6368"
> > + - reg: (required) the 'NAND_INTR_BASE' register range, with combined
> > status
> > + and enable registers, and boot address registers
> > + - reg-names: (required) "nand-int-base"
> > +
> > * "brcm,nand-iproc"
> > - reg: (required) the "IDM" register range, for interrupt enable and
> > APB
> > bus access endianness configuration, and the "EXT" register range,
> > @@ -148,3 +156,27 @@ nand@f0442800 {
> > };
> > };
> > };
> > +
> > +nand@1200 {
> > + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
> > + "brcm,brcmnand-v4.0", "brcm,brcmnand";
> > + reg = <0x1200 0x180>,
> > + <0x1600 0x200>,
> > + <0x10b0 0x10>;
> > + reg-names = "nand", "nand-cache", "nand-intr-base";
s/intr/int/
> > + interrupt-parent = <&periph_intc>;
> > + interrupts = <50>;
> > + clocks = <&periph_clk 20>;
> > + clock-names = "nand";
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + nand0: nandcs@0 {
> > + compatible = "brcm,nandcs";
> > + reg = <0>;
> > + nand-on-flash-bbt;
> > + nand-ecc-strength = <1>;
> > + nand-ecc-step-size = <512>;
> > + };
> > +};
> >
>
>
> --
> Florian
--
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
Re: [PATCH v2 12/19] ARM: dts: Add bus nodes using VDD_INT for Exynos3250
On 2015년 12월 10일 11:09, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
>> Exynos3250 has following AXI buses to translate data between
>> DRAM and sub-blocks.
>>
>> Following list specifies the detailed relation between DRAM and sub-blocks:
>> - ACLK400 clock for MCUISP
>> - ACLK266 clock for ISP
>> - ACLK200 clock for FSYS
>> - ACLK160 clock for LCD0
>> - ACLK100 clock for PERIL
>> - GDL clock for LEFTBUS
>> - GDR clock for RIGHTBUS
>> - SCLK_MFC clock for MFC
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos3250.dtsi | 160
>> ++
>> 1 file changed, 160 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 7214c5e42150..46dee1951ec1 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -721,6 +721,166 @@
>> opp-microvolt = <875000>;
>> };
>> };
>> +
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_GDR>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_lcd0: bus_lcd0 {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_ACLK_160>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_fsys: bus_fsys {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_ACLK_200>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_mcuisp: bus_mcuisp {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_mcuisp_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_isp: bus_isp {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_ACLK_266>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_isp_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_peril: bus_peril {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_ACLK_100>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_peril_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_mfc: bus_mfc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_SCLK_MFC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_leftbus_opp_table: opp_table2 {
>> +compatible = "operating-points-v2";
>> +opp-shared;
>> +
>> +opp00 {
>> +opp-hz = /bits/ 64 <5000>;
>> +opp-microvolt = <90>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <8000>;
>> +opp-microvolt = <90>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <100>;
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <13400>;
>> +opp-microvolt = <100>;
>> +};
>> +opp04 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <100>;
>> +};
>> +};
>> +
>> +bus_mcuisp_opp_table: opp_table3 {
>> +compatible = "operating-points-v2";
>> +
Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
On 10.12.2015 11:17, Chanwoo Choi wrote:
> On 2015년 12월 10일 11:04, Krzysztof Kozlowski wrote:
>> On 10.12.2015 11:00, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
On 10.12.2015 10:09, Chanwoo Choi wrote:
> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>> This patch adds the DMC (Dynamic Memory Controller) bus node for
>>> Exynos3250 SoC.
>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC
>>> standard
>>> SDRAM devices. The bus includes the OPP tables and the source clock for
>>> DMC
>>> block.
>>>
>>> Following list specifies the detailed relation between the clock and
>>> DMC block:
>>> - The source clock of DMC block : div_dmc
>>>
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> arch/arm/boot/dts/exynos3250.dtsi | 34
>>> ++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 2f30d632f1cc..7214c5e42150 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -687,6 +687,40 @@
>>> clock-names = "ppmu";
>>> status = "disabled";
>>> };
>>> +
>>> + bus_dmc: bus_dmc {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = <&cmu_dmc CLK_DIV_DMC>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <&bus_dmc_opp_table>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + bus_dmc_opp_table: opp_table1 {
>>
>> This is the firsy opp_table, right? So:
>> s/opp_table1/opp_table0/
>
> Right. It is first opp_table in exynos3250.dtsi.
> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
> So, I have the plan that support the operation-points-v2 for Exynos3250
> CPU.
Ok
>
>>
>>> + 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 <13400>;
>>> + opp-microvolt = <80>;
>>
>> Why 134, not 133 MHz?
>
> When I used the 13300, the source clock is changed to 100Mhz instead
> of 133MHz.
> I add following test result on exynos3250-rinato board.
>
> Case1.
> When I use the 134 MHz, the source clock is changed to 133MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400)
> (real: 13334)
>
> Case2.
> When I use the 133 MHz, the source clock is changed to 100MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300)
> (real: 1)
Now I remember that issue. You could use here directly 13334 but
that also would look a little bit weird... so 134 is ok for me. Could
just add a comment that desired frequency is actually "133 MHz"?
>>>
>>> Do you prefer among following example?
>>>
>>> Example1.
>>> opp02 {
>>> /* The desired frequency is 133MHz because
>>> * clock change has the dependency on clock driver.
>>> * When set rate as 134MHz, the clock driver would
>>> * change the 133MHz actually instead of 134MHz.
>>> */
>>> opp-hz = /bits/ 64 <13400>;
>>> opp-microvolt = <80>;
>>> };
>>>
>>> Example2.
>>> opp02 {
>>> opp-hz = /bits/ 64 <13334>;
>>> opp-microvolt = <80>;
>>> };
>>
>> I would prefer the second one (13334) but I don't have strong
>> feelings about it.
>
> If you ok, I want to maintain the original approach as following:
>
> opp02 {
> opp-hz = /bits/ 64 <13400>;
> opp-microvolt = <80>;
> };
OK
Best regards,
Krzysztof
--
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
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
On 2015년 12월 10일 10:22, Krzysztof Kozlowski wrote: > On 10.12.2015 09:57, Krzysztof Kozlowski wrote: >> On 09.12.2015 13:07, Chanwoo Choi wrote: >> >> (...) >> >>> .../devicetree/bindings/devfreq/exynos-bus.txt | 383 +++ >> >> How about adding this file to the MAINTAINERS to devfreq exynos entry? OK. I'll add new entry for 'devfreq exynos' as following: +SAMSUNG BUS DEVICE FREQUENCY SUPPORT +M: Chanwoo Choi +L: linux...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git +S: Supported +F: drivers/devfreq/exynos/exynos-bus.c +F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> Unfortunately, in current linux-next, I can find the entry for devfreq > > D'oh! I meant:^ I cannot find the entry for... > > BR, > Krzysztof > >> exynos. However I saw patches adding such entries... aren't they merged >> to linux-next? Yes, it is not merged to linux-next because any git repository don't apply this patchset. To merge the devfreq patchset to linux-next, devfreq maintainer should send the request mail to Stephen Rothwell. [snip] Best Regards, Chanwoo Choi -- 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
Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
On 2015년 12월 10일 11:04, Krzysztof Kozlowski wrote:
> On 10.12.2015 11:00, Chanwoo Choi wrote:
>> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
>>> On 10.12.2015 10:09, Chanwoo Choi wrote:
On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
>> This patch adds the DMC (Dynamic Memory Controller) bus node for
>> Exynos3250 SoC.
>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC
>> standard
>> SDRAM devices. The bus includes the OPP tables and the source clock for
>> DMC
>> block.
>>
>> Following list specifies the detailed relation between the clock and DMC
>> block:
>> - The source clock of DMC block : div_dmc
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos3250.dtsi | 34
>> ++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 2f30d632f1cc..7214c5e42150 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -687,6 +687,40 @@
>> clock-names = "ppmu";
>> status = "disabled";
>> };
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu_dmc CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table1 {
>
> This is the firsy opp_table, right? So:
> s/opp_table1/opp_table0/
Right. It is first opp_table in exynos3250.dtsi.
But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
So, I have the plan that support the operation-points-v2 for Exynos3250
CPU.
>>>
>>> Ok
>>>
>
>> +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 <13400>;
>> +opp-microvolt = <80>;
>
> Why 134, not 133 MHz?
When I used the 13300, the source clock is changed to 100Mhz instead
of 133MHz.
I add following test result on exynos3250-rinato board.
Case1.
When I use the 134 MHz, the source clock is changed to 133MHz
: exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400)
(real: 13334)
Case2.
When I use the 133 MHz, the source clock is changed to 100MHz
: exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300)
(real: 1)
>>>
>>> Now I remember that issue. You could use here directly 13334 but
>>> that also would look a little bit weird... so 134 is ok for me. Could
>>> just add a comment that desired frequency is actually "133 MHz"?
>>
>> Do you prefer among following example?
>>
>> Example1.
>> opp02 {
>> /* The desired frequency is 133MHz because
>> * clock change has the dependency on clock driver.
>> * When set rate as 134MHz, the clock driver would
>> * change the 133MHz actually instead of 134MHz.
>> */
>> opp-hz = /bits/ 64 <13400>;
>> opp-microvolt = <80>;
>> };
>>
>> Example2.
>> opp02 {
>> opp-hz = /bits/ 64 <13334>;
>> opp-microvolt = <80>;
>> };
>
> I would prefer the second one (13334) but I don't have strong
> feelings about it.
If you ok, I want to maintain the original approach as following:
opp02 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
Best Regards,
Chanwoo Choi
--
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
Re: Generic DT binding for IPIs
On Wed, Dec 09, 2015 at 10:50:35AM -0600, Rob Herring wrote:
> On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote:
> > Hi,
> >
> > On 10/22/2015 12:55 PM, Jason Cooper wrote:
> >>
> >> On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote:
> >>>
> >>> Is there anything more I can do to get more attention about this? I
> >>> think Marc's suggestion is more generic and future proof, if I send
> >>> RFC patches for that would this be better?
> >>
> >> Please do.
> >
> >
> > Unfortunately I haven't had a chance to get around writing the patches yet.
> > I came up with a different description though that I thought maybe worth
> > sharing
> > to see if there's any opinion about it before the actual work being done.
>
> I've not given this too much thought, but here's my initial thoughts.
>
> >
> > To summarise, the problem I am trying to solve is that we have a type of
> > coprocessors which share the interrupt controller with Linux, hence the IPI
> > mechanism this controller uses. I've been working with Thomas on
> > implementing
> > a generic API to allocate IPIs for coprocesors and a way for drivers to send
> > these IPIs [1].
> >
> > To complement this new API, we need a mechanism to describe this in
> > device tree so a driver that wants to allocate an IPI can have this done
> > automatically for it like we handle interrupts.
> >
> > What I have in mind is:
> >
> > coproc {
> > ipi-parent = <&gic>;
> >
> > ipis = ;
> > ipi-names = "in";
> > };
> >
> > This will allocate an IPI to go to cpu @CPU_VALUE passing @IPI_SPEC as
> > parameters to the controller. Which means we need a new ipi-cells to
> > define how many cells are in ipis property. Note the new ipi-parent too.
>
> These are still interrupts, so I'd prefer to use or extend the
> interrupt binding if possible.
I agree. It should be possible to just describe these as interrupts,
with the interrupt-parent being a special interrupt controller node to
represent these IPIs.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
Re: [PATCH v6 00/10] cpufreq: Introduce ST's CPUFreq driver
On 09-12-15, 15:58, Lee Jones wrote: > This is a re-write of the original submission, hence why the > change-log is omitted. Basically almost everything has changed. > We are now using the new OPP framework and generic bindings > written by Viresh. > > There are 'ARM' patches in the set which are not necessarily > related to CPUFreq, but are required to get it to work. Anyone > who is not interested in general STi DT changes can safely > ignore these. Apart from minor comments in the 8th patch, everything else looks fine. Reviewed-by: Viresh Kumar -- viresh -- 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
Re: [PATCH v2 12/19] ARM: dts: Add bus nodes using VDD_INT for Exynos3250
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
> Exynos3250 has following AXI buses to translate data between
> DRAM and sub-blocks.
>
> Following list specifies the detailed relation between DRAM and sub-blocks:
> - ACLK400 clock for MCUISP
> - ACLK266 clock for ISP
> - ACLK200 clock for FSYS
> - ACLK160 clock for LCD0
> - ACLK100 clock for PERIL
> - GDL clock for LEFTBUS
> - GDR clock for RIGHTBUS
> - SCLK_MFC clock for MFC
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 160
> ++
> 1 file changed, 160 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 7214c5e42150..46dee1951ec1 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -721,6 +721,166 @@
> opp-microvolt = <875000>;
> };
> };
> +
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_lcd0: bus_lcd0 {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_ACLK_160>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_fsys: bus_fsys {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_ACLK_200>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mcuisp: bus_mcuisp {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_mcuisp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_isp: bus_isp {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_ACLK_266>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_isp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_peril: bus_peril {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_ACLK_100>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_peril_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_mfc: bus_mfc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_SCLK_MFC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_leftbus_opp_table: opp_table2 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <90>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <8000>;
> + opp-microvolt = <90>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <100>;
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <100>;
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <100>;
> + };
> + };
> +
> + bus_mcuisp_opp_table: opp_table3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
> +
Re: [PATCH v6 08/10] cpufreq: st: Provide runtime initialised driver for ST's platforms
On 09-12-15, 15:58, Lee Jones wrote:
> +/*
> + * Only match on "suitable for ALL versions" entries
> + *
> + * This will be used with the BIT() macro. It sets the
> + * top bit of a 32bit value and is equal to 0x8000.
> + */
> +#define DEFAULT_VERSION 31
Okay, I misread it in the earlier version. This looks fine.
> +static int sti_cpufreq_set_opp_info(void)
> +{
> + sprintf(name, "pcode%d", pcode);
I would use snprintf here, in case I haven't counted the string
properly. That should guarantee that we don't access the anything else
than the 'name' array.
> +
> + ret = dev_pm_opp_set_prop_name(dev, name);
> + if (ret) {
> + dev_err(dev, "Failed to set prop name\n");
> + return ret;
> + }
> +
> + version[0] = BIT(major);
> + version[1] = BIT(minor);
> + version[2] = BIT(substrate);
> +
> + ret = dev_pm_opp_set_supported_hw(dev, version, VERSION_ELEMENTS);
> + if (ret) {
> + dev_err(dev, "Failed to set supported hardware\n");
> + return ret;
> + }
> +
> + dev_err(dev, "pcode: %d major: %d minor: %d substrate: %d\n",
> + pcode, major, minor, substrate);
> + dev_err(dev, "version[0]: %x version[1]: %x version[2]: %x\n",
> + version[0], version[1], version[2]);
These aren't errors.. dev_info ?
> +
> + return 0;
> +}
> +
> +static int sti_cpufreq_init(void)
> +{
> + int ret;
> +
> + ddata.cpu = get_cpu_device(0);
> + if (!ddata.cpu) {
> + dev_err(ddata.cpu, "Failed to get device for CPU0\n");
> + goto skip_voltage_scaling;
> + }
> +
> + if (!of_get_property(ddata.cpu->of_node, "operating-points-v2", NULL)) {
> + dev_err(ddata.cpu, "OPP-v2 not supported\n");
Should be:
dev_dbg(ddata.cpu, "OPP-v2 not supported, skip voltage
scaling\n");
> + goto skip_voltage_scaling;
> + }
> +
> + ret = sti_cpufreq_fetch_syscon_regsiters();
> + if (ret)
> + goto skip_voltage_scaling;
> +
> + ret = sti_cpufreq_set_opp_info();
> + if (ret)
Shouldn't this be !ret ? You should have jumped on success here.
> + goto register_cpufreq_dt;
> +
> +skip_voltage_scaling:
> + dev_err(ddata.cpu, "Not doing voltage scaling\n");
This doesn't look nice as you are adding unnecessary jumps to just
save on a print message. And because of the earlier suggestion you can
do:
ret = sti_cpufreq_set_opp_info();
if (ret)
dev_err(ddata.cpu, "Skip voltage scaling\n");
> +
> +register_cpufreq_dt:
> + platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
> +
> + return 0;
> +}
> +module_init(sti_cpufreq_init);
> +
> +MODULE_DESCRIPTION("STMicroelectronics CPUFreq/OPP driver");
> +MODULE_AUTHOR("Ajitpal Singh ");
> +MODULE_AUTHOR("Lee Jones ");
> +MODULE_LICENSE("GPL v2");
> --
> 1.9.1
--
viresh
--
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
Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
On 10.12.2015 11:00, Chanwoo Choi wrote:
> On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
>> On 10.12.2015 10:09, Chanwoo Choi wrote:
>>> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus node for
> Exynos3250 SoC.
> The DMC is an AMBA AXI-compliant slave to interface external JEDEC
> standard
> SDRAM devices. The bus includes the OPP tables and the source clock for
> DMC
> block.
>
> Following list specifies the detailed relation between the clock and DMC
> block:
> - The source clock of DMC block : div_dmc
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 2f30d632f1cc..7214c5e42150 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -687,6 +687,40 @@
> clock-names = "ppmu";
> status = "disabled";
> };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
This is the firsy opp_table, right? So:
s/opp_table1/opp_table0/
>>>
>>> Right. It is first opp_table in exynos3250.dtsi.
>>> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
>>> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
>>
>> Ok
>>
>>>
> + 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 <13400>;
> + opp-microvolt = <80>;
Why 134, not 133 MHz?
>>>
>>> When I used the 13300, the source clock is changed to 100Mhz instead of
>>> 133MHz.
>>> I add following test result on exynos3250-rinato board.
>>>
>>> Case1.
>>> When I use the 134 MHz, the source clock is changed to 133MHz
>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400)
>>> (real: 13334)
>>>
>>> Case2.
>>> When I use the 133 MHz, the source clock is changed to 100MHz
>>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300)
>>> (real: 1)
>>
>> Now I remember that issue. You could use here directly 13334 but
>> that also would look a little bit weird... so 134 is ok for me. Could
>> just add a comment that desired frequency is actually "133 MHz"?
>
> Do you prefer among following example?
>
> Example1.
> opp02 {
> /* The desired frequency is 133MHz because
>* clock change has the dependency on clock driver.
>* When set rate as 134MHz, the clock driver would
>* change the 133MHz actually instead of 134MHz.
>*/
> opp-hz = /bits/ 64 <13400>;
> opp-microvolt = <80>;
> };
>
> Example2.
> opp02 {
> opp-hz = /bits/ 64 <13334>;
> opp-microvolt = <80>;
> };
I would prefer the second one (13334) but I don't have strong
feelings about it.
Best regards,
Krzysztof
--
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
Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
On 2015년 12월 10일 10:20, Krzysztof Kozlowski wrote:
> On 10.12.2015 10:09, Chanwoo Choi wrote:
>> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>>> On 09.12.2015 13:07, Chanwoo Choi wrote:
This patch adds the DMC (Dynamic Memory Controller) bus node for
Exynos3250 SoC.
The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
SDRAM devices. The bus includes the OPP tables and the source clock for DMC
block.
Following list specifies the detailed relation between the clock and DMC
block:
- The source clock of DMC block : div_dmc
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 2f30d632f1cc..7214c5e42150 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -687,6 +687,40 @@
clock-names = "ppmu";
status = "disabled";
};
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_dmc CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
>>>
>>> This is the firsy opp_table, right? So:
>>> s/opp_table1/opp_table0/
>>
>> Right. It is first opp_table in exynos3250.dtsi.
>> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
>> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
>
> Ok
>
>>
>>>
+ 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 <13400>;
+ opp-microvolt = <80>;
>>>
>>> Why 134, not 133 MHz?
>>
>> When I used the 13300, the source clock is changed to 100Mhz instead of
>> 133MHz.
>> I add following test result on exynos3250-rinato board.
>>
>> Case1.
>> When I use the 134 MHz, the source clock is changed to 133MHz
>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) (real:
>> 13334)
>>
>> Case2.
>> When I use the 133 MHz, the source clock is changed to 100MHz
>> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) (real:
>> 1)
>
> Now I remember that issue. You could use here directly 13334 but
> that also would look a little bit weird... so 134 is ok for me. Could
> just add a comment that desired frequency is actually "133 MHz"?
Do you prefer among following example?
Example1.
opp02 {
/* The desired frequency is 133MHz because
* clock change has the dependency on clock driver.
* When set rate as 134MHz, the clock driver would
* change the 133MHz actually instead of 134MHz.
*/
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
Example2.
opp02 {
opp-hz = /bits/ 64 <13334>;
opp-microvolt = <80>;
};
Best Regards,
Chanwoo Choi
--
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
Re: [PATCH v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On 2015년 12월 10일 10:31, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch updates the documentation for passive bus devices and adds the
>> detailed example of Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> .../devicetree/bindings/devfreq/exynos-bus.txt | 244
>> -
>> 1 file changed, 241 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> index 54a1f9c46c88..c4fdc70f8eac 100644
>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -13,18 +13,23 @@ 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:
>> +Required properties for all bus devices:
>> - 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.
>> +
>> +Required properties for only parent bus device:
>
> Maybe:
> "Required properties only for parent bus devices:"
OK. I'll modify it.
>
> In this binding documentation file the idea of "parent" is not
> explained. I now it is related to passive devfreq governor but looking
> at the binding itself it is a new idea, not covered here.
OK. I'll add the detailed description of 'parent' and
correlation between 'parent' and 'passive' device.
>
>> - 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:
>> +Required properties for only passive bus device:
>
> "Required properties only for passive bus devices:"
OK. I'll modify it.
>
>> +- devfreq: the parent bus device.
>> +
>> +Optional properties for only parent bus device:
>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>> the performance count againt total cycle count.
>>
>> @@ -33,7 +38,20 @@ Example1:
>> 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 (Dynamic Memory Controller) block
>> +- MIF (Memory Interface) block
>> +: VDD_MIF |--- DMC (Dynamic Memory Controller)
>> +
>> +- INT (Internal) block
>> +: VDD_INT |--- LEFTBUS (parent device)
>> + |--- PERIL
>> + |--- MFC
>> + |--- G3D
>> + |--- RIGHTBUS
>> + |--- FSYS
>> + |--- LCD0
>> + |--- PERIR
>> + |--- ISP
>> + |--- CAM
>>
>> - MIF bus's frequency/voltage table
>> ---
>> @@ -46,6 +64,24 @@ Example1:
>> |L5| 40 |875000 |
>> ---
>>
>> +- INT bus's frequency/voltage table
>> +--
>> +|Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL ||VDD_INT |
>> +| name| |LCD0| | | |||
>> +| | |FSYS| | | |||
>> +| | |MFC | | | |||
>> +--
>> +|Mode |*parent|passive |passive|passive|passive|||
>> +--
>> +|Lv |Frequency ||Voltage |
>> +--
>> +|L1 |5 |5 |5 |5 |5 ||90 |
>> +|L2 |8 |8 |8 |8 |8 ||90 |
>> +|L3 |10 |10 |10 |10 |10 ||100 |
>> +|L4 |134000 |134000 |20 |20 | ||100 |
>> +|L5 |20 |20 |40 |30 | ||100 |
>> +--
>> +
>> Example2 :
>> The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>> are listed below:
>> @@ -84,6 +120,167 @@ Example2 :
>> };
>> };
>>
>> +bus_leftbus: bus_leftbus {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu CLK_DIV_GDL>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_leftbus_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_rightbus: bus_rightbus {
>> +compatible = "samsun
[PATCH v5 4/4] stmmac: socfpga: Provide dt node to config ptp clk source.
Provides an options to use the ptp clock routed from the Altera FPGA
fabric. Instead of the defalt eosc1 clock connected to the ARM HPS core.
This setting affects all emacs in the core as the ptp clock is common.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 +
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 3a9d679..72d82d6 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -11,6 +11,8 @@ Required properties:
designware version numbers documented in stmmac.txt
- altr,sysmgr-syscon : Should be the phandle to the system manager node that
encompasses the glue register, the register offset, and the register shift.
+ - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock
+ for ptp ref clk. This affects all emacs as the clock is common.
Optional properties:
altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 401383b..f0d797a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -32,6 +32,7 @@
#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
#define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x0003
+#define SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK 0x0010
#define EMAC_SPLITTER_CTRL_REG 0x0
#define EMAC_SPLITTER_CTRL_SPEED_MASK 0x3
@@ -47,6 +48,7 @@ struct socfpga_dwmac {
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
void __iomem *splitter_base;
+ bool f2h_ptp_ref_clk;
};
static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
@@ -116,6 +118,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
+ dwmac->f2h_ptp_ref_clk = of_property_read_bool(np,
"altr,f2h_ptp_ref_clk");
+
np_splitter = of_parse_phandle(np, "altr,emac-splitter", 0);
if (np_splitter) {
if (of_address_to_resource(np_splitter, 0, &res_splitter)) {
@@ -171,6 +175,11 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
ctrl |= val << reg_shift;
+ if (dwmac->f2h_ptp_ref_clk)
+ ctrl |= SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift / 2);
+ else
+ ctrl &= ~(SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift /
2));
+
regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
return 0;
}
--
1.8.3.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
[PATCH v5 3/4] stmmac: Fix calculations for ptp counters when clock input = 50Mhz.
stmmac_config_sub_second_increment set the sub second increment to 20ns.
Driver is configured to use the fine adjustment method where the sub second
register is incremented when the acculumator incremented by the addend
register wraps overflows. This accumulator is update on every ptp clk
cycle. If a ptp clk with a period of greater than 20ns was used the
sub second register would not get updated correctly.
Instead set the sub sec increment to twice the period of the ptp clk.
This result in the addend register being set mid range and overflow
the accumlator every 2 clock cycles.
Signed-off-by: Phil Reid
---
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 9 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index f4518bc..1e19c8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -439,7 +439,7 @@ struct stmmac_ops {
/* PTP and HW Timer helpers */
struct stmmac_hwtimestamp {
void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
- void (*config_sub_second_increment) (void __iomem *ioaddr);
+ u32 (*config_sub_second_increment) (void __iomem *ioaddr, u32 clk_rate);
int (*init_systime) (void __iomem *ioaddr, u32 sec, u32 nsec);
int (*config_addend) (void __iomem *ioaddr, u32 addend);
int (*adjust_systime) (void __iomem *ioaddr, u32 sec, u32 nsec,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 76ad214..a77f689 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -33,22 +33,25 @@ static void stmmac_config_hw_tstamping(void __iomem
*ioaddr, u32 data)
writel(data, ioaddr + PTP_TCR);
}
-static void stmmac_config_sub_second_increment(void __iomem *ioaddr)
+static u32 stmmac_config_sub_second_increment(void __iomem *ioaddr,
+ u32 ptp_clock)
{
u32 value = readl(ioaddr + PTP_TCR);
unsigned long data;
/* Convert the ptp_clock to nano second
-* formula = (1/ptp_clock) * 10
+* formula = (2/ptp_clock) * 10
* where, ptp_clock = 50MHz.
*/
- data = (10ULL / 5000);
+ data = (20ULL / ptp_clock);
/* 0.465ns accuracy */
if (!(value & PTP_TCR_TSCTRLSSR))
data = (data * 1000) / 465;
writel(data, ioaddr + PTP_SSIR);
+
+ return data;
}
static int stmmac_init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3c6549a..2231a01 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -53,6 +53,7 @@
#include "stmmac.h"
#include
#include
+#include "dwmac1000.h"
#define STMMAC_ALIGN(x)L1_CACHE_ALIGN(x)
@@ -185,7 +186,7 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
priv->clk_csr = STMMAC_CSR_100_150M;
else if ((clk_rate >= CSR_F_150M) && (clk_rate < CSR_F_250M))
priv->clk_csr = STMMAC_CSR_150_250M;
- else if ((clk_rate >= CSR_F_250M) && (clk_rate <= CSR_F_300M))
+ else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
priv->clk_csr = STMMAC_CSR_250_300M;
}
}
@@ -435,6 +436,7 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
u32 ts_master_en = 0;
u32 ts_event_en = 0;
u32 value = 0;
+ u32 sec_inc;
if (!(priv->dma_cap.time_stamp || priv->adv_ts)) {
netdev_alert(priv->dev, "No support for HW time stamping\n");
@@ -598,24 +600,19 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
tstamp_all | ptp_v2 | ptp_over_ethernet |
ptp_over_ipv6_udp | ptp_over_ipv4_udp | ts_event_en |
ts_master_en | snap_type_sel);
-
priv->hw->ptp->config_hw_tstamping(priv->ioaddr, value);
/* program Sub Second Increment reg */
- priv->hw->ptp->config_sub_second_increment(priv->ioaddr);
+ sec_inc = priv->hw->ptp->config_sub_second_increment(
+ priv->ioaddr, priv->clk_ptp_rate);
+ temp = div_u64(10ULL, sec_inc);
/* calculate default added value:
* formula is :
* addend = (2^32)/freq_div_ratio;
-* where, freq_div_ratio = clk
[PATCH v5 2/4] stmmac: Correct documentation on stmmac clocks.
devm_get_clk looks in clock-name property for matching clock. the ptp_ref_clk property is ignored. Acked-by: Rob Herring Signed-off-by: Phil Reid --- Documentation/devicetree/bindings/net/stmmac.txt | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index fd5ddf8..e862a92 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -35,15 +35,14 @@ Optional properties: - reset-names: Should contain the reset signal name "stmmaceth", if a reset phandle is given - max-frame-size: See ethernet.txt file in the same directory -- clocks: If present, the first clock should be the GMAC main clock and - the second clock should be peripheral's register interface clock. Further - clocks may be specified in derived bindings. -- clock-names: One name for each entry in the clocks property, the - first one should be "stmmaceth" and the second one should be "pclk". -- clk_ptp_ref: this is the PTP reference clock; in case of the PTP is - available this clock is used for programming the Timestamp Addend Register. - If not passed then the system clock will be used and this is fine on some - platforms. +- clocks: If present, the first clock should be the GMAC main clock + The optional second clock should be peripheral's register interface clock. + The third optional clock should be the ptp reference clock. + Further clocks may be specified in derived bindings. +- clock-names: One name for each entry in the clocks property. + The first one should be "stmmaceth". + The optional second one should be "pclk". + The optional third one should be "clk_ptp_ref". - snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register. - tx-fifo-depth: See ethernet.txt file in the same directory - rx-fifo-depth: See ethernet.txt file in the same directory -- 1.8.3.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
[PATCH v5 1/4] stmmac: create of compatible mdio bus for stmacc driver
The DSA driver needs to be passed a reference to an mdio bus. Typically
the mac is configured to use a fixed link but the mdio bus still needs
to be registered so that it con configure the switch.
This patch follows the same process as the altera tse ethernet driver for
creation of the mdio bus.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 31 +++---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index f34fc3c..fd5ddf8 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -47,6 +47,7 @@ Optional properties:
- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
- tx-fifo-depth: See ethernet.txt file in the same directory
- rx-fifo-depth: See ethernet.txt file in the same directory
+- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
@@ -65,4 +66,11 @@ Examples:
tx-fifo-depth = <16384>;
clocks = <&clock>;
clock-names = "stmmaceth";
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy1: ethernet-phy@0 {
+ };
+ };
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index bba670c..bb6f75c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
#include
#include "stmmac.h"
@@ -200,10 +200,29 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
+ struct device_node *mdio_node = NULL;
+ struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
+ if (IS_ENABLED(CONFIG_OF)) {
+ for_each_child_of_node(priv->device->of_node, child_node) {
+ if (of_device_is_compatible(child_node,
+ "snps,dwmac-mdio")) {
+ mdio_node = child_node;
+ break;
+ }
+ }
+
+ if (mdio_node) {
+ netdev_dbg(ndev, "FOUND MDIO subnode\n");
+ } else {
+ netdev_err(ndev, "NO MDIO subnode\n");
+ return 0;
+ }
+ }
+
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
@@ -231,7 +250,8 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->irq = irqlist;
new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
- err = mdiobus_register(new_bus);
+
+ err = of_mdiobus_register(new_bus, mdio_node);
if (err != 0) {
pr_err("%s: Cannot register as MDIO bus\n", new_bus->name);
goto bus_register_fail;
@@ -284,13 +304,6 @@ int stmmac_mdio_register(struct net_device *ndev)
}
}
- if (!found) {
- pr_warn("%s: No PHY found\n", ndev->name);
- mdiobus_unregister(new_bus);
- mdiobus_free(new_bus);
- return -ENODEV;
- }
-
priv->mii = new_bus;
return 0;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index d02691b..6863420 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -146,7 +146,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
- if (plat->phy_node || plat->phy_bus_name)
+ if (plat->phy_bus_name)
plat->mdio_bus_data = NULL;
else
plat->mdio_bus_data =
--
1.8.3.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
[PATCH v5 0/4] stmmac: Fixed Phy & PTP fixes
Provide ability to specify a fixed phy in the device tree and retain the mdio bus if no phy is found. This is needed where a dsa is connected via a fixed phy and uses the mdio bus for config. Fixed ptp ref clock calculatins for the stmmac when ptp ref clock is running at <= 50Mhz. Also add device tree setting to config ptp clk source on socfpga platforms. Change from V4: - Restore #ifdef CONFIG_OF around setting of reset_gpio. Member doesn't exist when this isn't defined. Changes from V3: - Use if (IS_ENABLED(CONFIG_OF)) instead of #if. Reorder some code to reduce if statements. - of_mdiobus_register already falls back to mdiobus_register - Tested on system with CONFIG_OF Changes from V2: - Formatting, spaces & lines > 80 chars. Using checkpatch - Drop PTP register debugfs patch. Changes from V1: - Fixed mismatch doc / code for ptp_ref_clk dt node. - Remove unit address from doc example. Phil Reid (5): stmmac: create of compatible mdio bus for stmacc driver stmmac: Correct documentation on stmmac clocks. stmmac: Fix calculations for ptp counters when clock input = 50Mhz. stmmac: socfpga: Provide dt node to config ptp clk source. .../devicetree/bindings/net/socfpga-dwmac.txt | 2 ++ Documentation/devicetree/bindings/net/stmmac.txt | 25 ++--- drivers/net/ethernet/stmicro/stmmac/common.h | 2 +- .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 9 +++ .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 9 --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++--- drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 31 +++--- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +- 8 files changed, 65 insertions(+), 34 deletions(-) -- 1.8.3.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
Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
On 2015년 12월 10일 10:25, Krzysztof Kozlowski wrote:
> On 10.12.2015 09:49, Chanwoo Choi wrote:
>> Hi,
>>
> (...)
>
>>>
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ 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 {
>>>
>>> Maybe use convention with frequency, like:
>>> opp@5000
>>> This also used in opp.txt examples.
>>
>> In the Documentations/devicetree/bindings/opp/opp.txt,
>> the example uses the 'opp@0x'. I check the opp.txt of Linux 4.4-rc4.
>
> Yes, it was changed by Viresh in "PM / OPP: Rename OPP nodes as
> opp@". You can find the most actual bindings in linux-next.
OK. I'll.
Best Regards,
Chanwoo Choi
--
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
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Tue, Dec 8, 2015 at 2:07 PM, Bjorn Andersson
wrote:
> On Tue 08 Dec 13:29 PST 2015, John Stultz wrote:
>> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> index 5183d18..ee5dcb7 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> @@ -282,6 +282,15 @@
>> };
>> };
>>
>> + reboot_reason: reboot_reason@2a03f65c {
>> + compatible = "reboot_reason";
>> + reg = <0x2A03F65C 0x4>;
>> + reason,none = <0x77665501>;
>> + reason,bootloader = <0x77665500>;
>> + reason,recovery = <0x77665502>;
>> + reason,oem = <0x6f656d00>;
>> + };
>> +
>
> This address refers to IMEM, which is shared with a number of other
> uses. So I think we should have a simple-mfd (and syscon) with this
> within.
So talking with Arnd some more it looked like IMEM was really just
SRAM. Is that not the case, or is there something else special about
it? Does it really need simple-mfd and syscon? I'm still fuzzy on how
to use those for this.
>> + /* initialize specified reasons from DT */
>> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", &val))
>> + reasons[NONE] = val;
>> + if (!of_property_read_u32(pdev->dev.of_node, "reason,bootloader",
>> &val))
>> + reasons[BOOTLOADER] = val;
>> + if (!of_property_read_u32(pdev->dev.of_node, "reason,recovery", &val))
>> + reasons[RECOVERY] = val;
>> + if (!of_property_read_u32(pdev->dev.of_node, "reason,oem", &val))
>> + reasons[OEM] = val;
>
> I would like for this to be less hard coded.
So thinking of this more. Is having something like:
cmds = "default", "bootloader", "recovery";
vals = <0xmagic1>, <0xmagic2>, <0xmagic3>;
what you're thinking about?
This wouldn't quite handle the "oem-N" options as simply, but they
could define each oem- case explicitly in the DT to support it.
thanks
-john
--
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
Re: [PATCH v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On 09.12.2015 13:08, Chanwoo Choi wrote:
> This patch updates the documentation for passive bus devices and adds the
> detailed example of Exynos3250.
>
> Signed-off-by: Chanwoo Choi
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 244
> -
> 1 file changed, 241 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index 54a1f9c46c88..c4fdc70f8eac 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -13,18 +13,23 @@ 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:
> +Required properties for all bus devices:
> - 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.
> +
> +Required properties for only parent bus device:
Maybe:
"Required properties only for parent bus devices:"
In this binding documentation file the idea of "parent" is not
explained. I now it is related to passive devfreq governor but looking
at the binding itself it is a new idea, not covered here.
> - 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:
> +Required properties for only passive bus device:
"Required properties only for passive bus devices:"
> +- devfreq: the parent bus device.
> +
> +Optional properties for only parent bus device:
> - exynos,saturation-ratio: the percentage value which is used to calibrate
> the performance count againt total cycle count.
>
> @@ -33,7 +38,20 @@ Example1:
> 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 (Dynamic Memory Controller) block
> + - MIF (Memory Interface) block
> + : VDD_MIF |--- DMC (Dynamic Memory Controller)
> +
> + - INT (Internal) block
> + : VDD_INT |--- LEFTBUS (parent device)
> + |--- PERIL
> + |--- MFC
> + |--- G3D
> + |--- RIGHTBUS
> + |--- FSYS
> + |--- LCD0
> + |--- PERIR
> + |--- ISP
> + |--- CAM
>
> - MIF bus's frequency/voltage table
> ---
> @@ -46,6 +64,24 @@ Example1:
> |L5| 40 |875000 |
> ---
>
> + - INT bus's frequency/voltage table
> + --
> + |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL ||VDD_INT |
> + | name| |LCD0| | | |||
> + | | |FSYS| | | |||
> + | | |MFC | | | |||
> + --
> + |Mode |*parent|passive |passive|passive|passive|||
> + --
> + |Lv |Frequency ||Voltage |
> + --
> + |L1 |5 |5 |5 |5 |5 ||90 |
> + |L2 |8 |8 |8 |8 |8 ||90 |
> + |L3 |10 |10 |10 |10 |10 ||100 |
> + |L4 |134000 |134000 |20 |20 | ||100 |
> + |L5 |20 |20 |40 |30 | ||100 |
> + --
> +
> Example2 :
> The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> are listed below:
> @@ -84,6 +120,167 @@ Example2 :
> };
> };
>
> + bus_leftbus: bus_leftbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_GDL>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_rightbus: bus_rightbus {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu CLK_DIV_GDR>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_leftbus_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_lcd0: bus_lcd0 {
> + compatible = "sams
Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
On 10.12.2015 09:49, Chanwoo Choi wrote:
> Hi,
>
(...)
>>
>>> +
>>> + bus_dmc: bus_dmc {
>>> + compatible = "samsung,exynos-bus";
>>> + 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 {
>>
>> Maybe use convention with frequency, like:
>> opp@5000
>> This also used in opp.txt examples.
>
> In the Documentations/devicetree/bindings/opp/opp.txt,
> the example uses the 'opp@0x'. I check the opp.txt of Linux 4.4-rc4.
Yes, it was changed by Viresh in "PM / OPP: Rename OPP nodes as
opp@". You can find the most actual bindings in linux-next.
Best regards,
Krzysztof
--
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
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
On 10.12.2015 09:57, Krzysztof Kozlowski wrote: > On 09.12.2015 13:07, Chanwoo Choi wrote: > > (...) > >> .../devicetree/bindings/devfreq/exynos-bus.txt | 383 +++ > > How about adding this file to the MAINTAINERS to devfreq exynos entry? > Unfortunately, in current linux-next, I can find the entry for devfreq D'oh! I meant:^ I cannot find the entry for... BR, Krzysztof > exynos. However I saw patches adding such entries... aren't they merged > to linux-next? > > Best regards, > Krzysztof > >> arch/arm/boot/dts/exynos3250-monk.dts |6 + >> arch/arm/boot/dts/exynos3250-rinato.dts| 47 + >> arch/arm/boot/dts/exynos3250.dtsi | 194 >> arch/arm/boot/dts/exynos4210.dtsi | 172 >> arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 93 +- >> arch/arm/boot/dts/exynos4412-trats2.dts| 47 + >> arch/arm/boot/dts/exynos4x12.dtsi | 184 >> drivers/devfreq/Kconfig| 37 +- >> drivers/devfreq/Makefile |2 + >> drivers/devfreq/devfreq.c | 120 ++- >> drivers/devfreq/exynos/Makefile|3 +- >> drivers/devfreq/exynos/exynos-bus.c| 549 ++ >> drivers/devfreq/exynos/exynos4_bus.c | 1055 >> >> drivers/devfreq/exynos/exynos4_bus.h | 110 -- >> drivers/devfreq/exynos/exynos5_bus.c | 431 >> drivers/devfreq/exynos/exynos_ppmu.c | 119 --- >> drivers/devfreq/exynos/exynos_ppmu.h | 86 -- >> drivers/devfreq/governor.h |7 + >> drivers/devfreq/governor_passive.c | 109 ++ >> drivers/devfreq/governor_performance.c |1 + >> drivers/devfreq/governor_powersave.c |1 + >> drivers/devfreq/governor_simpleondemand.c |1 + >> drivers/devfreq/governor_userspace.c |1 + >> include/linux/devfreq.h| 28 + >> 25 files changed, 1958 insertions(+), 1828 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt >> create mode 100644 drivers/devfreq/exynos/exynos-bus.c >> delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c >> delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h >> delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c >> delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c >> delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h >> create mode 100644 drivers/devfreq/governor_passive.c >> > > -- 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
Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
On 10.12.2015 10:09, Chanwoo Choi wrote:
> On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
>> On 09.12.2015 13:07, Chanwoo Choi wrote:
>>> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250
>>> SoC.
>>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
>>> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
>>> block.
>>>
>>> Following list specifies the detailed relation between the clock and DMC
>>> block:
>>> - The source clock of DMC block : div_dmc
>>>
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>>> b/arch/arm/boot/dts/exynos3250.dtsi
>>> index 2f30d632f1cc..7214c5e42150 100644
>>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>>> @@ -687,6 +687,40 @@
>>> clock-names = "ppmu";
>>> status = "disabled";
>>> };
>>> +
>>> + bus_dmc: bus_dmc {
>>> + compatible = "samsung,exynos-bus";
>>> + clocks = <&cmu_dmc CLK_DIV_DMC>;
>>> + clock-names = "bus";
>>> + operating-points-v2 = <&bus_dmc_opp_table>;
>>> + status = "disabled";
>>> + };
>>> +
>>> + bus_dmc_opp_table: opp_table1 {
>>
>> This is the firsy opp_table, right? So:
>> s/opp_table1/opp_table0/
>
> Right. It is first opp_table in exynos3250.dtsi.
> But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
> So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
Ok
>
>>
>>> + 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 <13400>;
>>> + opp-microvolt = <80>;
>>
>> Why 134, not 133 MHz?
>
> When I used the 13300, the source clock is changed to 100Mhz instead of
> 133MHz.
> I add following test result on exynos3250-rinato board.
>
> Case1.
> When I use the 134 MHz, the source clock is changed to 133MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) (real:
> 13334)
>
> Case2.
> When I use the 133 MHz, the source clock is changed to 100MHz
> : exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) (real:
> 1)
Now I remember that issue. You could use here directly 13334 but
that also would look a little bit weird... so 134 is ok for me. Could
just add a comment that desired frequency is actually "133 MHz"?
Best regards,
Krzysztof
--
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
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Wed, Dec 9, 2015 at 2:07 AM, Arnd Bergmann wrote:
> On Tuesday 08 December 2015 16:22:40 John Stultz wrote:
>> >> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> >> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> >> index 5183d18..ee5dcb7 100644
>> >> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> >> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
>> >> @@ -282,6 +282,15 @@
>> >> };
>> >> };
>> >>
>> >> + reboot_reason: reboot_reason@2a03f65c {
>> >> + compatible = "reboot_reason";
>> >> + reg = <0x2A03F65C 0x4>;
>> >> + reason,none = <0x77665501>;
>> >> + reason,bootloader = <0x77665500>;
>> >> + reason,recovery = <0x77665502>;
>> >> + reason,oem = <0x6f656d00>;
>> >> + };
>> >> +
>> >
>> > This address refers to IMEM, which is shared with a number of other
>> > uses. So I think we should have a simple-mfd (and syscon) with this
>> > within.
>>
>> Errr.. I'm going to have to read up there. I'm not super familiar with
>> any of those drivers, so I'll try to see how exactly they would map in
>> here.
>
> Is this an SRAM? We already have a generic SRAM binding, and I think this
> would fit in there.
>
>> > I like the fact that you don't hard code the magics in the
>> > implementation, as I've seen additions from multiple places - so perhaps
>> > it should be made even more flexible.
>> >
>> > OMAP seems to use strings here instead of magics, but the delivery
>> > mechanism looks to be the same. But I think of this as Qualcomm
>> > specific.
>>
>> Yea. This is good feedback. EFI bootloaders have their own
>> implementations as well. I suspect we'll need a few different driver
>> "types" to handle these differences, ie: value vs string.
>>
>> I'll maybe extend the compatible string to make it clear that this is
>> a "value" style, and we can extend it with a string type later if
>> folks care?
>
> If the two known implementations are already fundamentally different,
> there is a good chance that other vendors have found some more ways
> to do the same thing, so we might need to do this as a framework,
> or merge it into an existing framework.
>
> Maybe it can be done in the same driver that also handles rebooting
> the machine? Those are typically in drivers/power/reset or
> in drivers/watchdog/ for machines that use the watchdog as the only
> way to reboot the machine. We can have additional device specific
> properties along with the reboot method (e.g. a reference to the
> SRAM or some syscon node) and add common code in another file if
> we need it.
Heh. So my original patch to support this was actually tied into the
ps_hold reboot logic in the pinctrl-msm code:
https://git.linaro.org/people/john.stultz/flo.git/commitdiff/55f28281306af2cc6c61aa001030cb90da096ffa?hp=ad39413ecde7acd39c1f017249b1443ce4ef6812
But realizing I'd like to support this same feature on other hardware,
and we'd be duplicating the logic over and over for each device/reboot
method, it seemed having a fairly generic driver would be better.
Looking at a few other devices, I saw one example that wanted both a
string and a value at the same time, so I probably could extend the
driver to have both reason strings and values, and would set which
ever (or both) were specified. That would cover all the cases I've
seen except the UEFI methods.
(Though I suspect I still have to wrap my head more around the DT
bindings side of things)
>> >> + /* initialize specified reasons from DT */
>> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", &val))
>> >> + reasons[NONE] = val;
>> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,bootloader",
>> >> &val))
>> >> + reasons[BOOTLOADER] = val;
>> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,recovery",
>> >> &val))
>> >> + reasons[RECOVERY] = val;
>> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,oem", &val))
>> >> + reasons[OEM] = val;
>> >
>> > I would like for this to be less hard coded.
>>
>> Any tips here on how to do so?
>
> If we move this logic into the qcom reset driver in
> drivers/power/reset/msm-poweroff.c, we should be good.
If the concern is that since DT is basically ABI, one might not want
to have such a wide interface that specifies all the different
reasons, I can understand that. Though I'm really not sure how else we
would be able to specify the device supported the reboot reason logic
w/o having something in the DT (since some device may use the same soc
w/ the same reboot logic may use a different bootloader which doesn't
support the reason methods). At that point if we don't describe the
method clearly, it ends up being something closer to just a quirks
list which we'd have to map i
Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
On 2015년 12월 10일 09:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
>> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250
>> SoC.
>> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
>> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
>> block.
>>
>> Following list specifies the detailed relation between the clock and DMC
>> block:
>> - The source clock of DMC block : div_dmc
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos3250.dtsi | 34 ++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
>> b/arch/arm/boot/dts/exynos3250.dtsi
>> index 2f30d632f1cc..7214c5e42150 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -687,6 +687,40 @@
>> clock-names = "ppmu";
>> status = "disabled";
>> };
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +clocks = <&cmu_dmc CLK_DIV_DMC>;
>> +clock-names = "bus";
>> +operating-points-v2 = <&bus_dmc_opp_table>;
>> +status = "disabled";
>> +};
>> +
>> +bus_dmc_opp_table: opp_table1 {
>
> This is the firsy opp_table, right? So:
> s/opp_table1/opp_table0/
Right. It is first opp_table in exynos3250.dtsi.
But, I'm considering the OPP table of CPU freqeuncy as opp_table0.
So, I have the plan that support the operation-points-v2 for Exynos3250 CPU.
>
>> +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 <13400>;
>> +opp-microvolt = <80>;
>
> Why 134, not 133 MHz?
When I used the 13300, the source clock is changed to 100Mhz instead of
133MHz.
I add following test result on exynos3250-rinato board.
Case1.
When I use the 134 MHz, the source clock is changed to 133MHz
: exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13400) (real:
13334)
Case2.
When I use the 133 MHz, the source clock is changed to 100MHz
: exynos-bus soc:bus_dmc: old_freq(2) -> new_freq (13300) (real:
1)
>
>> +};
>> +opp03 {
>> +opp-hz = /bits/ 64 <2>;
>> +opp-microvolt = <80>;
>
> Shouldn't this be 825 mV, not 800? I think we used previously that value
> for our devices.
OK. I'll modify it.
Regards,
Chanwoo Choi
--
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
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
On 09.12.2015 13:07, Chanwoo Choi wrote: (...) > .../devicetree/bindings/devfreq/exynos-bus.txt | 383 +++ How about adding this file to the MAINTAINERS to devfreq exynos entry? Unfortunately, in current linux-next, I can find the entry for devfreq exynos. However I saw patches adding such entries... aren't they merged to linux-next? Best regards, Krzysztof > arch/arm/boot/dts/exynos3250-monk.dts |6 + > arch/arm/boot/dts/exynos3250-rinato.dts| 47 + > arch/arm/boot/dts/exynos3250.dtsi | 194 > arch/arm/boot/dts/exynos4210.dtsi | 172 > arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 93 +- > arch/arm/boot/dts/exynos4412-trats2.dts| 47 + > arch/arm/boot/dts/exynos4x12.dtsi | 184 > drivers/devfreq/Kconfig| 37 +- > drivers/devfreq/Makefile |2 + > drivers/devfreq/devfreq.c | 120 ++- > drivers/devfreq/exynos/Makefile|3 +- > drivers/devfreq/exynos/exynos-bus.c| 549 ++ > drivers/devfreq/exynos/exynos4_bus.c | 1055 > > drivers/devfreq/exynos/exynos4_bus.h | 110 -- > drivers/devfreq/exynos/exynos5_bus.c | 431 > drivers/devfreq/exynos/exynos_ppmu.c | 119 --- > drivers/devfreq/exynos/exynos_ppmu.h | 86 -- > drivers/devfreq/governor.h |7 + > drivers/devfreq/governor_passive.c | 109 ++ > drivers/devfreq/governor_performance.c |1 + > drivers/devfreq/governor_powersave.c |1 + > drivers/devfreq/governor_simpleondemand.c |1 + > drivers/devfreq/governor_userspace.c |1 + > include/linux/devfreq.h| 28 + > 25 files changed, 1958 insertions(+), 1828 deletions(-) > create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt > create mode 100644 drivers/devfreq/exynos/exynos-bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h > delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c > delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h > create mode 100644 drivers/devfreq/governor_passive.c > -- 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
Re: [PATCH v2 04/19] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk
On 2015년 12월 10일 09:53, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, Chanwoo Choi wrote:
>> This patch adds the DMC (Dynamic Memory Controller) bus frequency node
>> which includes the devfreq-events and regulator properties. The bus
>> frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
>> with ondemand governor.
>>
>> The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
>> on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
>> the DMC block.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos3250-monk.dts | 6 ++
>> arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
>> 2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
>> b/arch/arm/boot/dts/exynos3250-monk.dts
>> index 443a35085846..d982586a6533 100644
>> --- a/arch/arm/boot/dts/exynos3250-monk.dts
>> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
>> @@ -498,6 +498,12 @@
>> };
>> };
>>
>> +&bus_dmc {
>> +devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
>> +vdd-supply = <&buck1_reg>;
>> +status = "okay";
>> +};
>> +
>> &xusbxti {
>> clock-frequency = <2400>;
>> };
>> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
>> b/arch/arm/boot/dts/exynos3250-rinato.dts
>> index 3e64d5dcdd60..61477943015b 100644
>> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
>> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
>> @@ -675,6 +675,12 @@
>> };
>> };
>>
>> +&bus_dmc {
>> +devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
>> +vdd-supply = <&buck1_reg>;
>> +status = "okay";
>> +};
>
> I would prefer to put this in alphabetical order... which could be
> tricky because the nodes are not entirely sorted. Maybe after the "&adc"
> node?
OK. I'll move it.
>
> Anyway the change looks good:
>
> Reviewed-by: Krzysztof Kozlowski
Thanks for your review.
Regards,
Chanwoo Choi
--
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
Re: [PATCH v2 04/19] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk
On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus frequency node
> which includes the devfreq-events and regulator properties. The bus
> frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
> with ondemand governor.
>
> The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
> on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
> the DMC block.
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos3250-monk.dts | 6 ++
> arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
> 2 files changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
> b/arch/arm/boot/dts/exynos3250-monk.dts
> index 443a35085846..d982586a6533 100644
> --- a/arch/arm/boot/dts/exynos3250-monk.dts
> +++ b/arch/arm/boot/dts/exynos3250-monk.dts
> @@ -498,6 +498,12 @@
> };
> };
>
> +&bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>;
> + status = "okay";
> +};
> +
> &xusbxti {
> clock-frequency = <2400>;
> };
> diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
> b/arch/arm/boot/dts/exynos3250-rinato.dts
> index 3e64d5dcdd60..61477943015b 100644
> --- a/arch/arm/boot/dts/exynos3250-rinato.dts
> +++ b/arch/arm/boot/dts/exynos3250-rinato.dts
> @@ -675,6 +675,12 @@
> };
> };
>
> +&bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>;
> + status = "okay";
> +};
I would prefer to put this in alphabetical order... which could be
tricky because the nodes are not entirely sorted. Maybe after the "&adc"
node?
Anyway the change looks good:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
--
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
Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
Hi,
On 2015년 12월 10일 09:39, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:07, 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 | 94
>> ++
>> 1 file changed, 94 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 ..54a1f9c46c88
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -0,0 +1,94 @@
>> +* 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 PPMU (Platform Performance Monitoring Unit) which
>
> s/thie/the/
OK.
>
>> +is able to measure the current load of sub-blocks.
>> +
>> +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.
>
> This is a clock consumer, right? So the clock-cells is not valid here.
You're right. I'll remove '#clock-cells'.
>
>> +- 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
>
> s/curret/current/
>
>> + 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.
>
> s/againt/against/
OK.
>
>> +
>> +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 (Dynamic Memory Controller) block
>> +
>> +- MIF bus's frequency/voltage table
>> +---
>> +|Lv| Freq | Voltage |
>> +---
>> +|L1| 5 |80 |
>> +|L2| 10 |80 |
>> +|L3| 134000 |80 |
>> +|L4| 20 |80 |
>> +|L5| 40 |875000 |
>> +---
>> +
>> +Example2 :
>> +The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>> +are listed below:
>
> s/are/is/ (one bus is listed)
OK.
>
>> +
>> +bus_dmc: bus_dmc {
>> +compatible = "samsung,exynos-bus";
>> +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 {
>
> Maybe use convention with frequency, like:
> opp@5000
> This also used in opp.txt examples.
In the Documentations/devicetree/bindings/opp/opp.txt,
the example uses the 'opp@0x'. I check the opp.txt of Linux 4.4-rc4.
>
>
>> +opp-hz = /bits/ 64 <5000>;
>> +opp-microvolt = <80>;
>> +};
>> +opp01 {
>> +opp-hz = /bits/ 64 <1>;
>> +opp-microvolt = <80>;
>> +};
>> +opp02 {
>> +opp-hz = /bits/ 64 <13400>;
>> +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:
>
> s/are/is/
OK.
>
>> +
>> +&bus_dmc {
>> +
Re: [4.4-rc][PATCH v2] ARM: dts: am4372: fix clock source for arm twd and global timers
* Felipe Balbi [151208 10:05]:
>
> Hi,
>
> Grygorii Strashko writes:
> > ARM TWD and Global timer are clocked by PERIPHCLK which is MPU_CLK/2.
> > But now they are clocked by dpll_mpu_m2_ck == MPU_CLK and, as result.
> > Timekeeping core misbehaves. For example, execution of command
> > "sleep 5" will take 10 sec instead of 5.
> >
> > Hence, fix it by adding mpu_periphclk ("fixed-factor-clock") and use
> > it for clocking ARM TWD and Global timer (same way as on OMAP4).
> >
> > Cc: Tony Lindgren
> > Cc: Felipe Balbi
> > Cc: Tero Kristo
> > Fixes:commit 8cbd4c2f6a99 ("arm: boot: dts: am4372: add ARM timers and SCU
> > nodes")
> > Signed-off-by: Grygorii Strashko
>
> this seems to be the best fix for this problem, yeah.
>
> Reviewed-by: Felipe Balbi
OK applying into omap-for-v4.4/fixes thanks.
Tony
--
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
Re: [PATCH v2 03/19] ARM: dts: Add DMC bus node for Exynos3250
On 09.12.2015 13:07, Chanwoo Choi wrote:
> This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250
> SoC.
> The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
> SDRAM devices. The bus includes the OPP tables and the source clock for DMC
> block.
>
> Following list specifies the detailed relation between the clock and DMC
> block:
> - The source clock of DMC block : div_dmc
>
> Signed-off-by: Chanwoo Choi
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 2f30d632f1cc..7214c5e42150 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -687,6 +687,40 @@
> clock-names = "ppmu";
> status = "disabled";
> };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&cmu_dmc CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
This is the firsy opp_table, right? So:
s/opp_table1/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 <13400>;
> + opp-microvolt = <80>;
Why 134, not 133 MHz?
> + };
> + opp03 {
> + opp-hz = /bits/ 64 <2>;
> + opp-microvolt = <80>;
Shouldn't this be 825 mV, not 800? I think we used previously that value
for our devices.
Best regards,
Krzysztof
> + };
> + opp04 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <875000>;
> + };
> + };
> };
> };
>
>
--
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
Re: [PATCH v2 02/19] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
On 09.12.2015 13:07, 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 | 94
> ++
> 1 file changed, 94 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 ..54a1f9c46c88
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -0,0 +1,94 @@
> +* 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 PPMU (Platform Performance Monitoring Unit) which
s/thie/the/
> +is able to measure the current load of sub-blocks.
> +
> +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.
This is a clock consumer, right? So the clock-cells is not valid here.
> +- 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
s/curret/current/
> + 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.
s/againt/against/
> +
> +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 (Dynamic Memory Controller) block
> +
> + - MIF bus's frequency/voltage table
> + ---
> + |Lv| Freq | Voltage |
> + ---
> + |L1| 5 |80 |
> + |L2| 10 |80 |
> + |L3| 134000 |80 |
> + |L4| 20 |80 |
> + |L5| 40 |875000 |
> + ---
> +
> +Example2 :
> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> + are listed below:
s/are/is/ (one bus is listed)
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + 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 {
Maybe use convention with frequency, like:
opp@5000
This also used in opp.txt examples.
> + opp-hz = /bits/ 64 <5000>;
> + opp-microvolt = <80>;
> + };
> + opp01 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <80>;
> + };
> + opp02 {
> + opp-hz = /bits/ 64 <13400>;
> + 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:
s/are/is/
> +
> + &bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>; /* VDD_MIF */
> + status = "okay";
> + };
>
--
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-in
Re: [PATCH v1 7/8] ARM: dts: rockchip: add core rk3228 dtsi
Hi Jeffy,
Am Mittwoch, 9. Dezember 2015, 17:04:12 schrieb Jeffy Chen:
> Initial release for rk3228 shared dtsi.
>
> Signed-off-by: Jeffy Chen
> ---
>
> arch/arm/boot/dts/rk3228.dtsi | 478
> ++
> 1 file changed, 478 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk3228.dtsi
>
> diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
> new file mode 100644
> index 000..d6b3e40
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3228.dtsi
> @@ -0,0 +1,478 @@
> +/*
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file 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 file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "rockchip,rk3228";
> +
> + interrupt-parent = <&gic>;
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x6000 0x4000>;
> + };
The amount of memory is a property of the board
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
no enable-method?
As the rk3228 also does not have a pmu, does the newly created
"rockchip,rk3036-smp" work for you?
> +
> + cpu0: cpu@f00 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0xf00>;
> + resets = <&cru SRST_CORE0>;
> + operating-points = <
> + /* KHzuV */
> + 816000 100
> + >;
> + clock-latency = <4>;
> + clocks = <&cru ARMCLK>;
> + };
> +
> + cpu1: cpu@f01 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0xf01>;
> + resets = <&cru SRST_CORE1>;
> + };
> +
> + cpu2: cpu@f02 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0xf02>;
> + resets = <&cru SRST_CORE2>;
> + };
> +
> + cpu3: cpu@f03 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a7";
> + reg = <0xf03>;
> + resets = <&cru SRST_CORE3>;
> + };
> + };
> +
> + amba {
> + compatible = "arm,amba-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + pdma: pdma@110f {
> + compatible = "arm,pl330", "arm,primecell";
> + reg = <0x110f 0x4000>;
> + interrupts = ,
> + ;
> + #dma-cells = <1>;
> +
Re: [PATCH v2 00/19] PM / devferq: Add generic exynos bus frequency driver and new passive governor
Hi Anand,
First of all, thanks for trying to test this series.
On 2015년 12월 10일 04:05, Anand Moon wrote:
> Hi Chanwoo Choi,
>
> On 9 December 2015 at 09:37, Chanwoo Choi wrote:
>> This patch-set includes the two features as following. The generic exynos bus
>> frequency driver is able to support almost Exynos SoCs for bus frequency
>> scaling. And the new passive governor is able to make the dependency on
>> between devices for frequency/voltage scaling. I had posted the patch-set[1]
>> with the similiar concept. This is is revised version for exynos bus
>> frequency.
>> - Generic exynos bus frequency driver
>> - New passive governor of DEVFREQ framework
>>
>> Depends on:
>> - This patch-set is based on devfreq.git[2].
>> [1] https://lkml.org/lkml/2015/1/7/872
>>: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
>> [2] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
>> for-rafael)
>>
>> Changes from v1:
>> (https://lkml.org/lkml/2015/11/26/260)
>> - Check whether the instance of regulator is NULL or not
>> when executing regulator_disable() because of only parent
>> devfreq device has the regulator instance. After fixing it,
>> the wake-up from suspend state is well working. (patch1)
>> - Fix bug which checks 'bus-clk' instead of 'bus->regulator'
>> after calling devm_clk_get() (on patch1)
>> - Update the documentation to remove the description about
>> DEVFREQ-EVENT subsystem (on patch2)
>> - Add the full name of DMC (Dynamic Memory Controller) (on patch2)
>> - Modify the detailed correlation of buses for Exynos3250
>> on documentation (patch2)
>> - Add the MFC bus node for Exynos3250 (on patch11, patch12)
>> - Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
>> - Add the PPMU node for exynos4412-odroidu3
>> - Add the support of bus frequency for exynos4412-odroidu3
>>
>> Detailed descirption for patch-set:
>> 1. Add generic exynos bus frequency driver
>> : This patch-set adds the generic exynos bus frequency driver for AXI bus
>> of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
>> architecture for bus between DRAM and sub-blocks in SoC.
>>
>> There are the different buses according to Exynos SoC because Exynos SoC
>> has the differnt sub-blocks and bus speed. In spite of this difference
>> among Exynos SoCs, this driver is able to support almost Exynos SoC by adding
>> unique data of each bus in the devicetree file.
>>
>> In devicetree, each bus node has a bus clock, regulator, operation-point
>> and devfreq-event devices which measure the utilization of each bus block.
>>
>> For example,
>> - The bus of DMC block in exynos3250.dtsi are listed below:
>>
>> bus_dmc: bus_dmc {
>> compatible = "samsung,exynos-bus";
>> 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 <13400>;
>> 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>;
>> vdd-supply = <&buck1_reg>; /* VDD_MIF */
>> status = "okay";
>> };
>>
>> 2. Add new passive governor of DEVFREQ framework (patch5-patch7)
>> : This patch-set add the new passive governor for DEVFREQ framework.
>> The existing governors (ondemand, performance and so on) are used for DVFS
>> (Dynamic Voltage and Frequency Scaling) drivers. The existing governors
>> are independently used for specific device driver which don't give the
>> influence to other device drviers and also don't receive the effect from
>> other device drivers.
>>
>> The passive governor depends on operation of parent driver with existing
>> governors(ondemand, performance and so on) extremely and is not able to
>> decide the new frequency by oneself. According to the decided new frequency
>> of parent driv
Re: [PATCH v1 4/8] dt-bindings: add documentation of rk3228 clock controller
Am Mittwoch, 9. Dezember 2015, 17:04:09 schrieb Jeffy Chen: > Add the devicetree binding for the cru on the rk3228 which quite similar > structured as previous clock controllers. > > Signed-off-by: Jeffy Chen applied to my clock branch with Rob's ack -- 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
Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
[+cc Michal, Paul, Thierry, Stephen, Alexandre (see irq_dispose_mapping
questions below)]
On Sun, Nov 29, 2015 at 05:33:53PM +0530, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
>
> Signed-off-by: Bharat Kumar Gogada
> Signed-off-by: Ravi Kiran Gummaluri
> Acked-by: Rob Herring
This needs either a MAINTAINERS update or an ack from Michal (whose
MAINTAINERS entry matches anything containing "xilinx").
> ---
> Changes for v11:
> -> Changed data types of bridge, pcie controller and ecam base address
> -> Added programming of E_BREG_BASE_HI, E_ECAM_BASE_HI registers
> -> Removed MSI_ADDRESS macro, and using value from device tree
> -> Removed unneccessary type casting in nwl_pcie_bridge_init function.
> -> Removed mdelay and using msleep in nwl_pcie_bridge_init function.
> ---
> .../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 68 ++
> drivers/pci/host/Kconfig | 10 +
> drivers/pci/host/Makefile |1 +
> drivers/pci/host/pcie-xilinx-nwl.c | 1072
>
> 4 files changed, 1151 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
>
> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> new file mode 100644
> index 000..3b2a9ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> @@ -0,0 +1,68 @@
> +* Xilinx NWL PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- reg: Should contain Bridge, PCIe Controller registers location,
> + configuration sapce, and length
> +- reg-names: Must include the following entries:
> + "breg": bridge registers
> + "pcireg": PCIe controller registers
> + "cfg": configuration space region
> +- device_type: must be "pci"
> +- interrupts: Should contain NWL PCIe interrupt
> +- interrupt-names: Must include the following entries:
> + "msi1, msi0": interrupt asserted when msi is received
> + "intx": interrupt that is asserted when an legacy interrupt is received
> + "misc": interrupt asserted when miscellaneous is received
> +- interrupt-map-mask and interrupt-map: standard PCI properties to define the
> + mapping of the PCI interface to interrupt numbers.
> +- ranges: ranges for the PCI memory regions (I/O space region is not
> + supported by hardware)
> + Please refer to the standard PCI bus binding document for a more
> + detailed explanation
> +- msi-controller: indicates that this is MSI controller node
> +- msi-parent: MSI parent of the root complex itself
> +- legacy-interrupt-controller: Interrupt controller device node for Legacy
> interrupts
> + - interrupt-controller: identifies the node as an interrupt controller
> + - #interrupt-cells: should be set to 1
> + - #address-cells: specifies the number of cells needed to encode an
> + address. The value must be 0.
> +
> +
> +Example:
> +
> +
> +nwl_pcie: pcie@fd0e {
> + #address-cells = <3>;
> + #size-cells = <2>;
> + compatible = "xlnx,nwl-pcie-2.11";
> + #interrupt-cells = <1>;
> + msi-controller;
> + device_type = "pci";
> + interrupt-parent = <&gic>;
> + interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
> + interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
> + <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
> + <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
> + <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
> +
> + msi-parent = <&nwl_pcie>;
> + reg = <0x0 0xfd0e 0x1000>,
> + <0x0 0xfd48 0x1000>,
> + <0x0 0xe000 0x100>;
> + reg-names = "breg", "pcireg", "cfg";
> + ranges = <0x0200 0x 0xe100 0x 0xe100 0
> 0x0f00>;
> +
> + pcie_intc: legacy-interrupt-controller {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <1>;
> + };
> +
> +};
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index d5e58ba..24cbcba 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,16 @@ config PCI_MVEBU
> depends on ARCH_MVEBU || ARCH_DOVE
> depends on OF
>
> +config PCIE_XILINX_NWL
> + bool "NWL PCIe Core"
> + depends on ARCH_ZYNQMP
> + select PCI_MSI_IRQ_DOMAIN if PCI_MSI
> +
Re: [PATCH v1 2/8] clk: rockchip: add dt-binding header for rk3228
Am Mittwoch, 9. Dezember 2015, 17:04:07 schrieb Jeffy Chen: > Add the dt-bindings header for the rk3228, that gets shared between > the clock controller and the clock references in the dts. > > Signed-off-by: Jeffy Chen applied to my clk branch for 4.5 -- 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
Re: [PATCH v1 4/8] dt-bindings: add documentation of rk3228 clock controller
Hi Rob, Am Mittwoch, 9. Dezember 2015, 14:12:00 schrieb Rob Herring: > On Wed, Dec 09, 2015 at 05:04:09PM +0800, Jeffy Chen wrote: > > Add the devicetree binding for the cru on the rk3228 which quite similar > > structured as previous clock controllers. > > > > Signed-off-by: Jeffy Chen > > Seems like there is a lot of duplication across Rockchip cru bindings. > Perhaps they should be combined? You're right and I've put that on my list for the near future. > Otherwise: > > Acked-by: Rob Herring Thanks Heiko -- 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
Re: [PATCH 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > Add mt2701 support using mediatek common pinctrl driver. > MT2701 have some special pins need an extra setting register > than other ICs, so adding this support to common code. > > Signed-off-by: Biao Huang This looks uncontroversial, but I would like to have some of the other Mediatek driver authors send their Ack/Review tags, so Hongzhou & Yingjoe: can you review this and the other patch to the pin control driver? Yours, Linus Walleij -- 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
Re: [PATCH 5/5] arm: dts: Add pinctrl/GPIO/EINT node for mt2701
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > Add pinctrl and GPIO node to mt2701.dtsi > > Signed-off-by: Biao Huang Acked-by: Linus Walleij Take this through the ARM SoC tree as well. Yours, Linus Walleij -- 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
Re: [PATCH 3/5] pinctrl: dt bindings: Add pinfunc header file for mt2701
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > Add pinfunc header file, mt2701 related dts will include it > > Signed-off-by: Biao Huang Acked-by: Linus Walleij Take this through ARM SoC as well. Yours, Linus Walleij -- 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
Re: [PATCH 1/5] ARM: mediatek: Add MT2701 config options for mediatek SoCs.
On Thu, Nov 26, 2015 at 9:44 AM, Biao Huang wrote: > From: Erin Lo > > The upcoming MTK pinctrl driver have a big pin table for each SoC > and we don't want to bloat the kernel binary if we don't need it. > Add config options so we can build for one SoC only. Add MT2701. > > Signed-off-by: Erin Lo Acked-by: Linus Walleij FWIW, take this through the ARM SoC tree, since it's just a Kconfig symbol, the pin control patches should be possible to merge orthogonally. Yours, Linus Walleij -- 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
[PATCH v4 2/2] arm: pxa27x: support for ICP DAS LP-8x4x w/ DT
ICP DAS calls LP-8x4x 'programmable automation controller'. It is
an industrial computer based on PXA270 SoC. They ship it with a 2.6.19
kernel and proprietary kernel module and userspace library to access
its industrial IO.
This patch allows to boot a modern kernel with device tree on
the device. It adds support for:
* MMC card interface on PXA270
* USB 1.1 port on PXA270
* 2 NOR flash devices
* 2 onboard ethernet Davicom DM9000 devices
* 3 serial UART ports on PXA270
* front panel red LED
* 64bit 1-wire system ID chip
* 16 kiB EEPROM (reading)
Support for these devices will be added in separate patches, since
they are not currently supported by the kernel:
* DS1302 RTC
* 512kiB SRAM
* FPGA irq chip
* 3 built-in 16550A serial UART ports
* industrial IO parallel bus
* 10 position rotary switch
* 8 pin DIP switch
* 16 kiB EEPROM (writing)
* serial interface for digital and analog industrial IO modules on
parallel bus (all I-87xxx modules)
* digital and analog industrial IO modules for parallel bus:
** I-8024 4 port analog output
** I-8041 32 port digital output
** I-8042 16 port digital output/16 port digital input
Not supported for now:
* VGA interface on PXA270 for lack of dts binding
* the rest of parallel bus (I-8xxx) modules for lack of hardware
* GPIO reset for lack of relevance (watchdog reset is working)
Newer LP-8x4x devices have twice as much flash and a different
partition structure otherwise being the same. When each device
is provided with a correct device tree, all of them can be booted
using the same kernel.
Signed-off-by: Sergei Ianovich
CC: Daniel Mack
CC: Robert Jarzmik
CC: Arnd Bergmann
---
v3..v4
* support for newer flavor w/ 96Mb flash memory
* use 'partitions' subnodes
* move device-specific tweaking to device .dts file and drop
patches to pxa27x.dtsi
v2..v3
* added extbus which maps synchronous, static, and variable-latency
I/O (VLIO) interfaces of PXA27x SoC as suggested by Arnd Bergmann
* map is placed into platform include
* configured existing kernel drivers to support:
- front panel LED using gpio-leds
- 64bit 1-wire system ID chip using w1-gpio
- 16 kiB EEPROM using at24 over i2c-gpio
* number change (06/16 -> 08/21)
v1..v2
* drop left-over extern declaration
* use of_have_populated_dt() instead of a static variable
* drop wildcards in compatible
* drop machine-special machine description
* number changed from 9 to 6 (dropped patches)
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/boot/dts/Makefile | 3 +
arch/arm/boot/dts/pxa27x-lp8x4x-i105.dts | 50
arch/arm/boot/dts/pxa27x-lp8x4x.dts| 260 +
arch/arm/configs/lp8x4x_defconfig | 176 ++
5 files changed, 490 insertions(+)
create mode 100644 arch/arm/boot/dts/pxa27x-lp8x4x-i105.dts
create mode 100644 arch/arm/boot/dts/pxa27x-lp8x4x.dts
create mode 100644 arch/arm/configs/lp8x4x_defconfig
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 55df1d4..2f1b078 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -109,6 +109,7 @@ honeywell Honeywell
hp Hewlett Packard
i2se I2SE GmbH
ibmInternational Business Machines (IBM)
+icpdas ICP DAS CO., LTD.
idtIntegrated Device Technologies, Inc.
iomIomega Corporation
imgImagination Technologies Ltd.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..ed182ea 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -499,6 +499,9 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
orion5x-rd88f5182-nas.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
+dtb-$(CONFIG_MACH_PXA27X_DT) += \
+ pxa27x-lp8x4x.dtb \
+ pxa27x-lp8x4x-i105.dtb
dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
diff --git a/arch/arm/boot/dts/pxa27x-lp8x4x-i105.dts
b/arch/arm/boot/dts/pxa27x-lp8x4x-i105.dts
new file mode 100644
index 000..903f5c7
--- /dev/null
+++ b/arch/arm/boot/dts/pxa27x-lp8x4x-i105.dts
@@ -0,0 +1,50 @@
+/* Device tree for ICP DAS LP-8x4x i105 flavor */
+
+#include "pxa27x-lp8x4x.dts"
+
+/ {
+ extbus {
+ flash@0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x0400>;
+ bank-width = <4>;
+ device-width = <2>;
+
+ partitions {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ fs@0 {
+ label = "u-boot";
+ reg = <0 0x4>;
+ };
+ fs@4 {
+
[PATCH linux-next 2/2] power: bcm6358-power: Add BCM6358 power domain controller support
The BCM6358 contains power domains controlled with a register. Power
domains are indexed by bits in the register. Power domain bits can be
interleaved with other status bits and clocks in the same register.
Newer SoCs with dedicated power domain registers are active low.
Signed-off-by: Simon Arlott
---
MAINTAINERS | 1 +
drivers/power/Kconfig | 11 +++
drivers/power/Makefile| 1 +
drivers/power/bcm6358-power.c | 198 ++
4 files changed, 211 insertions(+)
create mode 100644 drivers/power/bcm6358-power.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 0370aba..5546a53 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2391,6 +2391,7 @@ F:drivers/clk/bcm/clk-bcm6345*
F: drivers/irqchip/irq-bcm63*
F: drivers/irqchip/irq-bcm7*
F: drivers/irqchip/irq-brcmstb*
+F: drivers/power/bcm6358*
F: drivers/reset/bcm/reset-bcm6345*
F: include/linux/bcm63xx_wdt.h
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 1ddd13c..3d6f842 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -506,3 +506,14 @@ endif # POWER_SUPPLY
source "drivers/power/reset/Kconfig"
source "drivers/power/avs/Kconfig"
+
+config BCM6358_POWER
+ bool "BCM6358 power domain support"
+ depends on BMIPS_GENERIC && PM && OF
+ select PM_GENERIC_DOMAINS
+ select PM_GENERIC_DOMAINS_OF
+ default BMIPS_GENERIC
+ help
+ Say Y here to enable support for power domains on the BCM6358.
+ Required to ensure that power is enabled for SoC peripheral
+ devices, and that power is disabled to unused devices.
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 0e4eab5..0b72dd2 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_GENERIC_ADC_BATTERY) += generic-adc-battery.o
obj-$(CONFIG_PDA_POWER)+= pda_power.o
obj-$(CONFIG_APM_POWER)+= apm_power.o
obj-$(CONFIG_AXP20X_POWER) += axp20x_usb_power.o
+obj-$(CONFIG_BCM6358_POWER)+= bcm6358-power.o
obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
obj-$(CONFIG_WM831X_BACKUP)+= wm831x_backup.o
obj-$(CONFIG_WM831X_POWER) += wm831x_power.o
diff --git a/drivers/power/bcm6358-power.c b/drivers/power/bcm6358-power.c
new file mode 100644
index 000..f4654d7
--- /dev/null
+++ b/drivers/power/bcm6358-power.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright 2015 Simon Arlott
+ *
+ * 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
+
+#define BITS 32
+
+struct bcm6358_power;
+
+struct bcm6358_power_dev {
+ struct generic_pm_domain genpd;
+ struct bcm6358_power *power;
+ u32 bit;
+};
+
+struct bcm6358_power {
+ struct regmap *map;
+ u32 offset;
+ bool active_low;
+
+ struct bcm6358_power_dev dev[BITS];
+ struct genpd_onecell_data genpd_data;
+ struct generic_pm_domain *genpd[BITS];
+};
+
+static int bcm6358_power_get_state(struct bcm6358_power_dev *pmd,
+ bool *is_on)
+{
+ struct bcm6358_power *power = pmd->power;
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(power->map, power->offset, &val);
+ if (ret) {
+ *is_on = false;
+ return ret;
+ }
+
+ if (power->active_low)
+ *is_on = !(val & pmd->bit);
+ else
+ *is_on = (val & pmd->bit);
+ return 0;
+}
+
+static int bcm6358_power_set_state(struct bcm6358_power_dev *pmd,
+ bool on)
+{
+ struct bcm6358_power *power = pmd->power;
+ u32 val;
+
+ if (power->active_low)
+ val = on ? 0 : pmd->bit;
+ else
+ val = on ? pmd->bit : 0;
+
+ return regmap_update_bits(power->map, power->offset, pmd->bit, val);
+}
+
+static int bcm6358_power_power_on(struct generic_pm_domain *genpd)
+{
+ struct bcm6358_power_dev *pmd = container_of(genpd,
+ struct bcm6358_power_dev, genpd);
+
+ return bcm6358_power_set_state(pmd, true);
+}
+
+static int bcm6358_power_power_off(struct generic_pm_domain *genpd)
+{
+ struct bcm6358_power_dev *pmd = container_of(genpd,
+ struct bcm6358_power_dev, genpd);
+
+ return bcm6358_power_set_state(pmd, false);
+}
+
+static int __init bcm6358_power_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_n
[PATCH linux-next 1/2] power: Add brcm,bcm6358-power-controller device tree binding
The BCM6358 contains power domains controlled with a register. Power
domains are indexed by bits in the register. Power domain bits can be
interleaved with other status bits and clocks in the same register.
Newer SoCs with dedicated power domain registers are active low.
Signed-off-by: Simon Arlott
---
.../power/brcm,bcm6358-power-controller.txt| 53 ++
1 file changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt
diff --git
a/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt
b/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt
new file mode 100644
index 000..556c323
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt
@@ -0,0 +1,53 @@
+Broadcom BCM6358 Power domain controller
+
+This binding uses the power domain bindings:
+Documentation/devicetree/bindings/power/power_domain.txt
+
+The BCM6358 contains power domains controlled with a register. Power
+domains are indexed by bits in the register. Power domain bits can be
+interleaved with other status bits and clocks in the same register.
+
+Newer SoCs with dedicated power domain registers are active low.
+
+Required properties:
+- compatible: Should be "brcm,bcm-power-controller",
"brcm,bcm6358-power-controller"
+- #power-domain-cells: Should be <1>.
+- regmap: The register map phandle
+- offset: Offset in the register map for the power domain
register (in bytes)
+- power-domain-indices: The bits in the register used for power domains.
+- power-domain-names: Should be a list of strings of power domain names
+indexed by the power domain indices.
+
+Optional properties:
+- active-low: Specify that the bits are active low.
+
+Example:
+
+misc_iddq_ctrl: power-controller {
+ compatible = "brcm,bcm63168-power-controller",
"brcm,bcm6358-power-controller";
+ regmap = <&misc>;
+ offset = <0x4c>;
+
+ #power-domain-cells = <1>;
+ power-domain-indices =
+ <0>, <1>, <2>,<3>, <4>,
+ <5>, <6>, <7>,<8>, <9>,
+ <10>,<11>, <12>, <13>,<17>,
+ <18>;
+ power-domain-names =
+ "sar", "ipsec", "mips", "dect", "usbh",
+ "usbd", "robosw", "pcm", "periph","vdsl_phy",
+ "vdsl_mips", "fap","pcie", "wlan_pads", "gphy",
+ "gmac";
+ active-low;
+};
+
+periph_iddq: power-controller {
+ compatible = "brcm,bcm6368-power-controller",
"brcm,bcm6358-power-controller";
+ regmap = <&periph_cntl>;
+ offset = <0x4>;
+
+ #power-domain-cells = <1>;
+ power-domain-indices = <19>;
+ power-domain-names = "usbh";
+};
--
2.1.4
--
Simon Arlott
--
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
Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding
Hi,
On Wed, Dec 09, 2015 at 09:42:09AM -0800, Tim Bird wrote:
> Or maybe our power maintainers will chime in with some wisdom. I
> can't be the first person to be adding a charge pathway switch to
> mainline, so I'm open to doing it the "right way". :-)
I don't think there is a standard way for this so far. Another
otg charger coming to my mindis bq2415x, which basically just
exposes the enable bit via sysfs.
Exposing the switch as regulator would be fine for me.
> > Thinking about this some more, the node name should be generic, so
> > just "regulator". The label does not need to be generic.
>
> There are other switches in the charger block that are not
> exposed yet. This one handles the the OTG (vbus) charge pathway.
> Others handle other charge pathways (some of which are used on phones
> and some are not - they're used, e.g., on the dragonboard). I'd
> rather not give it a generic name, because eventually the driver
> should expose those other switches as something as well.
otg_regulator: regulator@0 { }
other_regulator: regulator@1 { }
-- Sebastian
signature.asc
Description: PGP signature
Re: [PATCH 2/3] dt-bindings: add Silicon Image SiI8620 bridge bindings
On Wed, Dec 9, 2015 at 3:58 AM, Andrzej Hajda wrote:
> Hi Rob,
>
> Thanks for review.
>
>
> On 12/09/2015 04:47 AM, Rob Herring wrote:
>> On Tue, Dec 08, 2015 at 02:49:05PM +0100, Andrzej Hajda wrote:
>>> SiI8620 transmitter converts eTMDS/HDMI signal to MHL 3.0. It is controlled
>>> via I2C bus.
>>>
>>> Signed-off-by: Andrzej Hajda
>>> ---
>>> .../bindings/video/bridge/sil-sii8620.txt | 34
>>> ++
>>> 1 file changed, 34 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
>>> b/Documentation/devicetree/bindings/video/bridge/sil-sii8620.txt
[...]
>>> +port {
>>> +mhl_to_hdmi: endpoint {
>>> +remote-endpoint = <&hdmi_to_mhl>;
>>> +};
>>> +};
>> I'd like to see this have a port to a connector node, too. Possibly
>> that can come later.
>
> MHL standard is connector agnostic, usually MHL wires are routed
> via multi-function microUSB connector, which can serve also for
> USB/charging/UART
> There is additional logic to determine which cable is currently
> connected, usually
> implemented by extcon driver.
> I am not sure if/how it should be represented in DT. What do you think
> about it?
Probably all the more reason to have a connector defined, but for
muxed connectors I'm not sure how we should handle them and having
both drm connectors and extcon connectors is a problem. Like I said,
it can come later.
Rob
--
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
Re: [RFC][PATCH] misc: Introduce reboot_reason driver
On Wed, Dec 9, 2015 at 12:50 AM, Sascha Hauer wrote:
> On Tue, Dec 08, 2015 at 04:13:35PM -0800, John Stultz wrote:
>>
>> Is there a better way? Are enums for array indexes out of fashion?
>
> They are not, but you have declared a variable (reason_types) which you
> don't use. You probably meant to create a enum named reason_types, like
> this:
>
> enum reason_types {
> NONE,
> BOOTLOADER,
> RECOVERY,
> OEM,
> MAX_REASONS
> };
So I had tried using a enum name as well, close to what you suggest
here, and still got the "warning: useless storage class specifier in
empty declaration" build warning.
Though trying again, it seems the problem was I was declaring it as
"static enum ...". Removing the static allows it to build w/o warnings
as a unnamed enum structure. Why, I don't know. :P
Thanks for the pointer!
-john
--
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
Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding
On Wed, Dec 9, 2015 at 1:59 PM, Bjorn Andersson wrote: > On Wed 09 Dec 06:36 PST 2015, Rob Herring wrote: > >> On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird wrote: >> > On 12/08/2015 08:11 PM, Rob Herring wrote: >> >> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote: >> >>> Add a binding for the regulator which controls the OTG chargepath switch. >> >>> The OTG switch gets its power from pm8941_5vs1, and that should be >> >>> expressed as a usb-otg-in-supply property in the DT node for the >> >>> charger driver. The regulator name is "otg". >> >> [...] >> >> >>> +child nodes: >> >>> +- otg: >> >>> + Usage: optional >> >>> + Description: This node defines a regulator used to control the >> >>> direction >> >>> + of VBUS voltage - specifically: whether to supply voltage >> >>> + to VBUS for host mode operation of the OTG port, or allow >> >>> + input voltage from external VBUS for charging. In the >> >>> + hardware, the supply for this regulator comes from >> >>> + usb-otg-in-supply. >> >> >> >> Doesn't this regulator need to have a name defined? >> > >> > I'm not sure what you mean. The regulator name is "otg", defined by the >> > DT node >> > name. The code requires that the DT node name be "otg", and defines a >> > regulator >> > with the same name. >> > >> > As far as I know, you have to define a DT label for the node, in order >> > to reference this regulator with a phandle. Is that what you are >> > referring to? >> > I usually use "chg_otg" as the label. Are you asking that this be >> > reflected >> > in the example? >> >> You need a regulator-name property. Also, should should define valid >> values for regulator-min-microvolt and regulator-max-microvolt. >> > > The regulator has a name, derived from the node name, and this is > significant. If the developer wants an additional human readable name > for some reason they can use the optional regulator-name property. > > The regulator is a simple switch and as such inherits voltage properties > from its supply. It should therefor not have any specified voltage > range. > >> Thinking about this some more, the node name should be generic, so >> just "regulator". The label does not need to be generic. >> > > The name of the node is significant, as it's used for matching the > regulator to an implementation. Ah yes, you are right. I forget what an oddball the regulator binding is. And if voltage switches don't need min and max properties, then it is fine as is. Still, the empty node with no properties seems odd to me. Rob -- 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
Re: [PATCH linux-next (v2) 3/3] mtd: brcmnand: Add support for the BCM6368
Le 09/12/2015 12:43, Simon Arlott a écrit :
> The BCM6368 has a NAND interrupt register with combined status and enable
> registers.
>
> As the BCM6328, BCM6362 and BCM6368 all use v2.1 controllers, the first
> variant that will work with this driver is the BCM63268 using a v4.0
> controller.
>
> Set up the device by disabling and acking all interrupts, then handle
> the CTRL_READY interrupt.
>
> Signed-off-by: Simon Arlott
Reviewed-by: Florian Fainelli
> ---
> Changed "nand-intr-base" reg name to "nand-int-base".
>
> drivers/mtd/nand/brcmnand/Makefile | 1 +
> drivers/mtd/nand/brcmnand/bcm6368_nand.c | 145
> +++
> 2 files changed, 146 insertions(+)
> create mode 100644 drivers/mtd/nand/brcmnand/bcm6368_nand.c
>
> diff --git a/drivers/mtd/nand/brcmnand/Makefile
> b/drivers/mtd/nand/brcmnand/Makefile
> index 3b1fbfd..b28ffb59 100644
> --- a/drivers/mtd/nand/brcmnand/Makefile
> +++ b/drivers/mtd/nand/brcmnand/Makefile
> @@ -2,5 +2,6 @@
> # more specific iproc_nand.o, for instance
> obj-$(CONFIG_MTD_NAND_BRCMNAND) += iproc_nand.o
> obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm63138_nand.o
> +obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm6368_nand.o
> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmstb_nand.o
> obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand.o
> diff --git a/drivers/mtd/nand/brcmnand/bcm6368_nand.c
> b/drivers/mtd/nand/brcmnand/bcm6368_nand.c
> new file mode 100644
> index 000..7f5359b
> --- /dev/null
> +++ b/drivers/mtd/nand/brcmnand/bcm6368_nand.c
> @@ -0,0 +1,145 @@
> +/*
> + * Copyright 2015 Simon Arlott
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * Derived from bcm63138_nand.c:
> + * Copyright © 2015 Broadcom Corporation
> + *
> + * Derived from
> bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
> + * Copyright 2000-2010 Broadcom Corporation
> + *
> + * Derived from
> bcm963xx_4.12L.06B_consumer/shared/opensource/flash/nandflash.c:
> + * Copyright 2000-2010 Broadcom Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "brcmnand.h"
> +
> +struct bcm6368_nand_soc {
> + struct brcmnand_soc soc;
> + void __iomem *base;
> +};
> +
> +#define BCM6368_NAND_INT 0x00
> +#define BCM6368_NAND_STATUS_SHIFT 0
> +#define BCM6368_NAND_STATUS_MASK(0xfff << BCM6368_NAND_STATUS_SHIFT)
> +#define BCM6368_NAND_ENABLE_SHIFT 16
> +#define BCM6368_NAND_ENABLE_MASK(0x << BCM6368_NAND_ENABLE_SHIFT)
> +#define BCM6368_NAND_BASE_ADDR0 0x04
> +#define BCM6368_NAND_BASE_ADDR1 0x0c
> +
> +enum {
> + BCM6368_NP_READ = BIT(0),
> + BCM6368_BLOCK_ERASE = BIT(1),
> + BCM6368_COPY_BACK = BIT(2),
> + BCM6368_PAGE_PGM= BIT(3),
> + BCM6368_CTRL_READY = BIT(4),
> + BCM6368_DEV_RBPIN = BIT(5),
> + BCM6368_ECC_ERR_UNC = BIT(6),
> + BCM6368_ECC_ERR_CORR= BIT(7),
> +};
> +
> +static bool bcm6368_nand_intc_ack(struct brcmnand_soc *soc)
> +{
> + struct bcm6368_nand_soc *priv =
> + container_of(soc, struct bcm6368_nand_soc, soc);
> + void __iomem *mmio = priv->base + BCM6368_NAND_INT;
> + u32 val = brcmnand_readl(mmio);
> +
> + if (val & (BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT)) {
> + /* Ack interrupt */
> + val &= ~BCM6368_NAND_STATUS_MASK;
> + val |= BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT;
> + brcmnand_writel(val, mmio);
> + return true;
> + }
> +
> + return false;
> +}
> +
> +static void bcm6368_nand_intc_set(struct brcmnand_soc *soc, bool en)
> +{
> + struct bcm6368_nand_soc *priv =
> + container_of(soc, struct bcm6368_nand_soc, soc);
> + void __iomem *mmio = priv->base + BCM6368_NAND_INT;
> + u32 val = brcmnand_readl(mmio);
> +
> + /* Don't ack any interrupts */
> + val &= ~BCM6368_NAND_STATUS_MASK;
> +
> + if (en)
> + val |= BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT;
> + else
> + val &= ~(BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT);
> +
> + brcmnand_writel(val, mmio);
> +}
> +
> +static int bcm6368_nand_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct bcm6368_nand_soc *priv;
> + struct brcmnand_soc *soc;
> + struct resource *res;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (
Re: [PATCH linux-next (v2) 2/3] mtd: brcmnand: Request and enable the clock if present
Le 09/12/2015 12:42, Simon Arlott a écrit :
> Attempt to enable a clock named "nand" as some SoCs have a clock for the
> controller that needs to be enabled.
>
> Signed-off-by: Simon Arlott
Reviewed-by: Florian Fainelli
> ---
> Resend, no changes.
>
> drivers/mtd/nand/brcmnand/brcmnand.c | 64
>
> 1 file changed, 50 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index 190a99a..dca8162 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -11,6 +11,7 @@
> * GNU General Public License for more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -122,6 +123,9 @@ struct brcmnand_controller {
> /* Some SoCs provide custom interrupt status register(s) */
> struct brcmnand_soc *soc;
>
> + /* Some SoCs have a gateable clock for the controller */
> + struct clk *clk;
> +
> int cmd_pending;
> booldma_pending;
> struct completion done;
> @@ -2127,10 +2131,24 @@ int brcmnand_probe(struct platform_device *pdev,
> struct brcmnand_soc *soc)
> if (IS_ERR(ctrl->nand_base))
> return PTR_ERR(ctrl->nand_base);
>
> + /* Enable clock before using NAND registers */
> + ctrl->clk = devm_clk_get(dev, "nand");
> + if (!IS_ERR(ctrl->clk)) {
> + ret = clk_prepare_enable(ctrl->clk);
> + if (ret)
> + return ret;
> + } else {
> + ret = PTR_ERR(ctrl->clk);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + ctrl->clk = NULL;
> + }
> +
> /* Initialize NAND revision */
> ret = brcmnand_revision_init(ctrl);
> if (ret)
> - return ret;
> + goto err;
>
> /*
>* Most chips have this cache at a fixed offset within 'nand' block.
> @@ -2139,8 +2157,10 @@ int brcmnand_probe(struct platform_device *pdev,
> struct brcmnand_soc *soc)
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand-cache");
> if (res) {
> ctrl->nand_fc = devm_ioremap_resource(dev, res);
> - if (IS_ERR(ctrl->nand_fc))
> - return PTR_ERR(ctrl->nand_fc);
> + if (IS_ERR(ctrl->nand_fc)) {
> + ret = PTR_ERR(ctrl->nand_fc);
> + goto err;
> + }
> } else {
> ctrl->nand_fc = ctrl->nand_base +
> ctrl->reg_offsets[BRCMNAND_FC_BASE];
> @@ -2150,8 +2170,10 @@ int brcmnand_probe(struct platform_device *pdev,
> struct brcmnand_soc *soc)
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "flash-dma");
> if (res) {
> ctrl->flash_dma_base = devm_ioremap_resource(dev, res);
> - if (IS_ERR(ctrl->flash_dma_base))
> - return PTR_ERR(ctrl->flash_dma_base);
> + if (IS_ERR(ctrl->flash_dma_base)) {
> + ret = PTR_ERR(ctrl->flash_dma_base);
> + goto err;
> + }
>
> flash_dma_writel(ctrl, FLASH_DMA_MODE, 1); /* linked-list */
> flash_dma_writel(ctrl, FLASH_DMA_ERROR_STATUS, 0);
> @@ -2160,13 +2182,16 @@ int brcmnand_probe(struct platform_device *pdev,
> struct brcmnand_soc *soc)
> ctrl->dma_desc = dmam_alloc_coherent(dev,
>sizeof(*ctrl->dma_desc),
>&ctrl->dma_pa, GFP_KERNEL);
> - if (!ctrl->dma_desc)
> - return -ENOMEM;
> + if (!ctrl->dma_desc) {
> + ret = -ENOMEM;
> + goto err;
> + }
>
> ctrl->dma_irq = platform_get_irq(pdev, 1);
> if ((int)ctrl->dma_irq < 0) {
> dev_err(dev, "missing FLASH_DMA IRQ\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto err;
> }
>
> ret = devm_request_irq(dev, ctrl->dma_irq,
> @@ -2175,7 +2200,7 @@ int brcmnand_probe(struct platform_device *pdev, struct
> brcmnand_soc *soc)
> if (ret < 0) {
> dev_err(dev, "can't allocate IRQ %d: error %d\n",
> ctrl->dma_irq, ret);
> - return ret;
> + goto err;
> }
>
> dev_info(dev, "enabling FLASH_DMA\n");
> @@ -2199,7 +2224,8 @@ int brcmnand_probe(struct platform_device *pdev, struct
> brcmnand_soc *soc)
> ctrl->irq = platform_get_irq(pdev, 0);
> if ((int)ctrl->irq < 0) {
> dev_err(dev, "no IRQ defined\n");
> - return -ENODEV;
> + ret = -ENODEV;
> + goto
Re: [PATCH linux-next (v2) 1/3] mtd: brcmnand: Add brcm,bcm6368-nand device tree binding
Le 09/12/2015 12:40, Simon Arlott a écrit :
> Add device tree binding for NAND on the BCM6368.
>
> The BCM6368 has a NAND interrupt register with combined status and enable
> registers. It also requires a clock, so add an optional clock to the
> common brcmnand binding.
>
Reviewed-by: Florian Fainelli
> Signed-off-by: Simon Arlott
> ---
> Changed "nand-intr-base" reg name to "nand-int-base".
>
> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 32
> ++
> 1 file changed, 32 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> index 4ff7128..ebfa6fc 100644
> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
> @@ -45,6 +45,8 @@ Required properties:
> - #size-cells : <0>
>
> Optional properties:
> +- clock : reference to the clock for the NAND controller
> +- clock-names : "nand" (required for the above clock)
> - brcm,nand-has-wp : Some versions of this IP include a
> write-protect
>(WP) control bit. It is always available on >=
>v7.0. Use this property to describe the rare
> @@ -72,6 +74,12 @@ we define additional 'compatible' properties and
> associated register resources w
> and enable registers
> - reg-names: (required) "nand-int-base"
>
> + * "brcm,nand-bcm6368"
> + - compatible: should contain "brcm,nand-bcm", "brcm,nand-bcm6368"
> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined
> status
> + and enable registers, and boot address registers
> + - reg-names: (required) "nand-int-base"
> +
> * "brcm,nand-iproc"
> - reg: (required) the "IDM" register range, for interrupt enable and APB
> bus access endianness configuration, and the "EXT" register range,
> @@ -148,3 +156,27 @@ nand@f0442800 {
> };
> };
> };
> +
> +nand@1200 {
> + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
> + "brcm,brcmnand-v4.0", "brcm,brcmnand";
> + reg = <0x1200 0x180>,
> + <0x1600 0x200>,
> + <0x10b0 0x10>;
> + reg-names = "nand", "nand-cache", "nand-intr-base";
> + interrupt-parent = <&periph_intc>;
> + interrupts = <50>;
> + clocks = <&periph_clk 20>;
> + clock-names = "nand";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + nand0: nandcs@0 {
> + compatible = "brcm,nandcs";
> + reg = <0>;
> + nand-on-flash-bbt;
> + nand-ecc-strength = <1>;
> + nand-ecc-step-size = <512>;
> + };
> +};
>
--
Florian
--
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
[GIT PULL] DeviceTree fixes for 4.4
Hi Linus, Please pull DT fixes for 4.4. I think this should be all for 4.4. Rob The following changes since commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8: Linux 4.4-rc3 (2015-11-29 18:58:26 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-fixes-for-4.4-rc4 for you to fetch changes up to eaddb5725357e9f05ffe5d271630f8197d089da4: of/irq: move of_msi_map_rid declaration to the correct ifdef section (2015-12-09 09:23:28 -0600) DeviceTree fixes for 4.4-rc4: - Fix incorrect warning about overlapping memory regions - Export of_irq_find_parent again which was made static in 4.4, but has users pending for 4.5. - Fix of_msi_map_rid declaration location - Fix re-entrancy for of_fdt_unflatten_tree - Clean-up of phys_addr_t printks Carlo Caione (1): of/irq: Export of_irq_find_parent again Dmitry V. Krivenok (1): of: do not use 0x in front of %pa Guenter Roeck (1): of/fdt: Add mutex protection for calls to __unflatten_device_tree() Masahiro Yamada (1): of/address: fix typo in comment block of of_translate_one() Michael Ellerman (1): of: Fix comparison of reserved memory regions Rob Herring (1): of/irq: move of_msi_map_rid declaration to the correct ifdef section drivers/of/address.c | 5 +++-- drivers/of/fdt.c | 7 ++- drivers/of/irq.c | 3 ++- drivers/of/of_reserved_mem.c | 8 +++- include/linux/of_irq.h | 19 --- 5 files changed, 30 insertions(+), 12 deletions(-) -- 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
[PATCH linux-next (v2) 3/3] mtd: brcmnand: Add support for the BCM6368
The BCM6368 has a NAND interrupt register with combined status and enable
registers.
As the BCM6328, BCM6362 and BCM6368 all use v2.1 controllers, the first
variant that will work with this driver is the BCM63268 using a v4.0
controller.
Set up the device by disabling and acking all interrupts, then handle
the CTRL_READY interrupt.
Signed-off-by: Simon Arlott
---
Changed "nand-intr-base" reg name to "nand-int-base".
drivers/mtd/nand/brcmnand/Makefile | 1 +
drivers/mtd/nand/brcmnand/bcm6368_nand.c | 145 +++
2 files changed, 146 insertions(+)
create mode 100644 drivers/mtd/nand/brcmnand/bcm6368_nand.c
diff --git a/drivers/mtd/nand/brcmnand/Makefile
b/drivers/mtd/nand/brcmnand/Makefile
index 3b1fbfd..b28ffb59 100644
--- a/drivers/mtd/nand/brcmnand/Makefile
+++ b/drivers/mtd/nand/brcmnand/Makefile
@@ -2,5 +2,6 @@
# more specific iproc_nand.o, for instance
obj-$(CONFIG_MTD_NAND_BRCMNAND)+= iproc_nand.o
obj-$(CONFIG_MTD_NAND_BRCMNAND)+= bcm63138_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMNAND)+= bcm6368_nand.o
obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmstb_nand.o
obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand.o
diff --git a/drivers/mtd/nand/brcmnand/bcm6368_nand.c
b/drivers/mtd/nand/brcmnand/bcm6368_nand.c
new file mode 100644
index 000..7f5359b
--- /dev/null
+++ b/drivers/mtd/nand/brcmnand/bcm6368_nand.c
@@ -0,0 +1,145 @@
+/*
+ * Copyright 2015 Simon Arlott
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * Derived from bcm63138_nand.c:
+ * Copyright © 2015 Broadcom Corporation
+ *
+ * Derived from
bcm963xx_4.12L.06B_consumer/shared/opensource/include/bcm963xx/63268_map_part.h:
+ * Copyright 2000-2010 Broadcom Corporation
+ *
+ * Derived from
bcm963xx_4.12L.06B_consumer/shared/opensource/flash/nandflash.c:
+ * Copyright 2000-2010 Broadcom Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "brcmnand.h"
+
+struct bcm6368_nand_soc {
+ struct brcmnand_soc soc;
+ void __iomem *base;
+};
+
+#define BCM6368_NAND_INT 0x00
+#define BCM6368_NAND_STATUS_SHIFT 0
+#define BCM6368_NAND_STATUS_MASK (0xfff << BCM6368_NAND_STATUS_SHIFT)
+#define BCM6368_NAND_ENABLE_SHIFT 16
+#define BCM6368_NAND_ENABLE_MASK (0x << BCM6368_NAND_ENABLE_SHIFT)
+#define BCM6368_NAND_BASE_ADDR00x04
+#define BCM6368_NAND_BASE_ADDR10x0c
+
+enum {
+ BCM6368_NP_READ = BIT(0),
+ BCM6368_BLOCK_ERASE = BIT(1),
+ BCM6368_COPY_BACK = BIT(2),
+ BCM6368_PAGE_PGM= BIT(3),
+ BCM6368_CTRL_READY = BIT(4),
+ BCM6368_DEV_RBPIN = BIT(5),
+ BCM6368_ECC_ERR_UNC = BIT(6),
+ BCM6368_ECC_ERR_CORR= BIT(7),
+};
+
+static bool bcm6368_nand_intc_ack(struct brcmnand_soc *soc)
+{
+ struct bcm6368_nand_soc *priv =
+ container_of(soc, struct bcm6368_nand_soc, soc);
+ void __iomem *mmio = priv->base + BCM6368_NAND_INT;
+ u32 val = brcmnand_readl(mmio);
+
+ if (val & (BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT)) {
+ /* Ack interrupt */
+ val &= ~BCM6368_NAND_STATUS_MASK;
+ val |= BCM6368_CTRL_READY << BCM6368_NAND_STATUS_SHIFT;
+ brcmnand_writel(val, mmio);
+ return true;
+ }
+
+ return false;
+}
+
+static void bcm6368_nand_intc_set(struct brcmnand_soc *soc, bool en)
+{
+ struct bcm6368_nand_soc *priv =
+ container_of(soc, struct bcm6368_nand_soc, soc);
+ void __iomem *mmio = priv->base + BCM6368_NAND_INT;
+ u32 val = brcmnand_readl(mmio);
+
+ /* Don't ack any interrupts */
+ val &= ~BCM6368_NAND_STATUS_MASK;
+
+ if (en)
+ val |= BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT;
+ else
+ val &= ~(BCM6368_CTRL_READY << BCM6368_NAND_ENABLE_SHIFT);
+
+ brcmnand_writel(val, mmio);
+}
+
+static int bcm6368_nand_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct bcm6368_nand_soc *priv;
+ struct brcmnand_soc *soc;
+ struct resource *res;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ soc = &priv->soc;
+
+ res = platform_get_resource_byname(pdev,
+ IORESOURCE_MEM, "nand-int-base");
+ if (!res)
+ return -EINVAL;
+
+ priv->base = devm_ioremap_resource(d
