Re: drm: exynos: mixer: fix using usleep() in atomic context
Hello, On 2015년 01월 22일 07:46, Tobias Jakobi wrote: > Hello! > > > Inki Dae wrote: >> The use of spin lock, reg_slock, has been used for a long time and we >> hadn't some cleanups to spin lock codes so far. The spin lock is also >> used in here and there of mixer driver. And at least, it seems that >> the use of spin lock isn't required in mixer_win_reset. I don't see >> any atomic contexts in mixer module except interrupt handler. >> >> To Seung-Woo, >> I know that you referred to mixer codes of v4l2 based mixer driver. So >> was the spin lock used in origin v4l2 driver? or Is there any reason >> that you used the spin lock? The spinlock usage was originated from Tomasz Stanislawski's s5p-tv. >> >> Anyway, we will have some testing to check hdmi and mixer drivers >> without spin lock. So we will remove or replace it with mutex if >> needed. >> >> Thanks, >> Inki Dae > > So it's some weeks later and as far as I can see there has been no > changes to the spinlock usage. Wouldn't it be better to apply this patch > _now_ (since the use of 'usleep_range' is just plain wrong while under > spinlock). When the spinlock setup gets cleaned up later, then we can > always change back to 'usleep_range' again. > > Any thoughts? In s5p-tv, same patch is already applied by Tomasz, so I agree to apply this patch also. Best Regards, - Seung-Woo Kim > > With best wishes, > Tobias > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Seung-Woo Kim Samsung Software R&D Center -- -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] ARM: dts: Add HS400 support for exynos5420 and exynos5800
Hi.
On 01/21/2015 11:12 PM, Alim Akhtar wrote:
> Hi Jaehoon
>
> On Wed, Jan 21, 2015 at 4:32 AM, Jaehoon Chung wrote:
>> Hi,
>>
>> If you want to enable the hs400 mode, need to add "mmc-hs400-1_8v" or
>> "mmc-hs400-1_2v".
>> But this patch didn't add them. do you have any other plan?
>>
> Yes, right, plan is to send separate patch to enable hs400, as of now
> I am not sure if all the 5800-peach-pi boards are populated with
> emmc5.0 device or not. So I will enable HS400 after confirming this
> point.
I know if card is not support hs400, then it should be enabled to other bus
mode.
Best Regards,
Jaehoon Chung
>> On 01/14/2015 07:30 PM, Alim Akhtar wrote:
>>> From: Seungwon Jeon
>>>
>>> HS400 timing values are added for SMDK5420, exynos5420-peach-pit
>>> and exynos5800-peach-pi boards.
>>> This also adds RCLK GPIO line, this gpio should be in pull-down
>>> state.
>>>
>>> Signed-off-by: Seungwon Jeon
>>> Signed-off-by: Alim Akhtar
>>> [Alim: addressed review comments]
>>> ---
>>> arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +++-
>>> arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 +++
>>> arch/arm/boot/dts/exynos5420-smdk5420.dts |4 +++-
>>> arch/arm/boot/dts/exynos5800-peach-pi.dts |4 +++-
>>> 4 files changed, 16 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> index 9a050e1..7ffaba8 100644
>>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>>> @@ -569,8 +569,10 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> + samsung,dw-mshc-hs400-timing = <0 2>;
>>> + read-strobe-delay = <90>;
>>> pinctrl-names = "default";
>>> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>>> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>>> bus-width = <8>;
>>> };
>>>
>>> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>>> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>>> index ba686e4..8b15316 100644
>>> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>>> @@ -201,6 +201,13 @@
>>> samsung,pin-drv = <3>;
>>> };
>>>
>>> + sd0_rclk: sd0-rclk {
>>
>> I know it used to "sd0_rdqs", not "sd0_rclk".
>> Change name.
>>
> Ok, I will change as per UM of 5800/5420,
>
>> Best Regards,
>> Jaehoon Chung
>>> + samsung,pins = "gpc0-7";
>>> + samsung,pin-function = <2>;
>>> + samsung,pin-pud = <1>;
>>> + samsung,pin-drv = <3>;
>>> + };
>>> +
>>> sd1_cmd: sd1-cmd {
>>> samsung,pins = "gpc1-1";
>>> samsung,pin-function = <2>;
>>> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>>> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>>> index 8be3d7b..5290e79 100644
>>> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>>> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>>> @@ -80,8 +80,10 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> + samsung,dw-mshc-hs400-timing = <0 2>;
>>> + read-strobe-delay = <90>;
>>> pinctrl-names = "default";
>>> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>>> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>>> bus-width = <8>;
>>> cap-mmc-highspeed;
>>> };
>>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> index e8fdda8..fa1c858 100644
>>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>>> @@ -557,8 +557,10 @@
>>> samsung,dw-mshc-ciu-div = <3>;
>>> samsung,dw-mshc-sdr-timing = <0 4>;
>>> samsung,dw-mshc-ddr-timing = <0 2>;
>>> + samsung,dw-mshc-hs400-timing = <0 2>;
>>> + read-strobe-delay = <90>;
>>> pinctrl-names = "default";
>>> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>>> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>>> bus-width = <8>;
>>> };
>>>
>>>
>>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] power: reset: add driver for Hardkernel's Odroid boards
Hi,
On 01/22/2015 10:06 AM, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Oct 29, 2014 at 02:13:28PM +0100, Marek Szyprowski wrote:
>> This patch adds a driver implementing correct reboot and poweroff
>> procedures for Exynos4412-based Hardkernel's Odroid X/X2/U2/U3/U3+
>> boards.
>
> Sorry it took so long. I have a couple of small requests before
> applying this (comments inline).
>
>> Signed-off-by: Marek Szyprowski
>> ---
>> .../bindings/power/reset/odroid-reset.txt | 18
>> drivers/power/reset/Kconfig| 6 ++
>> drivers/power/reset/Makefile | 1 +
>> drivers/power/reset/odroid-reboot.c| 119
>> +
>> 4 files changed, 144 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/power/reset/odroid-reset.txt
>> create mode 100644 drivers/power/reset/odroid-reboot.c
>>
>> diff --git a/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
>> b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
>> new file mode 100644
>> index ..86471a463518
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
>> @@ -0,0 +1,18 @@
>> +* Device tree bindings for Hardkernel's Exynos4412 based Odroid boards
>> +
>> +This node is intended to allow proper system reboot and power off of
>> +Odroid X/X2/U2/U3/U3+ boards with eMMC storage. Without this node, board
>> +hangs during standard reset procedure.
>> +
>> +Required properties:
>> +- compatible: hardkernel,odroid-reboot
>> +- samsung,pmureg-phandle: phandle to Exynos PMU node
>> +- reset-gpios: phandle and gpio-specifier to the GPIO
>> pin
>> +connected to the eMMC_nDET
>> +
>> +Example:
>> +odroid_reboot {
>> +compatible = "hardkernel,odroid-reboot";
>> +samsung,pmureg-phandle = <&pmu_system_controller>;
>> +reset-gpio = <&gpk1 2 0>;
>> +};
>> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
>> index f65ff49bb275..f02b13d5344f 100644
>> --- a/drivers/power/reset/Kconfig
>> +++ b/drivers/power/reset/Kconfig
>> @@ -84,6 +84,12 @@ config POWER_RESET_LTC2952
>>This driver supports an external powerdown trigger and board power
>>down via the LTC2952. Bindings are made in the device tree.
>>
>> +config POWER_RESET_ODROID
>> +bool "Hardkernel's Exynos4412 based Odroid reboot driver"
>> +depends on POWER_RESET && ARCH_EXYNOS
>
> once the arm specific restart handler is gone you can add ||
> COMPILE_TEST
>
>> +help
>> + Power off and restart support for Odroid boards.
>> +
>> config POWER_RESET_QNAP
>> bool "QNAP power-off driver"
>> depends on OF_GPIO && PLAT_ORION
>> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
>> index 76ce1c59469b..178ee86eb813 100644
>> --- a/drivers/power/reset/Makefile
>> +++ b/drivers/power/reset/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
>> obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
>> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
>> obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
>> +obj-$(CONFIG_POWER_RESET_ODROID) += odroid-reboot.o
>> obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
>> obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
>> obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
>> diff --git a/drivers/power/reset/odroid-reboot.c
>> b/drivers/power/reset/odroid-reboot.c
>> new file mode 100644
>> index ..823e93539220
>> --- /dev/null
>> +++ b/drivers/power/reset/odroid-reboot.c
>> @@ -0,0 +1,119 @@
>> +/*
>> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +#define PS_HOLD_CONTROL 0x330C
>> +
>> +struct odroid_reboot_data {
>> +struct device *dev;
>> +int power_gpio;
>> +struct regmap *reg_pmu;
>> +void (*reboot_func)(enum reboot_mode mode, const char *cmd);
>> +};
>> +
>> +static struct odroid_reboot_data *reboot_data;
>> +
>> +static void odroid_reboot(enum reboot_mode mode, const char *cmd)
>> +{
>> +local_irq_disable();
>> +
>> +gpio_set_value(reboot_data->power_gpio, 0);
>> +mdelay(150);
>> +gpio_set_value(reboot_data->power_gpio, 1);
>> +
>> +reboot_data->reboot_func(mode, cmd);
>> +
It is called do_kernel_restart() if arm_pm_restart is NULL from
machine_restart of arch/arm/kernel/process.c
How about this?
if (reboot_data->reboot_func)
reboot_data->reboot_func(mode,
Re: [alsa-devel] [PATCH v2 3/3] ARM: dts: Add sound nodes for exynos4412-trats2
Hi,
Thanks for your comments.
On Wed, 21 Jan 2015 17:23:21 +0100
Sylwester Nawrocki wrote:
> Hi,
>
> On 19/01/15 10:48, Inha Song wrote:
> > --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> > +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>
> > + sound {
> > + compatible = "samsung,trats2-audio";
>
> > + assigned-clocks = <&pmu_system_controller 0>;
> > + assigned-clock-parents = <&clock CLK_XUSBXTI>;
>
> How about putting these properties in the pmu_system_controller
> node? After all the mux clock being configured here belongs to
> the PMU subsystem. Wouldn't it work that way ?
OK, I will move assigned clock properties to pmu_system_controller DT node.
Best Regards,
Inha Song.
>
> > + samsung,i2s-controller = <&i2s0>;
> > + samsung,model = "Trats2";
> > + samsung,audio-codec = <&wm1811>;
> > + samsung,audio-routing =
> > + "SPK", "SPKOUTLN",
> > + "SPK", "SPKOUTLP",
> > + "SPK", "SPKOUTRN",
> > + "SPK", "SPKOUTRP";
> > + };
>
> --
> Regards,
> Sylwester
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] power: reset: add driver for Hardkernel's Odroid boards
Hi,
On Wed, Oct 29, 2014 at 02:13:28PM +0100, Marek Szyprowski wrote:
> This patch adds a driver implementing correct reboot and poweroff
> procedures for Exynos4412-based Hardkernel's Odroid X/X2/U2/U3/U3+
> boards.
Sorry it took so long. I have a couple of small requests before
applying this (comments inline).
> Signed-off-by: Marek Szyprowski
> ---
> .../bindings/power/reset/odroid-reset.txt | 18
> drivers/power/reset/Kconfig| 6 ++
> drivers/power/reset/Makefile | 1 +
> drivers/power/reset/odroid-reboot.c| 119
> +
> 4 files changed, 144 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/power/reset/odroid-reset.txt
> create mode 100644 drivers/power/reset/odroid-reboot.c
>
> diff --git a/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
> b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
> new file mode 100644
> index ..86471a463518
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
> @@ -0,0 +1,18 @@
> +* Device tree bindings for Hardkernel's Exynos4412 based Odroid boards
> +
> +This node is intended to allow proper system reboot and power off of
> +Odroid X/X2/U2/U3/U3+ boards with eMMC storage. Without this node, board
> +hangs during standard reset procedure.
> +
> +Required properties:
> +- compatible:hardkernel,odroid-reboot
> +- samsung,pmureg-phandle:phandle to Exynos PMU node
> +- reset-gpios: phandle and gpio-specifier to the GPIO
> pin
> + connected to the eMMC_nDET
> +
> +Example:
> +odroid_reboot {
> + compatible = "hardkernel,odroid-reboot";
> + samsung,pmureg-phandle = <&pmu_system_controller>;
> + reset-gpio = <&gpk1 2 0>;
> +};
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index f65ff49bb275..f02b13d5344f 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -84,6 +84,12 @@ config POWER_RESET_LTC2952
> This driver supports an external powerdown trigger and board power
> down via the LTC2952. Bindings are made in the device tree.
>
> +config POWER_RESET_ODROID
> + bool "Hardkernel's Exynos4412 based Odroid reboot driver"
> + depends on POWER_RESET && ARCH_EXYNOS
once the arm specific restart handler is gone you can add ||
COMPILE_TEST
> + help
> + Power off and restart support for Odroid boards.
> +
> config POWER_RESET_QNAP
> bool "QNAP power-off driver"
> depends on OF_GPIO && PLAT_ORION
> diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> index 76ce1c59469b..178ee86eb813 100644
> --- a/drivers/power/reset/Makefile
> +++ b/drivers/power/reset/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
> +obj-$(CONFIG_POWER_RESET_ODROID) += odroid-reboot.o
> obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
> diff --git a/drivers/power/reset/odroid-reboot.c
> b/drivers/power/reset/odroid-reboot.c
> new file mode 100644
> index ..823e93539220
> --- /dev/null
> +++ b/drivers/power/reset/odroid-reboot.c
> @@ -0,0 +1,119 @@
> +/*
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#define PS_HOLD_CONTROL 0x330C
> +
> +struct odroid_reboot_data {
> + struct device *dev;
> + int power_gpio;
> + struct regmap *reg_pmu;
> + void (*reboot_func)(enum reboot_mode mode, const char *cmd);
> +};
> +
> +static struct odroid_reboot_data *reboot_data;
> +
> +static void odroid_reboot(enum reboot_mode mode, const char *cmd)
> +{
> + local_irq_disable();
> +
> + gpio_set_value(reboot_data->power_gpio, 0);
> + mdelay(150);
> + gpio_set_value(reboot_data->power_gpio, 1);
> +
> + reboot_data->reboot_func(mode, cmd);
> +
> + pr_emerg("%s: waiting for reboot\n", __func__);
> + while (1)
> + ;
> +}
> +
> +static void odroid_power_off(void)
> +{
> + regmap_update_bits(reboot_data->reg_pmu, PS_HOLD_CONTROL, 0x,
> 0x5200);
> + while (1) {
> + pr_emerg("%s: should not reach here!\n", __func__);
> + msleep(1000);
> + }
> +
Re: [PATCH v3 00/16] thermal: exynos: Thermal code rework to use device tree
Hello!
Lukasz Majewski wrote:
>> The point is that I'm still working with a rather old version of the
>> cpufreq series, a version which still had the Exynos4x12 code in it
>> (this was removed later, if I remember correctly because of problems
>> with how to properly describe boost configuration in DT).
>
> Is your board Odroid-U3/Trats2 ?
It's an Odroid-X2, so pretty similar to the U3, except that it doesn't
have any active cooling device.
>> Anyway, to not get completly off-topic here, I noticed some small
>> issue with v3 of the thermal series. I've enabled
>> CONFIG_THERMAL_HWMON so that I can use lm_sensors to query
>> temperature of the board. However while the thermal_zone is created,
>> there is no hwmon node to be found.
>
> I'm not surprised, that some use cases (about which I wasn't even
> aware) show up.
> I've already fixed issues reported by Abhilash (with v5 and a following
> patch) and look closer into the THERMAL_HWMON.
The problem seems to be that of_parse_thermal_zones always sets
'no_hwmon' to true, so that thermal_zone_device_register never registers
a hwmon device when the underlaying thermal zone is setup through DT. I
don't understand the rationale behind this, even with the comment ('No
hwmon because there might be hwmon drivers registering').
> I've also done some work regarding FAN controlled by hwmon for Odroid
> U3.
> Could you look on following series:
> http://www.spinics.net/lists/linux-samsung-soc/msg40471.html
>
> I can only guess that your board might need similar entries for your
> DTS file(s).
Like I said, the X2 only has a passive heatsink, so no fan controlling here.
With best wishes,
Tobias
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos5422-odroidxu3: add sound nodes
Hi,
Thanks for your comment.
On Wed, 21 Jan 2015 12:41:55 +0100
Sylwester Nawrocki wrote:
> Hi,
>
> On 21/01/15 06:58, Inha Song wrote:
> > Add MAX98090 audio codec, I2S interface and the sound nodes to support
> > audio on Odroid-XU3 board.
> >
> > Signed-off-by: Inha Song
> > ---
> > arch/arm/boot/dts/exynos5422-odroidxu3.dts | 34
> > ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > index 7874da2..79493d1 100644
> > --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> > @@ -310,6 +310,40 @@
> > rtc@101E {
> > status = "okay";
> > };
> > +
> > + sound: sound {
> > + compatible = "samsung,odroidu3-audio";
>
> How about using simple-card instead ? I've been trying to switch
> Odroid X2/U3 to simple card. Here a corresponding dts patch:
> http://www.spinics.net/lists/linux-samsung-soc/msg41083.html
> For that recent patches for the I2S driver which area already in -next
> might be needed.
Oh, I missed your patchs.
I will rework this patch based on your patch.
Best Regards,
Inha Song.
>
> > + samsung,model = "Odroid-XU3";
> > + samsung,i2s-controller = <&i2s0>;
> > + samsung,audio-codec = <&max98090>;
> > + assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> > + <&clock_audss EXYNOS_MOUT_I2S>;
> > + assigned-clock-parents = <&clock CLK_FIN_PLL>,
> > + <&clock_audss EXYNOS_MOUT_AUDSS>;
> > + samsung,audio-routing =
> > + "Headphone Jack", "HPL",
> > + "Headphone Jack", "HPR",
> > + "Headphone Jack", "MICBIAS",
> > + "IN1", "Headphone Jack",
> > + "Speakers", "SPKL",
> > + "Speakers", "SPKR";
> > + };
> > +};
> > +
> > +&hsi2c_5 {
> > + status = "okay";
> > + max98090: max98090@10 {
> > + compatible = "maxim,max98090";
> > + reg = <0x10>;
> > + interrupt-parent = <&gpx3>;
> > + interrupts = <2 0>;
> > + clocks = <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> > + clock-names = "mclk";
> > + };
> > +};
>
> --
> Thanks,
> Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/9] clk: samsung: exynos5433: Add clocks for CMU_CAM1 domain
This patch adds the mux/divider/gate clocks for CMU_CAM1 domain which
generates the clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 +
drivers/clk/samsung/clk-exynos5433.c | 435 +
include/dt-bindings/clock/exynos5433.h | 147 ++-
3 files changed, 588 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index abef8f5..10e0ba6 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -48,6 +48,8 @@ Required Properties:
- "samsung,exynos5433-cmu-cam0" - clock controller compatible for CMU_CAM0
which generates clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1}
IPs.
+ - "samsung,exynos5433-cmu-cam1" - clock controller compatible for CMU_CAM1
+which generates clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -189,6 +191,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_cam1: clock-controller@145d {
+ compatible = "samsung,exynos5433-cmu-cam1";
+ reg = <0x145d 0x0b08>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index c765fe7..cb5fda1 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -405,6 +405,12 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
static struct samsung_div_clock top_div_clks[] __initdata = {
/* DIV_TOP0 */
+ DIV(CLK_DIV_ACLK_CAM1_333, "div_aclk_cam1_333", "mout_aclk_cam1_333",
+ DIV_TOP0, 28, 3),
+ DIV(CLK_DIV_ACLK_CAM1_400, "div_aclk_cam1_400", "mout_bus_pll_user",
+ DIV_TOP0, 24, 3),
+ DIV(CLK_DIV_ACLK_CAM1_552, "div_aclk_cam1_552", "mout_aclk_cam1_552_b",
+ DIV_TOP0, 20, 3),
DIV(CLK_DIV_ACLK_CAM0_333, "div_aclk_cam0_333", "mout_mfc_pll_user",
DIV_TOP0, 16, 3),
DIV(CLK_DIV_ACLK_CAM0_400, "div_aclk_cam0_400", "mout_bus_pll_user",
@@ -464,6 +470,32 @@ static struct samsung_div_clock top_div_clks[] __initdata
= {
DIV(CLK_DIV_SCLK_JPEG, "div_sclk_jpeg", "mout_sclk_jpeg_c",
DIV_TOP_MSCL, 0, 4),
+ /* DIV_TOP_CAM10 */
+ DIV(CLK_DIV_SCLK_ISP_UART, "div_sclk_isp_uart", "mout_sclk_isp_uart",
+ DIV_TOP_CAM10, 24, 5),
+ DIV(CLK_DIV_SCLK_ISP_SPI1_B, "div_sclk_isp_spi1_b",
+ "div_sclk_isp_spi1_a", DIV_TOP_CAM10, 16, 8),
+ DIV(CLK_DIV_SCLK_ISP_SPI1_A, "div_sclk_isp_spi1_a",
+ "mout_sclk_isp_spi1", DIV_TOP_CAM10, 12, 4),
+ DIV(CLK_DIV_SCLK_ISP_SPI0_B, "div_sclk_isp_spi0_b",
+ "div_sclk_isp_spi0_a", DIV_TOP_CAM10, 4, 8),
+ DIV(CLK_DIV_SCLK_ISP_SPI0_A, "div_sclk_isp_spi0_a",
+ "mout_sclk_isp_spi0", DIV_TOP_CAM10, 0, 4),
+
+ /* DIV_TOP_CAM11 */
+ DIV(CLK_DIV_SCLK_ISP_SENSOR2_B, "div_sclk_isp_sensor2_b",
+ "div_sclk_isp_sensor2_a", DIV_TOP_CAM11, 20, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR2_A, "div_sclk_isp_sensor2_a",
+ "mout_sclk_isp_sensor2", DIV_TOP_CAM11, 16, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR1_B, "div_sclk_isp_sensor1_b",
+ "div_sclk_isp_sensor1_a", DIV_TOP_CAM11, 12, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR1_A, "div_sclk_isp_sensor1_a",
+ "mout_sclk_isp_sensor1", DIV_TOP_CAM11, 8, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR0_B, "div_sclk_isp_sensor0_b",
+ "div_sclk_isp_sensor0_a", DIV_TOP_CAM11, 12, 4),
+ DIV(CLK_DIV_SCLK_ISP_SENSOR0_A, "div_sclk_isp_sensor0_a",
+ "mout_sclk_isp_sensor0", DIV_TOP_CAM11, 8, 4),
+
/* DIV_TOP_FSYS0 */
DIV(CLK_DIV_SCLK_MMC1_B, "div_sclk_mmc1_b", "div_sclk_mmc1_a",
DIV_TOP_FSYS0, 16, 8),
@@ -572,6 +604,15 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_ACLK_GSCL_333, "aclk_gscl_333", "div_aclk_gscl_333",
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_CAM1_333, "aclk_cam1_333", "div_aclk_cam1_333",
+ ENABLE_ACLK_TOP, 13,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_CAM1_400, "aclk_cam1_400",
[PATCH 4/9] clk: samsung: exynos5433: Add clocks for CMU_MFC domain
This patch adds the mux/divider/gate clocks for CMU_MFC domain which
generates the clocks for MFC(Multi-Format Codec) IP.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 7 ++
drivers/clk/samsung/clk-exynos5433.c | 113 +
include/dt-bindings/clock/exynos5433.h | 27 -
3 files changed, 146 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 790d93b..d3deaaf 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -39,6 +39,8 @@ Required Properties:
L2 cache controller.
- "samsung,exynos5433-cmu-mscl" - clock controller compatible for CMU_MSCL
which generates clocks for M2M (Memory to Memory) scaler and JPEG IPs.
+ - "samsung,exynos5433-cmu-mfc" - clock controller compatible for CMU_MFC
+which generates clocks for MFC(Multi-Format Codec) IP.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -156,6 +158,11 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_mfc: clock-controller@1528 {
+ compatible = "samsung,exynos5433-cmu-mfc";
+ reg = <0x1528 0x0b08>;
+ #clock-cells = <1>;
+ };
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 60ac4c7..b64f703 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -560,6 +560,9 @@ static struct samsung_gate_clock top_gate_clks[] __initdata
= {
GATE(CLK_ACLK_GSCL_333, "aclk_gscl_333", "div_aclk_gscl_333",
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_MFC_400, "aclk_mfc_400", "div_aclk_mfc_400",
+ ENABLE_ACLK_TOP, 3,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_G2D_266, "aclk_g2d_266", "div_aclk_g2d_266",
ENABLE_ACLK_TOP, 2,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -3990,3 +3993,113 @@ static void __init exynos5433_cmu_mscl_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_mscl, "samsung,exynos5433-cmu-mscl",
exynos5433_cmu_mscl_init);
+
+/*
+ * Register offset definitions for CMU_MFC
+ */
+#define MUX_SEL_MFC0x0200
+#define MUX_ENABLE_MFC 0x0300
+#define MUX_STAT_MFC 0x0400
+#define DIV_MFC0x0600
+#define DIV_STAT_MFC 0x0700
+#define ENABLE_ACLK_MFC0x0800
+#define ENABLE_ACLK_MFC_SECURE_SMMU_MFC0x0804
+#define ENABLE_PCLK_MFC0x0900
+#define ENABLE_PCLK_MFC_SECURE_SMMU_MFC0x0904
+#define ENABLE_IP_MFC0 0x0b00
+#define ENABLE_IP_MFC1 0x0b04
+#define ENABLE_IP_MFC_SECURE_SMMU_MFC 0x0b08
+
+static unsigned long mfc_clk_regs[] __initdata = {
+ MUX_SEL_MFC,
+ MUX_ENABLE_MFC,
+ MUX_STAT_MFC,
+ DIV_MFC,
+ DIV_STAT_MFC,
+ ENABLE_ACLK_MFC,
+ ENABLE_ACLK_MFC_SECURE_SMMU_MFC,
+ ENABLE_PCLK_MFC,
+ ENABLE_PCLK_MFC_SECURE_SMMU_MFC,
+ ENABLE_IP_MFC0,
+ ENABLE_IP_MFC1,
+ ENABLE_IP_MFC_SECURE_SMMU_MFC,
+};
+
+PNAME(mout_aclk_mfc_400_user_p)= { "fin_pll", "aclk_mfc_400",
};
+
+static struct samsung_mux_clock mfc_mux_clks[] __initdata = {
+ /* MUX_SEL_MFC */
+ MUX(CLK_MOUT_ACLK_MFC_400_USER, "mout_aclk_mfc_400_user",
+ mout_aclk_mfc_400_user_p, MUX_SEL_MFC, 0, 0),
+};
+
+static struct samsung_div_clock mfc_div_clks[] __initdata = {
+ /* DIV_MFC */
+ DIV(CLK_DIV_PCLK_MFC, "div_pclk_mfc", "mout_aclk_mfc_400_user",
+ DIV_MFC, 0, 2),
+};
+
+static struct samsung_gate_clock mfc_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_MFC */
+ GATE(CLK_ACLK_BTS_MFC_1, "aclk_bts_mfc_1", "mout_aclk_mfc_400_user",
+ ENABLE_ACLK_MFC, 6, 0, 0),
+ GATE(CLK_ACLK_BTS_MFC_0, "aclk_bts_mfc_0", "mout_aclk_mfc_400_user",
+ ENABLE_ACLK_MFC, 5, 0, 0),
+ GATE(CLK_ACLK_AHB2APB_MFCP, "aclk_ahb2apb_mfcp", "div_pclk_mfc",
+ ENABLE_ACLK_MFC, 4, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_XIU_MFCX, "aclk_xiu_mfcx", "mout_aclk_mfc_400_user",
+ ENABLE_ACLK_MFC, 3, CLK_IGNORE_UNUSED, 0),
+ GA
[PATCH 1/9] clk: samsung: exynos5433: Add clocks for CMU_APOLLO domain
This patch adds the mux/divider/gate clocks for CMU_APOLLO domain which
generates the clocks for Cortex-A53 Quad-core processsor.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 +
drivers/clk/samsung/clk-exynos5433.c | 193 +
include/dt-bindings/clock/exynos5433.h | 37
3 files changed, 238 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index bf72817..18c51c1 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -32,6 +32,8 @@ Required Properties:
which generates clocks for 3D Graphics Engine IP.
- "samsung,exynos5433-cmu-gscl" - clock controller compatible for CMU_GSCL
which generates clocks for GSCALER IPs.
+ - "samsung,exynos5433-cmu-apollo"- clock controller compatible for CMU_APOLLO
+which generates clocks for Cortex-A53 Quad-core processor.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -131,6 +133,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_apollo: clock-controller@1190 {
+ compatible = "samsung,exynos5433-cmu-apollo";
+ reg = <0x1190 0x1088>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 1d8d67a..37a5e78 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -3393,3 +3393,196 @@ static void __init exynos5433_cmu_gscl_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_gscl, "samsung,exynos5433-cmu-gscl",
exynos5433_cmu_gscl_init);
+
+/*
+ * Register offset definitions for CMU_APOLLO
+ */
+#define APOLLO_PLL_LOCK0x
+#define APOLLO_PLL_CON00x0100
+#define APOLLO_PLL_CON10x0104
+#define APOLLO_PLL_FREQ_DET0x010c
+#define MUX_SEL_APOLLO00x0200
+#define MUX_SEL_APOLLO10x0204
+#define MUX_SEL_APOLLO20x0208
+#define MUX_ENABLE_APOLLO0 0x0300
+#define MUX_ENABLE_APOLLO1 0x0304
+#define MUX_ENABLE_APOLLO2 0x0308
+#define MUX_STAT_APOLLO0 0x0400
+#define MUX_STAT_APOLLO1 0x0404
+#define MUX_STAT_APOLLO2 0x0408
+#define DIV_APOLLO00x0600
+#define DIV_APOLLO10x0604
+#define DIV_APOLLO_PLL_FREQ_DET0x0608
+#define DIV_STAT_APOLLO0 0x0700
+#define DIV_STAT_APOLLO1 0x0704
+#define DIV_STAT_APOLLO_PLL_FREQ_DET 0x0708
+#define ENABLE_ACLK_APOLLO 0x0800
+#define ENABLE_PCLK_APOLLO 0x0900
+#define ENABLE_SCLK_APOLLO 0x0a00
+#define ENABLE_IP_APOLLO0 0x0b00
+#define ENABLE_IP_APOLLO1 0x0b04
+#define CLKOUT_CMU_APOLLO 0x0c00
+#define CLKOUT_CMU_APOLLO_DIV_STAT 0x0c04
+#define ARMCLK_STOPCTRL0x1000
+#define APOLLO_PWR_CTRL0x1020
+#define APOLLO_PWR_CTRL2 0x1024
+#define APOLLO_INTR_SPREAD_ENABLE 0x1080
+#define APOLLO_INTR_SPREAD_USE_STANDBYWFI 0x1084
+#define APOLLO_INTR_SPREAD_BLOCKING_DURATION 0x1088
+
+static unsigned long apollo_clk_regs[] __initdata = {
+ APOLLO_PLL_LOCK,
+ APOLLO_PLL_CON0,
+ APOLLO_PLL_CON1,
+ APOLLO_PLL_FREQ_DET,
+ MUX_SEL_APOLLO0,
+ MUX_SEL_APOLLO1,
+ MUX_SEL_APOLLO2,
+ MUX_ENABLE_APOLLO0,
+ MUX_ENABLE_APOLLO1,
+ MUX_ENABLE_APOLLO2,
+ MUX_STAT_APOLLO0,
+ MUX_STAT_APOLLO1,
+ MUX_STAT_APOLLO2,
+ DIV_APOLLO0,
+ DIV_APOLLO1,
+ DIV_APOLLO_PLL_FREQ_DET,
+ DIV_STAT_APOLLO0,
+ DIV_STAT_APOLLO1,
+ DIV_STAT_APOLLO_PLL_FREQ_DET,
+ ENABLE_ACLK_APOLLO,
+ ENABLE_PCLK_APOLLO,
+ ENABLE_SCLK_APOLLO,
+ ENABLE_IP_APOLLO0,
+ ENABLE_IP_APOLLO1,
+ CLKOUT_CMU_APOLLO,
+ CLKOUT_CMU_APOLLO_DIV_STAT,
+ ARMCLK_STOPCTRL,
+ APOLLO_PWR_CTRL,
+ APOLLO_PWR_CTRL2,
+ APOLLO_INTR_SPREAD_ENABLE,
+ APOLLO_INTR_SPREAD_USE_STANDBYWFI,
+ APOLLO_INTR_SPREAD_BLOCKING_DURATION,
+};
+
+/* list of all parent clock list */
+PNAME(mout_apollo_pll_p)
[PATCH 5/9] clk: samsung: exynos5433: Add clocks for CMU_HEVC domain
This patch adds the mux/divider/gate clocks for CMU_HEVC domain which
generates the clocks for HEVC(High Efficiency Video Codec) decoder IP.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 ++
drivers/clk/samsung/clk-exynos5433.c | 115 +
include/dt-bindings/clock/exynos5433.h | 27 -
3 files changed, 149 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index d3deaaf..10908d2 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -41,6 +41,8 @@ Required Properties:
which generates clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- "samsung,exynos5433-cmu-mfc" - clock controller compatible for CMU_MFC
which generates clocks for MFC(Multi-Format Codec) IP.
+ - "samsung,exynos5433-cmu-hevc" - clock controller compatible for CMU_HEVC
+which generates clocks for HEVC(High Efficiency Video Codec) decoder IP.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -164,6 +166,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_hevc: clock-controller@14f8 {
+ compatible = "samsung,exynos5433-cmu-hevc";
+ reg = <0x14f8 0x0b08>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index b64f703..1c2e5c8 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -560,6 +560,9 @@ static struct samsung_gate_clock top_gate_clks[] __initdata
= {
GATE(CLK_ACLK_GSCL_333, "aclk_gscl_333", "div_aclk_gscl_333",
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_HEVC_400, "aclk_hevc_400", "div_aclk_hevc_400",
+ ENABLE_ACLK_TOP, 5,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_MFC_400, "aclk_mfc_400", "div_aclk_mfc_400",
ENABLE_ACLK_TOP, 3,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -4103,3 +4106,115 @@ static void __init exynos5433_cmu_mfc_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_mfc, "samsung,exynos5433-cmu-mfc",
exynos5433_cmu_mfc_init);
+
+/*
+ * Register offset definitions for CMU_HEVC
+ */
+#define MUX_SEL_HEVC 0x0200
+#define MUX_ENABLE_HEVC0x0300
+#define MUX_STAT_HEVC 0x0400
+#define DIV_HEVC 0x0600
+#define DIV_STAT_HEVC 0x0700
+#define ENABLE_ACLK_HEVC 0x0800
+#define ENABLE_ACLK_HEVC_SECURE_SMMU_HEVC 0x0804
+#define ENABLE_PCLK_HEVC 0x0900
+#define ENABLE_PCLK_HEVC_SECURE_SMMU_HEVC 0x0904
+#define ENABLE_IP_HEVC00x0b00
+#define ENABLE_IP_HEVC10x0b04
+#define ENABLE_IP_HEVC_SECURE_SMMU_HEVC0x0b08
+
+static unsigned long hevc_clk_regs[] __initdata = {
+ MUX_SEL_HEVC,
+ MUX_ENABLE_HEVC,
+ MUX_STAT_HEVC,
+ DIV_HEVC,
+ DIV_STAT_HEVC,
+ ENABLE_ACLK_HEVC,
+ ENABLE_ACLK_HEVC_SECURE_SMMU_HEVC,
+ ENABLE_PCLK_HEVC,
+ ENABLE_PCLK_HEVC_SECURE_SMMU_HEVC,
+ ENABLE_IP_HEVC0,
+ ENABLE_IP_HEVC1,
+ ENABLE_IP_HEVC_SECURE_SMMU_HEVC,
+};
+
+PNAME(mout_aclk_hevc_400_user_p) = { "fin_pll", "aclk_hevc_400", };
+
+static struct samsung_mux_clock hevc_mux_clks[] __initdata = {
+ /* MUX_SEL_HEVC */
+ MUX(CLK_MOUT_ACLK_HEVC_400_USER, "mout_aclk_hevc_400_user",
+ mout_aclk_hevc_400_user_p, MUX_SEL_HEVC, 0, 0),
+};
+
+static struct samsung_div_clock hevc_div_clks[] __initdata = {
+ /* DIV_HEVC */
+ DIV(CLK_DIV_PCLK_HEVC, "div_pclk_hevc", "mout_aclk_hevc_400_user",
+ DIV_HEVC, 0, 2),
+};
+
+static struct samsung_gate_clock hevc_gate_clks[] __initdata = {
+ /* ENABLE_ACLK_HEVC */
+ GATE(CLK_ACLK_BTS_HEVC_1, "aclk_bts_hevc_1", "mout_aclk_hevc_400_user",
+ ENABLE_ACLK_HEVC, 6, 0, 0),
+ GATE(CLK_ACLK_BTS_HEVC_0, "aclk_bts_hevc_0", "mout_aclk_hevc_400_user",
+ ENABLE_ACLK_HEVC, 5, 0, 0),
+ GATE(CLK_ACLK_AHB2APB_HEVCP, "aclk_ahb2apb_hevcp", "div_pclk_hevc",
+ ENABLE_ACLK_HEVC, 4, CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_XIU_HEVCX, "aclk_xiu_hevcx",
[PATCH 2/9] clk: samsung: exynos5433: Add clocks for CMU_ATLAS domain
This patch adds the mux/divider/gate clocks for CMU_ATLAS domain which
generates the clocks for Cortex-A57 Quad-core processsor, L2 cache controller
and CoreSight.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 9 +
drivers/clk/samsung/clk-exynos5433.c | 219 +
include/dt-bindings/clock/exynos5433.h | 46 +
3 files changed, 274 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 18c51c1..414e32c 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -34,6 +34,9 @@ Required Properties:
which generates clocks for GSCALER IPs.
- "samsung,exynos5433-cmu-apollo"- clock controller compatible for CMU_APOLLO
which generates clocks for Cortex-A53 Quad-core processor.
+ - "samsung,exynos5433-cmu-atlas" - clock controller compatible for CMU_ATLAS
+which generates clocks for Cortex-A57 Quad-core processor, CoreSight and
+L2 cache controller.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -139,6 +142,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_atlas: clock-controller@1180 {
+ compatible = "samsung,exynos5433-cmu-atlas";
+ reg = <0x1180 0x1088>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 37a5e78..089c98f 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -3586,3 +3586,222 @@ static void __init exynos5433_cmu_apollo_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_apollo, "samsung,exynos5433-cmu-apollo",
exynos5433_cmu_apollo_init);
+
+/*
+ * Register offset definitions for CMU_ATLAS
+ */
+#define ATLAS_PLL_LOCK 0x
+#define ATLAS_PLL_CON0 0x0100
+#define ATLAS_PLL_CON1 0x0104
+#define ATLAS_PLL_FREQ_DET 0x010c
+#define MUX_SEL_ATLAS0 0x0200
+#define MUX_SEL_ATLAS1 0x0204
+#define MUX_SEL_ATLAS2 0x0208
+#define MUX_ENABLE_ATLAS0 0x0300
+#define MUX_ENABLE_ATLAS1 0x0304
+#define MUX_ENABLE_ATLAS2 0x0308
+#define MUX_STAT_ATLAS00x0400
+#define MUX_STAT_ATLAS10x0404
+#define MUX_STAT_ATLAS20x0408
+#define DIV_ATLAS0 0x0600
+#define DIV_ATLAS1 0x0604
+#define DIV_ATLAS_PLL_FREQ_DET 0x0608
+#define DIV_STAT_ATLAS00x0700
+#define DIV_STAT_ATLAS10x0704
+#define DIV_STAT_ATLAS_PLL_FREQ_DET0x0708
+#define ENABLE_ACLK_ATLAS 0x0800
+#define ENABLE_PCLK_ATLAS 0x0900
+#define ENABLE_SCLK_ATLAS 0x0a00
+#define ENABLE_IP_ATLAS0 0x0b00
+#define ENABLE_IP_ATLAS1 0x0b04
+#define CLKOUT_CMU_ATLAS 0x0c00
+#define CLKOUT_CMU_ATLAS_DIV_STAT 0x0c04
+#define ARMCLK_STOPCTRL0x1000
+#define ATLAS_PWR_CTRL 0x1020
+#define ATLAS_PWR_CTRL20x1024
+#define ATLAS_INTR_SPREAD_ENABLE 0x1080
+#define ATLAS_INTR_SPREAD_USE_STANDBYWFI 0x1084
+#define ATLAS_INTR_SPREAD_BLOCKING_DURATION0x1088
+
+static unsigned long atlas_clk_regs[] __initdata = {
+ ATLAS_PLL_LOCK,
+ ATLAS_PLL_CON0,
+ ATLAS_PLL_CON1,
+ ATLAS_PLL_FREQ_DET,
+ MUX_SEL_ATLAS0,
+ MUX_SEL_ATLAS1,
+ MUX_SEL_ATLAS2,
+ MUX_ENABLE_ATLAS0,
+ MUX_ENABLE_ATLAS1,
+ MUX_ENABLE_ATLAS2,
+ MUX_STAT_ATLAS0,
+ MUX_STAT_ATLAS1,
+ MUX_STAT_ATLAS2,
+ DIV_ATLAS0,
+ DIV_ATLAS1,
+ DIV_ATLAS_PLL_FREQ_DET,
+ DIV_STAT_ATLAS0,
+ DIV_STAT_ATLAS1,
+ DIV_STAT_ATLAS_PLL_FREQ_DET,
+ ENABLE_ACLK_ATLAS,
+ ENABLE_PCLK_ATLAS,
+ ENABLE_SCLK_ATLAS,
+ ENABLE_IP_ATLAS0,
+ ENABLE_IP_ATLAS1,
+ CLKOUT_CMU_ATLAS,
+ CLKOUT_CMU_ATLAS_DIV_STAT,
+ ARMCLK_STOPCTRL,
+ ATLAS_PWR_CTRL,
+ ATLAS_PWR_CTRL2,
+ ATLAS_INTR_SPREAD_ENABLE,
+ ATLAS_INTR_SPREAD_USE_STANDBYWFI,
+ ATLAS_INTR_SPREAD_BLOCKING_DURATION,
+};
+
+/* list of all parent
[PATCH 7/9] clk: samsung: exynos5433: Add clocks for CMU_CAM0 domain
This patch adds the mux/divider/gate clocks for CMU_HEVC domain which
generates the clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 9 +
drivers/clk/samsung/clk-exynos5433.c | 501 +
include/dt-bindings/clock/exynos5433.h | 146 +-
3 files changed, 655 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index ae97a77..abef8f5 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -45,6 +45,9 @@ Required Properties:
which generates clocks for HEVC(High Efficiency Video Codec) decoder IP.
- "samsung,exynos5433-cmu-isp" - clock controller compatible for CMU_ISP
which generates clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
+ - "samsung,exynos5433-cmu-cam0" - clock controller compatible for CMU_CAM0
+which generates clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1}
+IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -180,6 +183,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_cam0: clock-controller@120d {
+ compatible = "samsung,exynos5433-cmu-cam0";
+ reg = <0x120d 0x0b0c>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 04a6089..c765fe7 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -405,6 +405,12 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
static struct samsung_div_clock top_div_clks[] __initdata = {
/* DIV_TOP0 */
+ DIV(CLK_DIV_ACLK_CAM0_333, "div_aclk_cam0_333", "mout_mfc_pll_user",
+ DIV_TOP0, 16, 3),
+ DIV(CLK_DIV_ACLK_CAM0_400, "div_aclk_cam0_400", "mout_bus_pll_user",
+ DIV_TOP0, 12, 3),
+ DIV(CLK_DIV_ACLK_CAM0_552, "div_aclk_cam0_552", "mout_isp_pll",
+ DIV_TOP0, 8, 3),
DIV(CLK_DIV_ACLK_ISP_DIS_400, "div_aclk_isp_dis_400",
"mout_aclk_isp_dis_400", DIV_TOP0, 4, 4),
DIV(CLK_DIV_ACLK_ISP_400, "div_aclk_isp_400",
@@ -566,6 +572,15 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_ACLK_GSCL_333, "aclk_gscl_333", "div_aclk_gscl_333",
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_CAM0_333, "aclk_cam0_333", "div_aclk_cam0_333",
+ ENABLE_ACLK_TOP, 10,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_CAM0_400, "aclk_cam0_400", "div_aclk_cam0_400",
+ ENABLE_ACLK_TOP, 9,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_CAM0_552, "aclk_cam0_552", "div_aclk_cam0_552",
+ ENABLE_ACLK_TOP, 8,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_ISP_DIS_400, "aclk_isp_dis_400", "div_aclk_isp_dis_400",
ENABLE_ACLK_TOP, 7,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -4485,3 +4500,489 @@ static void __init exynos5433_cmu_isp_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_isp, "samsung,exynos5433-cmu-isp",
exynos5433_cmu_isp_init);
+
+/*
+ * Register offset definitions for CMU_CAM0
+ */
+#define MUX_SEL_CAM00 0x0200
+#define MUX_SEL_CAM01 0x0204
+#define MUX_SEL_CAM02 0x0208
+#define MUX_SEL_CAM03 0x020c
+#define MUX_SEL_CAM04 0x0210
+#define MUX_ENABLE_CAM00 0x0300
+#define MUX_ENABLE_CAM01 0x0304
+#define MUX_ENABLE_CAM02 0x0308
+#define MUX_ENABLE_CAM03 0x030c
+#define MUX_ENABLE_CAM04 0x0310
+#define MUX_STAT_CAM00 0x0400
+#define MUX_STAT_CAM01 0x0404
+#define MUX_STAT_CAM02 0x0408
+#define MUX_STAT_CAM03 0x040c
+#define MUX_STAT_CAM04 0x0410
+#define MUX_IGNORE_CAM01 0x0504
+#define DIV_CAM00 0x0600
+#define DIV_CAM01 0x0604
+#define DIV_CAM02 0x0608
+#define DIV_CAM03 0x060c
+#define DIV_STAT_CAM00 0x0700
+#define DIV_STAT_CAM01 0x0704
+#define DIV_STAT_CAM02
[PATCH 6/9] clk: samsung: exynos5433: Add clocks for CMU_ISP domain
This patch adds the mux/divider/gate clocks for CMU_ISP domain which
generates the clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 8 +
drivers/clk/samsung/clk-exynos5433.c | 267 +
include/dt-bindings/clock/exynos5433.h | 89 ++-
3 files changed, 363 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 10908d2..ae97a77 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -43,6 +43,8 @@ Required Properties:
which generates clocks for MFC(Multi-Format Codec) IP.
- "samsung,exynos5433-cmu-hevc" - clock controller compatible for CMU_HEVC
which generates clocks for HEVC(High Efficiency Video Codec) decoder IP.
+ - "samsung,exynos5433-cmu-isp" - clock controller compatible for CMU_ISP
+which generates clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -172,6 +174,12 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_isp: clock-controller@146d {
+ compatible = "samsung,exynos5433-cmu-isp";
+ reg = <0x146d 0x0b0c>;
+ #clock-cells = <1>;
+ };
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 1c2e5c8..04a6089 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -404,6 +404,12 @@ static struct samsung_mux_clock top_mux_clks[] __initdata
= {
};
static struct samsung_div_clock top_div_clks[] __initdata = {
+ /* DIV_TOP0 */
+ DIV(CLK_DIV_ACLK_ISP_DIS_400, "div_aclk_isp_dis_400",
+ "mout_aclk_isp_dis_400", DIV_TOP0, 4, 4),
+ DIV(CLK_DIV_ACLK_ISP_400, "div_aclk_isp_400",
+ "mout_aclk_isp_400", DIV_TOP0, 0, 4),
+
/* DIV_TOP1 */
DIV(CLK_DIV_ACLK_GSCL_111, "div_aclk_gscl_111", "mout_aclk_gscl_333",
DIV_TOP1, 28, 3),
@@ -560,6 +566,12 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
GATE(CLK_ACLK_GSCL_333, "aclk_gscl_333", "div_aclk_gscl_333",
ENABLE_ACLK_TOP, 14,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_ISP_DIS_400, "aclk_isp_dis_400", "div_aclk_isp_dis_400",
+ ENABLE_ACLK_TOP, 7,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_ISP_400, "aclk_isp_400", "div_aclk_isp_400",
+ ENABLE_ACLK_TOP, 6,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_HEVC_400, "aclk_hevc_400", "div_aclk_hevc_400",
ENABLE_ACLK_TOP, 5,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -4218,3 +4230,258 @@ static void __init exynos5433_cmu_hevc_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_hevc, "samsung,exynos5433-cmu-hevc",
exynos5433_cmu_hevc_init);
+
+/*
+ * Register offset definitions for CMU_ISP
+ */
+#define MUX_SEL_ISP0x0200
+#define MUX_ENABLE_ISP 0x0300
+#define MUX_STAT_ISP 0x0400
+#define DIV_ISP0x0600
+#define DIV_STAT_ISP 0x0700
+#define ENABLE_ACLK_ISP0 0x0800
+#define ENABLE_ACLK_ISP1 0x0804
+#define ENABLE_ACLK_ISP2 0x0808
+#define ENABLE_PCLK_ISP0x0900
+#define ENABLE_SCLK_ISP0x0a00
+#define ENABLE_IP_ISP0 0x0b00
+#define ENABLE_IP_ISP1 0x0b04
+#define ENABLE_IP_ISP2 0x0b08
+#define ENABLE_IP_ISP3 0x0b0c
+
+static unsigned long isp_clk_regs[] __initdata = {
+ MUX_SEL_ISP,
+ MUX_ENABLE_ISP,
+ MUX_STAT_ISP,
+ DIV_ISP,
+ DIV_STAT_ISP,
+ ENABLE_ACLK_ISP0,
+ ENABLE_ACLK_ISP1,
+ ENABLE_ACLK_ISP2,
+ ENABLE_PCLK_ISP,
+ ENABLE_SCLK_ISP,
+ ENABLE_IP_ISP0,
+ ENABLE_IP_ISP1,
+ ENABLE_IP_ISP2,
+ ENABLE_IP_ISP3,
+};
+
+PNAME(mout_aclk_isp_dis_400_user_p)= { "fin_pll", "aclk_isp_dis_400", };
+PNAME(mout_aclk_isp_400_user_p)= { "fin_pll", "aclk_isp_400",
};
+
+static struct samsung_mux_clock isp_mux_clks[] __initdata = {
+ /* MUX_SEL_ISP */
+ MUX(CLK_MOUT_ACLK_ISP_DIS_400_USER, "mout_aclk_isp_dis_400_user",
+ mout_aclk_isp_dis_
[PATCH 3/9] clk: samsung: exynos5433: Add clocks for CMU_MSCL domain
This patch adds the mux/divider/gate clocks for CMU_MSCL domain which
generates the clocks for M2M (Memory to Memory) scaler, JPEG IPs.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
.../devicetree/bindings/clock/exynos5433-clock.txt | 9 +
drivers/clk/samsung/clk-exynos5433.c | 185 +
include/dt-bindings/clock/exynos5433.h | 41 -
3 files changed, 234 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
index 414e32c..790d93b 100644
--- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt
@@ -37,6 +37,8 @@ Required Properties:
- "samsung,exynos5433-cmu-atlas" - clock controller compatible for CMU_ATLAS
which generates clocks for Cortex-A57 Quad-core processor, CoreSight and
L2 cache controller.
+ - "samsung,exynos5433-cmu-mscl" - clock controller compatible for CMU_MSCL
+which generates clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- reg: physical base address of the controller and length of memory mapped
region.
@@ -148,6 +150,13 @@ Example 1: Examples of clock controller nodes are listed
below.
#clock-cells = <1>;
};
+ cmu_mscl: clock-controller@105d {
+ compatible = "samsung,exynos5433-cmu-mscl";
+ reg = <0x105d 0x0b10>;
+ #clock-cells = <1>;
+ };
+
+
Example 2: UART controller node that consumes the clock generated by the clock
controller.
diff --git a/drivers/clk/samsung/clk-exynos5433.c
b/drivers/clk/samsung/clk-exynos5433.c
index 089c98f..60ac4c7 100644
--- a/drivers/clk/samsung/clk-exynos5433.c
+++ b/drivers/clk/samsung/clk-exynos5433.c
@@ -419,6 +419,8 @@ static struct samsung_div_clock top_div_clks[] __initdata =
{
DIV_TOP1, 0, 3),
/* DIV_TOP2 */
+ DIV(CLK_DIV_ACLK_MSCL_400, "div_aclk_mscl_400", "mout_aclk_mscl_400_b",
+ DIV_TOP2, 4, 3),
DIV(CLK_DIV_ACLK_FSYS_200, "div_aclk_fsys_200", "mout_bus_pll_user",
DIV_TOP2, 0, 3),
@@ -446,6 +448,10 @@ static struct samsung_div_clock top_div_clks[] __initdata
= {
DIV(CLK_DIV_ACLK_BUS1_400, "div_aclk_bus1_400", "mout_bus_pll_user",
DIV_TOP4, 0, 3),
+ /* DIV_TOP_MSCL */
+ DIV(CLK_DIV_SCLK_JPEG, "div_sclk_jpeg", "mout_sclk_jpeg_c",
+ DIV_TOP_MSCL, 0, 4),
+
/* DIV_TOP_FSYS0 */
DIV(CLK_DIV_SCLK_MMC1_B, "div_sclk_mmc1_b", "div_sclk_mmc1_a",
DIV_TOP_FSYS0, 16, 8),
@@ -542,6 +548,9 @@ static struct samsung_gate_clock top_gate_clks[] __initdata
= {
GATE(CLK_ACLK_PERIS_66, "aclk_peris_66", "div_aclk_peris_66_b",
ENABLE_ACLK_TOP, 21,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ GATE(CLK_ACLK_MSCL_400, "aclk_mscl_400", "div_aclk_mscl_400",
+ ENABLE_ACLK_TOP, 19,
+ CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
GATE(CLK_ACLK_FSYS_200, "aclk_fsys_200", "div_aclk_fsys_200",
ENABLE_ACLK_TOP, 18,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
@@ -558,6 +567,10 @@ static struct samsung_gate_clock top_gate_clks[]
__initdata = {
ENABLE_ACLK_TOP, 0,
CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED, 0),
+ /* ENABLE_SCLK_TOP_MSCL */
+ GATE(CLK_SCLK_JPEG_MSCL, "sclk_jpeg_mscl", "div_sclk_jpeg",
+ ENABLE_SCLK_TOP_MSCL, 0, 0, 0),
+
/* ENABLE_SCLK_TOP_FSYS */
GATE(CLK_SCLK_PCIE_100_FSYS, "sclk_pcie_100_fsys", "div_sclk_pcie_100",
ENABLE_SCLK_TOP_FSYS, 7, 0, 0),
@@ -3805,3 +3818,175 @@ static void __init exynos5433_cmu_atlas_init(struct
device_node *np)
}
CLK_OF_DECLARE(exynos5433_cmu_atlas, "samsung,exynos5433-cmu-atlas",
exynos5433_cmu_atlas_init);
+
+/*
+ * Register offset definitions for CMU_MSCL
+ */
+#define MUX_SEL_MSCL0 0x0200
+#define MUX_SEL_MSCL1 0x0204
+#define MUX_ENABLE_MSCL0 0x0300
+#define MUX_ENABLE_MSCL1 0x0304
+#define MUX_STAT_MSCL0 0x0400
+#define MUX_STAT_MSCL1 0x0404
+#define DIV_MSCL 0x0600
+#define DIV_STAT_MSCL 0x0700
+#define ENABLE_ACLK_MSCL 0x0800
+#define ENABLE_ACLK_MSCL_SECURE_SMMU_M2MSCALER00x0804
+#define ENABLE_ACLK_MSCL_SECURE_SMMU_M2MSCALER10x0808
+#define ENABLE_ACLK_MSCL_SECURE_SMMU_JPEG 0x080c
+#def
[PATCH 9/9] clk: samsung: Add CLKOUT driver support for Exynos5433 SoC.
From: Inha Song This patch add CLKOUT driver support for Exynos5433 SoC. Cc: Sylwester Nawrocki Cc: Tomasz Figa Signed-off-by: Inha Song Acked-by: Inki Dae --- drivers/clk/samsung/clk-exynos-clkout.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/samsung/clk-exynos-clkout.c b/drivers/clk/samsung/clk-exynos-clkout.c index 3a7cb25..1eb16b8 100644 --- a/drivers/clk/samsung/clk-exynos-clkout.c +++ b/drivers/clk/samsung/clk-exynos-clkout.c @@ -151,3 +151,5 @@ CLK_OF_DECLARE(exynos5250_clkout, "samsung,exynos5250-pmu", exynos5_clkout_init); CLK_OF_DECLARE(exynos5420_clkout, "samsung,exynos5420-pmu", exynos5_clkout_init); +CLK_OF_DECLARE(exynos5433_clkout, "samsung,exynos5433-pmu", + exynos5_clkout_init); -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/9] clk: samsung: Add clocks for remaining domains of Exynos5433
This patchset adds the support for following clock domains of Exynos5433
and clkout drvier.
Following clock domains has clocks for each IP.
- CMU_APOLLO : clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor, CoreSight and
L2 cache controller.
- CMU_MSCL : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC: clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP: clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0 : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1 : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.
Depend on:
[PATCH v3 00/12] clk: samsung: Add the support for exynos5433 clocks
- https://lkml.org/lkml/2015/1/21/44
Chanwoo Choi (8):
clk: samsung: exynos5433: Add clocks for CMU_APOLLO domain
clk: samsung: exynos5433: Add clocks for CMU_ATLAS domain
clk: samsung: exynos5433: Add clocks for CMU_MSCL domain
clk: samsung: exynos5433: Add clocks for CMU_MFC domain
clk: samsung: exynos5433: Add clocks for CMU_HEVC domain
clk: samsung: exynos5433: Add clocks for CMU_ISP domain
clk: samsung: exynos5433: Add clocks for CMU_CAM0 domain
clk: samsung: exynos5433: Add clocks for CMU_CAM1 domain
Inha Song (1):
clk: samsung: Add CLKOUT driver support for Exynos5433 SoC.
.../devicetree/bindings/clock/exynos5433-clock.txt | 66 +
drivers/clk/samsung/clk-exynos-clkout.c|2 +
drivers/clk/samsung/clk-exynos5433.c | 2028
include/dt-bindings/clock/exynos5433.h | 548 +-
4 files changed, 2643 insertions(+), 1 deletion(-)
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] mmc: dw_mmc: exynos: Support eMMC's HS400 mode
Hi Jaehoon
On Wed, Jan 21, 2015 at 4:32 AM, Jaehoon Chung wrote:
> Hi,
>
> This patch can be separated.
> When i tested on my board, it's not working fine.
> I think it depends on my timing, so i will check after change the timing.
>
> On 01/14/2015 07:30 PM, Alim Akhtar wrote:
>> From: Seungwon Jeon
>>
>> Implements HS400 mode support for exynos host driver.
>> This also include some updates as new mode is added.
>>
>> Signed-off-by: Seungwon Jeon
>> Signed-off-by: Alim Akhtar
>> [Alim: addressed review comments]
>> ---
>> .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 +
>> drivers/mmc/host/dw_mmc-exynos.c | 187
>>
>> drivers/mmc/host/dw_mmc-exynos.h | 19 +-
>> drivers/mmc/host/dw_mmc.c | 16 +-
>> drivers/mmc/host/dw_mmc.h |2 +
>> 5 files changed, 196 insertions(+), 35 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> index ee4fc05..dcab52c 100644
>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> @@ -36,6 +36,8 @@ Required Properties:
>>in transmit mode and CIU clock phase shift value in receive mode for
>> double
>>data rate mode operation. Refer notes below for the order of the cells
>> and the
>>valid values.
>> +* samsung,dw-mshc-hs400-timing: Specifies the value of CIU TX and RX clock
>> phase
>> + shift value for hs400 mode operation.
>>
>>Notes for the sdr-timing and ddr-timing values:
>>
>> @@ -50,6 +52,9 @@ Required Properties:
>>- if CIU clock divider value is 0 (that is divide by 1), both tx and
>> rx
>> phase shift clocks should be 0.
>>
>> +* read-strobe-delay: RCLK (Data strobe) delay to control HS400 mode
>> + (Latency value for delay line in Read path)
>> +
>> Required properties for a slot (Deprecated - Recommend to use one slot per
>> host):
>>
>> * gpios: specifies a list of gpios used for command, clock and data bus. The
>> @@ -82,5 +87,7 @@ Example:
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <2 3>;
>> samsung,dw-mshc-ddr-timing = <1 2>;
>> + samsung,dw-mshc-hs400-timing = <0 2>;
>> + read-strobe-delay = <90>;
>
> read-strobe-delay is exynos specific, isn't?
> read-strobe-delay -> samsung.read-strobe-delay.
>
read-strobe are as per hs400 spec, ok I will change this to match the
naming with other properties.
>> bus-width = <8>;
>> };
>> diff --git a/drivers/mmc/host/dw_mmc-exynos.c
>> b/drivers/mmc/host/dw_mmc-exynos.c
>> index 12a5eaa..172a2a8 100644
>> --- a/drivers/mmc/host/dw_mmc-exynos.c
>> +++ b/drivers/mmc/host/dw_mmc-exynos.c
>> @@ -40,7 +40,12 @@ struct dw_mci_exynos_priv_data {
>> u8 ciu_div;
>> u32 sdr_timing;
>> u32 ddr_timing;
>> + u32 hs400_timing;
>> + u32 tuned_sample;
>> u32 cur_speed;
>> + u32 dqs_delay;
>> + u32 saved_dqs_en;
>> + u32 saved_strobe_ctrl;
>> };
>>
>> static struct dw_mci_exynos_compatible {
>> @@ -71,6 +76,21 @@ static struct dw_mci_exynos_compatible {
>> },
>> };
>>
>> +static inline u8 dw_mci_exynos_get_ciu_div(struct dw_mci *host)
>> +{
>> + struct dw_mci_exynos_priv_data *priv = host->priv;
>> +
>> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS4412)
>> + return EXYNOS4412_FIXED_CIU_CLK_DIV;
>> + else if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS4210)
>> + return EXYNOS4210_FIXED_CIU_CLK_DIV;
>> + else if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
>> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
>> + return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL64)) + 1;
>> + else
>> + return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL)) + 1;
>> +}
>> +
>> static int dw_mci_exynos_priv_init(struct dw_mci *host)
>> {
>> struct dw_mci_exynos_priv_data *priv = host->priv;
>> @@ -85,6 +105,16 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
>> SDMMC_MPSCTRL_NON_SECURE_WRITE_BIT);
>> }
>>
>> + if (priv->ctrl_type >= DW_MCI_TYPE_EXYNOS5420) {
>> + priv->saved_strobe_ctrl = mci_readl(host, HS400_DLINE_CTRL);
>> + priv->saved_dqs_en = mci_readl(host, HS400_DQS_EN);
>> + priv->saved_dqs_en |= AXI_NON_BLOCKING_WR;
>> + mci_writel(host, HS400_DQS_EN, priv->saved_dqs_en);
>> + if (!priv->dqs_delay)
>> + priv->dqs_delay =
>> + DQS_CTRL_GET_RD_DELAY(priv->saved_strob
Re: [PATCH v4 00/18] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem
Hello, just some warnings I encountered when compiling this today: drivers/iommu/exynos-iommu.c: In function ‘exynos_iommu_of_setup’: drivers/iommu/exynos-iommu.c:1177:2: warning: passing argument 2 of ‘of_iommu_set_ops’ discards ‘const’ qualifier from pointer target type [enabled by default] of_iommu_set_ops(np, &exynos_iommu_ops); ^ In file included from drivers/iommu/exynos-iommu.c:23:0: include/linux/of_iommu.h:34:6: note: expected ‘struct iommu_ops *’ but argument is of type ‘const struct iommu_ops *’ void of_iommu_set_ops(struct device_node *np, struct iommu_ops *ops); ^ I guess the 'const' should be dropped from exynos_iommu_ops, even though I wonder why of_iommu_set_ops wants a non-const pointer (can/does it modify the struct later on?). With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drm: exynos: mixer: fix using usleep() in atomic context
Hello! Inki Dae wrote: > The use of spin lock, reg_slock, has been used for a long time and we > hadn't some cleanups to spin lock codes so far. The spin lock is also > used in here and there of mixer driver. And at least, it seems that > the use of spin lock isn't required in mixer_win_reset. I don't see > any atomic contexts in mixer module except interrupt handler. > > To Seung-Woo, > I know that you referred to mixer codes of v4l2 based mixer driver. So > was the spin lock used in origin v4l2 driver? or Is there any reason > that you used the spin lock? > > Anyway, we will have some testing to check hdmi and mixer drivers > without spin lock. So we will remove or replace it with mutex if > needed. > > Thanks, > Inki Dae So it's some weeks later and as far as I can see there has been no changes to the spinlock usage. Wouldn't it be better to apply this patch _now_ (since the use of 'usleep_range' is just plain wrong while under spinlock). When the spinlock setup gets cleaned up later, then we can always change back to 'usleep_range' again. Any thoughts? With best wishes, Tobias -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
* santosh shilimkar [150121 13:31]: > On 1/21/2015 12:43 PM, Tony Lindgren wrote: > >* santosh shilimkar [150121 12:16]: > >> > >>TWD is useless on this machine since single core and TWD > >>as know die in low power states. All the broadcast stuff > >>is for SMP machines. > > > >Hmm it seems we should still use TWD during runtime and > >swich over to the gptimer for idle states for wake-up > >events. > > > Well timer wheel code don't support it so if you are serious, > some one needs to do that. For me, it is not worth at all. > You will have more to loose than gain with these time switching > schemes since you have to keep 2 times alive, do switching, loose > the idle time. > > All of that is to save few CPU cycles since TWD is closer > compared to other SOC timer. > > Anyways I will let you fight it out but IIRC, I had a > discussion a while back with tglx in one of the conference > and the conclusion was it not worth doing. > Rather TWD hardware on SOC should be made wakeup capable > and then everything is good. > > Till you have support, using TWD on AM43XX will break CPUIDLE. > Not sure if it is supported or some one cares about it. Just > keep that aspect in mind. Yes sure I'm aware of this. It should be easy to profile the speed gain to see if it would make much of a difference before starting to tinker with that. The way I think it's possible to do would be to copy the TWD timer value to a wake-up capable gptimer before hitting any deeper idle state. Of course some aux timer support might be still needed :) Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
On 1/21/2015 12:43 PM, Tony Lindgren wrote: * santosh shilimkar [150121 12:16]: On 1/21/2015 10:36 AM, Tony Lindgren wrote: * Marc Zyngier [150121 09:25]: On 21/01/15 16:30, Tony Lindgren wrote: I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Interesting. No TWD timer on this one? Good question, adding Felipe to cc. It eems to be there in the TRM in "Table 2-3. L4_PER Peripheral Memory Map" as MPU_PRV_TIMERS. Also seems to actually work with the attached patch: TWD is useless on this machine since single core and TWD as know die in low power states. All the broadcast stuff is for SMP machines. Hmm it seems we should still use TWD during runtime and swich over to the gptimer for idle states for wake-up events. Well timer wheel code don't support it so if you are serious, some one needs to do that. For me, it is not worth at all. You will have more to loose than gain with these time switching schemes since you have to keep 2 times alive, do switching, loose the idle time. All of that is to save few CPU cycles since TWD is closer compared to other SOC timer. Anyways I will let you fight it out but IIRC, I had a discussion a while back with tglx in one of the conference and the conclusion was it not worth doing. Rather TWD hardware on SOC should be made wakeup capable and then everything is good. Till you have support, using TWD on AM43XX will break CPUIDLE. Not sure if it is supported or some one cares about it. Just keep that aspect in mind. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
* santosh shilimkar [150121 12:16]: > On 1/21/2015 10:36 AM, Tony Lindgren wrote: > >* Marc Zyngier [150121 09:25]: > >>On 21/01/15 16:30, Tony Lindgren wrote: > >> > >>>I gave this a quick boot test on am437x-gp-evm and the > >>>interrupts look OK with the fix also applied: > >>> > >>># cat /proc/interrupts > >>> CPU0 > >>> 16:657 WUGEN 68 gp_timer > >>> 18: 0 WUGEN 9 l3-dbg-irq > >>> 19: 0 WUGEN 10 l3-app-irq > >>> 20: 5 WUGEN 12 edma > >>> 22: 0 WUGEN 14 edma_error > >>> 23: 96 WUGEN 72 OMAP UART0 > >>> 33: 0 44e07000.gpio 6 mmc0 > >>>158: 52 WUGEN 70 44e0b000.i2c > >>>159: 0 WUGEN 71 4802a000.i2c > >>>160: 35 WUGEN 64 mmc0 > >>>161: 0 WUGEN 40 4a10.ethernet > >>>162: 7739 WUGEN 41 4a10.ethernet > >>>163: 7608 WUGEN 42 4a10.ethernet > >>>164: 0 WUGEN 43 4a10.ethernet > >>>170: 0 WUGEN 100 gpmc > >>>180: 0 WUGEN 7 tps65218 > >>>IPI0: 0 CPU wakeup interrupts > >>>IPI1: 0 Timer broadcast interrupts > >>>IPI2: 0 Rescheduling interrupts > >>>IPI3: 0 Function call interrupts > >>>IPI4: 0 Single function call interrupts > >>>IPI5: 0 CPU stop interrupts > >>>IPI6: 0 IRQ work interrupts > >>>IPI7: 0 completion interrupts > >>>Err: 0 > >> > >>Interesting. No TWD timer on this one? > > > >Good question, adding Felipe to cc. It eems to be there in > >the TRM in "Table 2-3. L4_PER Peripheral Memory Map" as > >MPU_PRV_TIMERS. Also seems to actually work with the > >attached patch: > > > TWD is useless on this machine since single core and TWD > as know die in low power states. All the broadcast stuff > is for SMP machines. Hmm it seems we should still use TWD during runtime and swich over to the gptimer for idle states for wake-up events. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
On 1/21/2015 10:36 AM, Tony Lindgren wrote: * Marc Zyngier [150121 09:25]: On 21/01/15 16:30, Tony Lindgren wrote: I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Interesting. No TWD timer on this one? Good question, adding Felipe to cc. It eems to be there in the TRM in "Table 2-3. L4_PER Peripheral Memory Map" as MPU_PRV_TIMERS. Also seems to actually work with the attached patch: TWD is useless on this machine since single core and TWD as know die in low power states. All the broadcast stuff is for SMP machines. Above is expected and correct and no patching is needed. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
* Marc Zyngier [150121 09:25]:
> On 21/01/15 16:30, Tony Lindgren wrote:
>
> > I gave this a quick boot test on am437x-gp-evm and the
> > interrupts look OK with the fix also applied:
> >
> > # cat /proc/interrupts
> > CPU0
> > 16:657 WUGEN 68 gp_timer
> > 18: 0 WUGEN 9 l3-dbg-irq
> > 19: 0 WUGEN 10 l3-app-irq
> > 20: 5 WUGEN 12 edma
> > 22: 0 WUGEN 14 edma_error
> > 23: 96 WUGEN 72 OMAP UART0
> > 33: 0 44e07000.gpio 6 mmc0
> > 158: 52 WUGEN 70 44e0b000.i2c
> > 159: 0 WUGEN 71 4802a000.i2c
> > 160: 35 WUGEN 64 mmc0
> > 161: 0 WUGEN 40 4a10.ethernet
> > 162: 7739 WUGEN 41 4a10.ethernet
> > 163: 7608 WUGEN 42 4a10.ethernet
> > 164: 0 WUGEN 43 4a10.ethernet
> > 170: 0 WUGEN 100 gpmc
> > 180: 0 WUGEN 7 tps65218
> > IPI0: 0 CPU wakeup interrupts
> > IPI1: 0 Timer broadcast interrupts
> > IPI2: 0 Rescheduling interrupts
> > IPI3: 0 Function call interrupts
> > IPI4: 0 Single function call interrupts
> > IPI5: 0 CPU stop interrupts
> > IPI6: 0 IRQ work interrupts
> > IPI7: 0 completion interrupts
> > Err: 0
>
> Interesting. No TWD timer on this one?
Good question, adding Felipe to cc. It eems to be there in
the TRM in "Table 2-3. L4_PER Peripheral Memory Map" as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:
# cat /proc/interrupts
CPU0
16: 0 WUGEN 67 gp_timer
17:529 GIC 29 twd
18: 0 WUGEN 9 l3-dbg-irq
19: 0 WUGEN 10 l3-app-irq
20: 5 WUGEN 12 edma
22: 0 WUGEN 14 edma_error
23:130 WUGEN 72 OMAP UART0
34: 0 44e07000.gpio 6 mmc0
159: 52 WUGEN 70 44e0b000.i2c
160: 0 WUGEN 71 4802a000.i2c
161: 35 WUGEN 64 mmc0
162: 0 WUGEN 40 4a10.ethernet
163: 8033 WUGEN 41 4a10.ethernet
164: 7769 WUGEN 42 4a10.ethernet
165: 0 WUGEN 43 4a10.ethernet
171: 0 WUGEN 100 gpmc
181: 0 WUGEN 7 tps65218
IPI0: 0 CPU wakeup interrupts
IPI1: 0 Timer broadcast interrupts
IPI2: 0 Rescheduling interrupts
IPI3: 0 Function call interrupts
IPI4: 0 Single function call interrupts
IPI5: 0 CPU stop interrupts
IPI6: 0 IRQ work interrupts
IPI7: 0 completion interrupts
Err: 0
Hmm I wonder why we have the !is_smp() check in the TWD timer?
Regards,
Tony
8< ---
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -51,6 +51,14 @@
interrupt-parent = <&gic>;
};
+ local-timer@48240600 {
+ compatible = "arm,cortex-a9-twd-timer";
+ clocks = <&dpll_mpu_m2_ck>;
+ reg = <0x48240600 0x20>;
+ interrupts = ;
+ interrupt-parent = <&gic>;
+ };
+
wakeupgen: interrupt-controller@48281000 {
compatible = "ti,omap4-wugen-mpu";
interrupt-controller;
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -388,7 +388,7 @@ static void __init twd_local_timer_of_register(struct
device_node *np)
{
int err;
- if (!is_smp() || !setup_max_cpus)
+ if (!setup_max_cpus)
return;
twd_ppi = irq_of_parse_and_map(np, 0);
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -237,7 +237,7 @@ DT_MACHINE_START(AM43_DT, "Generic AM43 (Flattened Device
Tree)")
.init_late = am43xx_init_late,
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
- .init_time = omap3_gptimer_timer_init,
+ .init_time = omap4_local_timer_init,
.dt_compat = am43_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 12/21] DT: omap4/5: add binding for the wake-up generator
* Marc Zyngier [150119 01:48]:
> Signed-off-by: Marc Zyngier
Acked-by: Tony Lindgren
> ---
> .../interrupt-controller/ti,omap4-wugen-mpu| 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
> b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
> new file mode 100644
> index 000..43effa0
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
> @@ -0,0 +1,33 @@
> +TI OMAP4 Wake-up Generator
> +
> +All TI OMAP4/5 (and their derivatives) an interrupt controller that
> +routes interrupts to the GIC, and also serves as a wakeup source. It
> +is also referred to as "WUGEN-MPU", hence the name of the binding.
> +
> +Reguired properties:
> +
> +- compatible : should contain at least "ti,omap4-wugen-mpu" or
> + "ti,omap5-wugen-mpu"
> +- reg : Specifies base physical address and size of the registers.
> +- interrupt-controller : Identifies the node as an interrupt controller.
> +- #interrupt-cells : Specifies the number of cells needed to encode an
> + interrupt source. The value must be 3.
> +- interrupt-parent : a phandle to the GIC these interrupts are routed
> + to.
> +
> +Notes:
> +
> +- Because this HW ultimately routes interrupts to the GIC, the
> + interrupt specifier must be that of the GIC.
> +- Only SPIs can use the WUGEN as an interrupt parent. SGIs and PPIs
> + are explicitly forbiden.
> +
> +Example:
> +
> + wakeupgen: interrupt-controller@48281000 {
> + compatible = "ti,omap5-wugen-mpu", "ti,omap4-wugen-mpu";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0x48281000 0x1000>;
> + interrupt-parent = <&gic>;
> + };
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
On 21/01/15 16:30, Tony Lindgren wrote: > * Marc Zyngier [150119 01:48]: >> OMAP4/5 has been (ab)using the gic_arch_extn to provide >> wakeup from suspend, and it makes a lot of sense to convert >> this code to use stacked domains instead. >> >> This patch does just this, updating the DT files to actually >> reflect what the HW provides. >> >> BIG FAT WARNING: because the DTs were so far lying by not >> exposing the WUGEN HW block, kernels with this patch applied >> won't have any suspend-resume facility when booted with old DTs, >> and old kernels with updated DTs won't even boot. >> >> On a platform with this patch applied, the system looks like >> this: >> >> root@bacon-fat:~# cat /proc/interrupts >> CPU0 CPU1 >> 16: 0 0 WUGEN 37 gp_timer >> 19: 233799 155916 GIC 27 arch_timer >> 23: 0 0 WUGEN 9 l3-dbg-irq >> 24: 1 0 WUGEN 10 l3-app-irq >> 27:282 0 WUGEN 13 omap-dma-engine >> 44: 0 0 4ae1.gpio 13 DMA > > You may want to update this part for the fix :) Ah, yes. Thanks for noticing this. > I gave this a quick boot test on am437x-gp-evm and the > interrupts look OK with the fix also applied: > > # cat /proc/interrupts > CPU0 > 16:657 WUGEN 68 gp_timer > 18: 0 WUGEN 9 l3-dbg-irq > 19: 0 WUGEN 10 l3-app-irq > 20: 5 WUGEN 12 edma > 22: 0 WUGEN 14 edma_error > 23: 96 WUGEN 72 OMAP UART0 > 33: 0 44e07000.gpio 6 mmc0 > 158: 52 WUGEN 70 44e0b000.i2c > 159: 0 WUGEN 71 4802a000.i2c > 160: 35 WUGEN 64 mmc0 > 161: 0 WUGEN 40 4a10.ethernet > 162: 7739 WUGEN 41 4a10.ethernet > 163: 7608 WUGEN 42 4a10.ethernet > 164: 0 WUGEN 43 4a10.ethernet > 170: 0 WUGEN 100 gpmc > 180: 0 WUGEN 7 tps65218 > IPI0: 0 CPU wakeup interrupts > IPI1: 0 Timer broadcast interrupts > IPI2: 0 Rescheduling interrupts > IPI3: 0 Function call interrupts > IPI4: 0 Single function call interrupts > IPI5: 0 CPU stop interrupts > IPI6: 0 IRQ work interrupts > IPI7: 0 completion interrupts > Err: 0 Interesting. No TWD timer on this one? > Also verified that suspend and resume to a serial console event > works on omap4430-sdp. So please feel free to add: > > Acked-by: Tony Lindgren Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 3/7] mfd: cros_ec: Add cros_ec_lpc driver for x86 devices
Hello Lee,
On 01/20/2015 05:52 PM, Javier Martinez Canillas wrote:
>>>
>>> Now, all those drivers may be wrong and the buses don't belong to the mfd
>>> subsystem but then I think we need to document that since it seems that is
>>> the correct way to do it just by looking at the other drivers.
>>
>> I don't think the drivers you mentioned above do anything practical.
>> For instance, they are not SPI/IC2/etc drivers. They should only
>> offer some abstraction layers which are used to communicate with the
>> device. The driver you are submitting looks a lot more like a device
>> driver, which should live somewhere else. Don't ask me where though,
>> I'm not even sure what a Low Pin Controller does.
>>
>
> The driver added by $subject doesn't really do anything practical either.
> LPC [0] is just another transport method like i2c or spi that is used on
> x86 Chromebooks to access the Embedded Controller.
>
> So the driver is really not that different than the cros_ec_{i2c,spi}.c
> drivers.
>
> Best regards,
> Javier
>
> [0]: http://en.wikipedia.org/wiki/Low_Pin_Count
>
Maybe the problem is that the commit message didn't explain this clearly?
I took the patch from the ChromiumOS tree verbatim but I can reword the
commit message to add something like this instead:
Author: Bill Richardson
Date: Tue Dec 23 15:13:23 2014 +0100
mfd: cros_ec: Add cros_ec_lpc driver for x86 devices
Chromebooks have an Embedded Controller (EC) that is used to
implement various functions such as keyboard, power and battery.
The AP can communicate with the EC through different bus types
such as I2C, SPI or LPC.
The cros_ec mfd driver is then composed of a core driver that
register the sub-devices as mfd cells and provide a high level
communication interface that is used by the rest of the kernel
and bus specific interfaces modules.
Each connection method then has its own driver, which register
with the EC driver interface-agnostic interface.
Currently, there are drivers to communicate with the EC over
I2C and SPI and this driver adds support for LPC.
Signed-off-by: Bill Richardson
Signed-off-by: Javier Martinez Canillas
If you agree with this commit message then I can change it on the next revision
but really $subject doesn't do anything special besides providing a transport
method to access the mfd device using a LPC bus.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND v2 5/7] mfd: cros_ec: Instantiate ChromeOS EC character device
Hello Lee, On 01/20/2015 06:11 PM, Javier Martinez Canillas wrote: >> >> But is it really a chardev? Don't chardevs usually live in >> drivers/char? It probably uses a chardev node in /dev, but what does >> it really do? What information can/will userspace obtain from this >> memory block? >> > > Right, is a driver that register a chardev but mostly to expose an ioctl > interface to send commands to the Embedded Controller from user-space. > > The Application Processor communicates with Embedded Controller by sending > commands over an interface. This can be either spi or i2c on ARM (depending > on the Chromebook model) or LPC on x86 Chromebooks so the platform driver > instantiated by the "cros-ec-dev" mfd cell is to allow user-space to send > commands to the Embedded Controller (using the correct transport method). > > So this chardev is used by the ectool binary in ChromeOS to communicate > with the Embedded Controller. > Just FYI, I'll rename it to "cros-ec-ctl" since as you said is not really a chardev but that just happens to be the interface chosen to send the ioctl commands to the driver. Thanks a lot for your suggestion. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 13/21] ARM: omap: convert wakeupgen to stacked domains
* Marc Zyngier [150119 01:48]: > OMAP4/5 has been (ab)using the gic_arch_extn to provide > wakeup from suspend, and it makes a lot of sense to convert > this code to use stacked domains instead. > > This patch does just this, updating the DT files to actually > reflect what the HW provides. > > BIG FAT WARNING: because the DTs were so far lying by not > exposing the WUGEN HW block, kernels with this patch applied > won't have any suspend-resume facility when booted with old DTs, > and old kernels with updated DTs won't even boot. > > On a platform with this patch applied, the system looks like > this: > > root@bacon-fat:~# cat /proc/interrupts > CPU0 CPU1 > 16: 0 0 WUGEN 37 gp_timer > 19: 233799 155916 GIC 27 arch_timer > 23: 0 0 WUGEN 9 l3-dbg-irq > 24: 1 0 WUGEN 10 l3-app-irq > 27:282 0 WUGEN 13 omap-dma-engine > 44: 0 0 4ae1.gpio 13 DMA You may want to update this part for the fix :) I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Also verified that suspend and resume to a serial console event works on omap4430-sdp. So please feel free to add: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH v2 3/3] ARM: dts: Add sound nodes for exynos4412-trats2
Hi,
On 19/01/15 10:48, Inha Song wrote:
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> + sound {
> + compatible = "samsung,trats2-audio";
> + assigned-clocks = <&pmu_system_controller 0>;
> + assigned-clock-parents = <&clock CLK_XUSBXTI>;
How about putting these properties in the pmu_system_controller
node? After all the mux clock being configured here belongs to
the PMU subsystem. Wouldn't it work that way ?
> + samsung,i2s-controller = <&i2s0>;
> + samsung,model = "Trats2";
> + samsung,audio-codec = <&wm1811>;
> + samsung,audio-routing =
> + "SPK", "SPKOUTLN",
> + "SPK", "SPKOUTLP",
> + "SPK", "SPKOUTRN",
> + "SPK", "SPKOUTRP";
> + };
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] ARM: l2c: Maintain CPU endianness for early resume function
In big endian CPU mode l2x0_saved_regs structure stores registers values in BE format. In order to maintain BE CPU mode, these values and immediate constants must be converted back to LE format before writing them to cache controller. Signed-off-by: Dmitry Osipenko --- V2: no code change, fixed patch numbering, extended mail recipients list arch/arm/mm/l2c-l2x0-resume.S | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/mm/l2c-l2x0-resume.S b/arch/arm/mm/l2c-l2x0-resume.S index fda415e..9f99c7e 100644 --- a/arch/arm/mm/l2c-l2x0-resume.S +++ b/arch/arm/mm/l2c-l2x0-resume.S @@ -30,6 +30,15 @@ ENTRY(l2c310_early_resume) teq r1, #0 reteq lr + @ Reverse for big endian kernel +ARM_BE8(revr2, r2) +ARM_BE8(revr3, r3) +ARM_BE8(revr4, r4) +ARM_BE8(revr5, r5) +ARM_BE8(revr6, r6) +ARM_BE8(revr7, r7) +ARM_BE8(revr8, r8) + @ The prefetch and power control registers are revision dependent @ and can be written whether or not the L2 cache is enabled ldr r0, [r1, #L2X0_CACHE_ID] @@ -51,6 +60,7 @@ ENTRY(l2c310_early_resume) str r2, [r1, #L2X0_AUX_CTRL] mov r9, #L2X0_CTRL_EN +ARM_BE8(revr9, r9) str r9, [r1, #L2X0_CTRL] ret lr ENDPROC(l2c310_early_resume) -- 2.2.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] ARM: dts: Add HS400 support for exynos5420 and exynos5800
Hi Jaehoon
On Wed, Jan 21, 2015 at 4:32 AM, Jaehoon Chung wrote:
> Hi,
>
> If you want to enable the hs400 mode, need to add "mmc-hs400-1_8v" or
> "mmc-hs400-1_2v".
> But this patch didn't add them. do you have any other plan?
>
Yes, right, plan is to send separate patch to enable hs400, as of now
I am not sure if all the 5800-peach-pi boards are populated with
emmc5.0 device or not. So I will enable HS400 after confirming this
point.
> On 01/14/2015 07:30 PM, Alim Akhtar wrote:
>> From: Seungwon Jeon
>>
>> HS400 timing values are added for SMDK5420, exynos5420-peach-pit
>> and exynos5800-peach-pi boards.
>> This also adds RCLK GPIO line, this gpio should be in pull-down
>> state.
>>
>> Signed-off-by: Seungwon Jeon
>> Signed-off-by: Alim Akhtar
>> [Alim: addressed review comments]
>> ---
>> arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +++-
>> arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 +++
>> arch/arm/boot/dts/exynos5420-smdk5420.dts |4 +++-
>> arch/arm/boot/dts/exynos5800-peach-pi.dts |4 +++-
>> 4 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> index 9a050e1..7ffaba8 100644
>> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
>> @@ -569,8 +569,10 @@
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <0 4>;
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> + samsung,dw-mshc-hs400-timing = <0 2>;
>> + read-strobe-delay = <90>;
>> pinctrl-names = "default";
>> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>> bus-width = <8>;
>> };
>>
>> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>> index ba686e4..8b15316 100644
>> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
>> @@ -201,6 +201,13 @@
>> samsung,pin-drv = <3>;
>> };
>>
>> + sd0_rclk: sd0-rclk {
>
> I know it used to "sd0_rdqs", not "sd0_rclk".
> Change name.
>
Ok, I will change as per UM of 5800/5420,
> Best Regards,
> Jaehoon Chung
>> + samsung,pins = "gpc0-7";
>> + samsung,pin-function = <2>;
>> + samsung,pin-pud = <1>;
>> + samsung,pin-drv = <3>;
>> + };
>> +
>> sd1_cmd: sd1-cmd {
>> samsung,pins = "gpc1-1";
>> samsung,pin-function = <2>;
>> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> index 8be3d7b..5290e79 100644
>> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> @@ -80,8 +80,10 @@
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <0 4>;
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> + samsung,dw-mshc-hs400-timing = <0 2>;
>> + read-strobe-delay = <90>;
>> pinctrl-names = "default";
>> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>> bus-width = <8>;
>> cap-mmc-highspeed;
>> };
>> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> index e8fdda8..fa1c858 100644
>> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
>> @@ -557,8 +557,10 @@
>> samsung,dw-mshc-ciu-div = <3>;
>> samsung,dw-mshc-sdr-timing = <0 4>;
>> samsung,dw-mshc-ddr-timing = <0 2>;
>> + samsung,dw-mshc-hs400-timing = <0 2>;
>> + read-strobe-delay = <90>;
>> pinctrl-names = "default";
>> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
>> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>> bus-width = <8>;
>> };
>>
>>
>
--
Regards,
Alim
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: exynos5422-odroidxu3: reduce total RAM by 22 MiB
Last 22 MiB is RAM is reserved by secure monitor code and cannot be
accessed from Linux kernel, so adjust total RAM size to 0x7EA0
(2 GiB - 22 MiB). This fixes random 'imprecise kernel abort' kernel
failures.
Signed-off-by: Marek Szyprowski
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index f6fc9442f631..50843208860d 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -18,7 +18,7 @@
compatible = "hardkernel,odroid-xu3", "samsung,exynos5800",
"samsung,exynos5";
memory {
- reg = <0x4000 0x8000>;
+ reg = <0x4000 0x7EA0>;
};
chosen {
--
1.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: exynos5422-odroidxu3: add sound nodes
Hi,
On 21/01/15 06:58, Inha Song wrote:
> Add MAX98090 audio codec, I2S interface and the sound nodes to support
> audio on Odroid-XU3 board.
>
> Signed-off-by: Inha Song
> ---
> arch/arm/boot/dts/exynos5422-odroidxu3.dts | 34
> ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> index 7874da2..79493d1 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
> @@ -310,6 +310,40 @@
> rtc@101E {
> status = "okay";
> };
> +
> + sound: sound {
> + compatible = "samsung,odroidu3-audio";
How about using simple-card instead ? I've been trying to switch
Odroid X2/U3 to simple card. Here a corresponding dts patch:
http://www.spinics.net/lists/linux-samsung-soc/msg41083.html
For that recent patches for the I2S driver which area already in -next
might be needed.
> + samsung,model = "Odroid-XU3";
> + samsung,i2s-controller = <&i2s0>;
> + samsung,audio-codec = <&max98090>;
> + assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
> + <&clock_audss EXYNOS_MOUT_I2S>;
> + assigned-clock-parents = <&clock CLK_FIN_PLL>,
> + <&clock_audss EXYNOS_MOUT_AUDSS>;
> + samsung,audio-routing =
> + "Headphone Jack", "HPL",
> + "Headphone Jack", "HPR",
> + "Headphone Jack", "MICBIAS",
> + "IN1", "Headphone Jack",
> + "Speakers", "SPKL",
> + "Speakers", "SPKR";
> + };
> +};
> +
> +&hsi2c_5 {
> + status = "okay";
> + max98090: max98090@10 {
> + compatible = "maxim,max98090";
> + reg = <0x10>;
> + interrupt-parent = <&gpx3>;
> + interrupts = <2 0>;
> + clocks = <&clock_audss EXYNOS_DOUT_AUD_BUS>;
> + clock-names = "mclk";
> + };
> +};
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] clk: exynos5420: Add IDs for clocks used in DISP1 power domain
Hello, On 01/20/2015 06:54 PM, Mike Turquette wrote: > Quoting Sylwester Nawrocki (2015-01-20 06:04:00) >> Hi, >> >> On 20/01/15 11:35, Javier Martinez Canillas wrote: >> > When a power domain is powered off on Exynos5420 SoC, the input clocks of >> > the devices attached to this power domain are re-parented to oscclk and >> > restored to the original parent after powering on the power domain. >> > >> > So a reference to the input and parent clocks for the devices attached to >> > a power domain are needed to be able to do the re-parenting. The DISP1 pd >> > includes modules which uses the following clocks: >> > >> > ACLK_200_DISP1 (MIXER and HDMILINK) >> > ACLK_300_DISP1 (FIMD1) >> > ACLK_400_DISP1 (Internal Buses) >> > >> > Each of these clocks are generated as the output of a clock mux so add an >> > ID for all of these clock muxes and their parents to be referenced in the >> > DISP1 power domain device node. >> > >> > Signed-off-by: Javier Martinez Canillas >> >> The patch looks OK to me, I'm fine with it being merged via Kukjin's tree >> due to the dts dependencies (including other pending dts patches touching >> the arch/arm/boot/dts/exynos5420.dtsi file). >> I think we need also Mike ACK for that, I could also queue the patch for >> the clk tree and create a topic branch, but merging both patches via >> arm-soc seems a more sane option in this case. >> >> Acked-by: Sylwester Nawrocki > > Acked-by: Michael Turquette > Thanks a lot Sylwester and Mike for your acks. Kukjin, could you please pick $subject and "Patch 2/2 ARM: dts: Add DISP1 power domain for exynos5420" through your tree? Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
Hi Viresh, > On 21 January 2015 at 15:17, Lukasz Majewski > wrote: > > In previous versions I've only checked for cpu 0. > > > > If you think that it is enough to explicitly check only for cpu 0 > > and forget about above "fail safe" code (when. e.g. CPU3 has defined > > cooling-cells), then I'm fine with it. > > I don't know what bindings are you following, but cpufreq-dt's > bindings say that it has to be present in cpu0. Anyway, this driver > isn't for a multi-cluster system and so cpu0 should be fine. Ok. > > > As I've mention - it would be maintainer's call if one trades > > potential regression for patch separation. > > I am just asking it to split into a separate patch, not that I will > get it through > cpufreq. Eduardo can take it, but it should be a separate patch. Lets do it in this way :-). Thanks. -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
On 21 January 2015 at 15:17, Lukasz Majewski wrote: > In previous versions I've only checked for cpu 0. > > If you think that it is enough to explicitly check only for cpu 0 and > forget about above "fail safe" code (when. e.g. CPU3 has defined > cooling-cells), then I'm fine with it. I don't know what bindings are you following, but cpufreq-dt's bindings say that it has to be present in cpu0. Anyway, this driver isn't for a multi-cluster system and so cpu0 should be fine. > As I've mention - it would be maintainer's call if one trades potential > regression for patch separation. I am just asking it to split into a separate patch, not that I will get it through cpufreq. Eduardo can take it, but it should be a separate patch. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
Hi Viresh,
> On 21 January 2015 at 14:03, Lukasz Majewski
> wrote:
> >> diff --git a/drivers/cpufreq/exynos-cpufreq.c
>
> >> static int exynos_cpufreq_probe(struct platform_device *pdev)
> >> {
> >> + struct device_node *cpus, *np;
> >> int ret = -EINVAL;
> >>
> >> exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
> >> @@ -198,9 +202,31 @@ static int exynos_cpufreq_probe(struct
> >> platform_device *pdev) /* Done here as we want to capture boot
> >> frequency */ locking_frequency =
> >> clk_get_rate(exynos_info->cpu_clk) / 1000;
> >> - if (!cpufreq_register_driver(&exynos_driver))
> >> - return 0;
> >> + if (cpufreq_register_driver(&exynos_driver))
>
> You should return the error returned by cpufreq_register_driver().
OK.
>
> >> + goto err;
> >>
> >> + cpus = of_find_node_by_path("/cpus");
> >> + if (!cpus) {
> >> + pr_err("failed to find cpus node\n");
> >> + return -ENOENT;
> >> + }
> >> +
> >> + for (np = of_get_next_child(cpus, NULL); np;
> >> + of_node_put(np), np = of_get_next_child(cpus, np)) {
> >> + if (of_find_property(np, "#cooling-cells", NULL)) {
>
> Shouldn't you be checking this just for cpu 0 ?
In previous versions I've only checked for cpu 0.
If you think that it is enough to explicitly check only for cpu 0 and
forget about above "fail safe" code (when. e.g. CPU3 has defined
cooling-cells), then I'm fine with it.
>
> >> + cdev = of_cpufreq_cooling_register(np,
> >> +
> >> cpu_present_mask);
> >> + if (IS_ERR(cdev))
> >> + pr_err("running cpufreq without
> >> cooling device: %ld\n",
> >> +PTR_ERR(cdev));
> >> + break;
> >> + }
> >> + }
> >> + of_node_put(np);
> >> + of_node_put(cpus);
> >> +
> >> + return 0;
> >> + err:
> >> dev_err(&pdev->dev, "failed to register cpufreq driver\n");
> >> regulator_put(arm_regulator);
> >> err_vdd_arm:
> >
> > Viresh, the above is a small part of the cpufreq related code,
> > which is necessary for Exynos thermal rework to use device tree.
> >
> > It is NOT adding any new functionality, but preserves possibility to
> > use cpufreq as a colling device.
> >
> > Normally I would exclude this part from this commit, but then I
> > cannot assure that between commits no regression is slipping in.
>
> Mostly looks fine. Just few nits.
>
> But another important thing is to split this patch, so that there is
> a separate patch for cpufreq driver.
As I've mention - it would be maintainer's call if one trades potential
regression for patch separation.
Thanks for a prompt reply.
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
On 21 January 2015 at 14:03, Lukasz Majewski wrote:
>> diff --git a/drivers/cpufreq/exynos-cpufreq.c
>> static int exynos_cpufreq_probe(struct platform_device *pdev)
>> {
>> + struct device_node *cpus, *np;
>> int ret = -EINVAL;
>>
>> exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
>> @@ -198,9 +202,31 @@ static int exynos_cpufreq_probe(struct
>> platform_device *pdev) /* Done here as we want to capture boot
>> frequency */ locking_frequency = clk_get_rate(exynos_info->cpu_clk) /
>> 1000;
>> - if (!cpufreq_register_driver(&exynos_driver))
>> - return 0;
>> + if (cpufreq_register_driver(&exynos_driver))
You should return the error returned by cpufreq_register_driver().
>> + goto err;
>>
>> + cpus = of_find_node_by_path("/cpus");
>> + if (!cpus) {
>> + pr_err("failed to find cpus node\n");
>> + return -ENOENT;
>> + }
>> +
>> + for (np = of_get_next_child(cpus, NULL); np;
>> + of_node_put(np), np = of_get_next_child(cpus, np)) {
>> + if (of_find_property(np, "#cooling-cells", NULL)) {
Shouldn't you be checking this just for cpu 0 ?
>> + cdev = of_cpufreq_cooling_register(np,
>> +
>> cpu_present_mask);
>> + if (IS_ERR(cdev))
>> + pr_err("running cpufreq without
>> cooling device: %ld\n",
>> +PTR_ERR(cdev));
>> + break;
>> + }
>> + }
>> + of_node_put(np);
>> + of_node_put(cpus);
>> +
>> + return 0;
>> + err:
>> dev_err(&pdev->dev, "failed to register cpufreq driver\n");
>> regulator_put(arm_regulator);
>> err_vdd_arm:
>
> Viresh, the above is a small part of the cpufreq related code, which is
> necessary for Exynos thermal rework to use device tree.
>
> It is NOT adding any new functionality, but preserves possibility to
> use cpufreq as a colling device.
>
> Normally I would exclude this part from this commit, but then I cannot
> assure that between commits no regression is slipping in.
Mostly looks fine. Just few nits.
But another important thing is to split this patch, so that there is a separate
patch for cpufreq driver.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 18/18] thermal: exynos: Remove not needed exynos_tmu_init_data declarations from exynos_tmu.h
Hi Eduardo,
> On Mon, Jan 19, 2015 at 12:21:02PM +0100, Lukasz Majewski wrote:
> > After switching to device tree based configuration those
> > declarations are not needed anymore.
> >
> > Reported-by: Abhilash Kesavan
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v5:
> > - New patch
> > ---
> > | 8
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/exynos_tmu.h
> > b/drivers/thermal/samsung/exynos_tmu.h index d876d4c..9f9b1b8 100644
> > --- a/drivers/thermal/samsung/exynos_tmu.h
> > +++ b/drivers/thermal/samsung/exynos_tmu.h
> > @@ -71,12 +71,4 @@ struct exynos_tmu_platform_data {
> > u32 cal_mode;
> > };
> >
> > -extern struct exynos_tmu_init_data const
> > exynos3250_default_tmu_data; -extern struct exynos_tmu_init_data
> > const exynos4210_default_tmu_data; -extern struct
> > exynos_tmu_init_data const exynos4412_default_tmu_data; -extern
> > struct exynos_tmu_init_data const exynos5250_default_tmu_data;
> > -extern struct exynos_tmu_init_data const
> > exynos5260_default_tmu_data; -extern struct exynos_tmu_init_data
> > const exynos5420_default_tmu_data; -extern struct
> > exynos_tmu_init_data const exynos5440_default_tmu_data;
>
> Please merge this patch to the one that removes these symbols from
> kernel.
Will be done for v6 version.
>
> > -
> > #endif /* _EXYNOS_TMU_H */
> > --
> > 2.0.0.rc2
> >
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 15/18] thermal: samsung: core: Exynos TMU rework to use device tree for configuration
Hi Eduardo,
> On Mon, Jan 19, 2015 at 12:20:59PM +0100, Lukasz Majewski wrote:
> > This patch brings support for providing configuration via device
> > tree. Previously this data has been hardcoded in the
> > exynos_tmu_data.c file. Such approach was not scalable and very
> > often required copying the whole data.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
> > - Usage of of-thermal.c exported trip points table
> > Changes for v3:
> > - Adding exynos_of_get_soc_type() method to set SOC type from
> > device's compatible string
> > - "samsung,tmu_" prefix for TMU specific properties has been added
> > Changes for v4:
> > - None
> > Changes for v5:
> > - Remove duplicated exynos_tmu_initialize() - reported by Abhilash
> > Kesavan
> >
> > ---
> > drivers/thermal/samsung/Makefile | 2 -
> > drivers/thermal/samsung/exynos_tmu.c | 339
> > ++-
> > drivers/thermal/samsung/exynos_tmu.h | 53 +- 3 files changed,
> > 220 insertions(+), 174 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/Makefile
> > b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
> > --- a/drivers/thermal/samsung/Makefile
> > +++ b/drivers/thermal/samsung/Makefile
> > @@ -3,5 +3,3 @@
> > #
> > obj-$(CONFIG_EXYNOS_THERMAL) +=
> > exynos_thermal.o exynos_thermal-y :=
> > exynos_tmu.o -exynos_thermal-y +=
> > exynos_tmu_data.o
> > -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) +=
> > exynos_thermal_common.o diff --git
> > a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c index ae30f6a..9d2d685
> > 100644 --- a/drivers/thermal/samsung/exynos_tmu.c +++
> > b/drivers/thermal/samsung/exynos_tmu.c @@ -1,6 +1,10 @@ /*
> > * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
> > *
> > + * Copyright (C) 2014 Samsung Electronics
> > + * Bartlomiej Zolnierkiewicz
> > + * Lukasz Majewski
> > + *
> > * Copyright (C) 2011 Samsung Electronics
> > * Donggeun Kim
> > * Amit Daniel Kachhap
> > @@ -31,8 +35,8 @@
> > #include
> > #include
> >
> > -#include "exynos_thermal_common.h"
> > #include "exynos_tmu.h"
> > +#include "../thermal_core.h"
> >
> > /* Exynos generic registers */
> > #define EXYNOS_TMU_REG_TRIMINFO0x0
> > @@ -115,6 +119,7 @@
> > #define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
> > #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
> >
> > +#define MCELSIUS 1000
> > /**
> > * struct exynos_tmu_data : A structure to hold the private data
> > of the TMU driver
> > @@ -150,7 +155,8 @@ struct exynos_tmu_data {
> > struct clk *clk, *clk_sec;
> > u8 temp_error1, temp_error2;
> > struct regulator *regulator;
> > - struct thermal_sensor_conf *reg_conf;
> > + struct thermal_zone_device *tzd;
> > +
> > int (*tmu_initialize)(struct platform_device *pdev);
> > void (*tmu_control)(struct platform_device *pdev, bool on);
> > int (*tmu_read)(struct exynos_tmu_data *data);
> > @@ -159,6 +165,33 @@ struct exynos_tmu_data {
> > void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
> > };
> >
> > +static void exynos_report_trigger(struct exynos_tmu_data *p)
> > +{
> > + char data[10], *envp[] = { data, NULL };
> > + struct thermal_zone_device *tz = p->tzd;
> > + unsigned long temp;
> > + unsigned int i;
> > +
> > + if (!p) {
> > + pr_err("Wrong temperature configuration data\n");
> > + return;
> > + }
> > +
> > + thermal_zone_device_update(tz);
> > +
> > + mutex_lock(&tz->lock);
> > + /* Find the level for which trip happened */
> > + for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
> > + tz->ops->get_trip_temp(tz, i, &temp);
> > + if (tz->last_temperature < temp)
> > + break;
> > + }
> > +
> > + snprintf(data, sizeof(data), "%u", i);
> > + kobject_uevent_env(&tz->device.kobj, KOBJ_CHANGE, envp);
> > + mutex_unlock(&tz->lock);
> > +}
> > +
> > /*
> > * TMU treats temperature as a mapped temperature code.
> > * The temperature is converted differently depending on the
> > calibration type. @@ -234,14 +267,25 @@ static void
> > sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
> > static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold,
> > bool falling) {
> > - struct exynos_tmu_platform_data *pdata = data->pdata;
> > + struct thermal_zone_device *tz = data->tzd;
> > + const struct thermal_trip * const trips =
> > + of_thermal_get_trip_points(tz);
> > + unsigned long temp;
> > int i;
> >
> > - for (i = 0; i < pdata->non_hw_trigger_levels; i++) {
> > - u8 temp = pdata->trigger_levels[i];
> > + if (!trips) {
> > + pr_err("%s: Cannot get trip points from
> > of-thermal.c!\n",
> > + __func__);
> > + return 0
Re: [PATCH v5 15/18] thermal: samsung: core: Exynos TMU rework to use device tree for configuration
Hi Eduardo,
> On Mon, Jan 19, 2015 at 12:20:59PM +0100, Lukasz Majewski wrote:
> > This patch brings support for providing configuration via device
> > tree. Previously this data has been hardcoded in the
> > exynos_tmu_data.c file. Such approach was not scalable and very
> > often required copying the whole data.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
> > - Usage of of-thermal.c exported trip points table
> > Changes for v3:
> > - Adding exynos_of_get_soc_type() method to set SOC type from
> > device's compatible string
> > - "samsung,tmu_" prefix for TMU specific properties has been added
> > Changes for v4:
> > - None
> > Changes for v5:
> > - Remove duplicated exynos_tmu_initialize() - reported by Abhilash
> > Kesavan
> >
>
> several checkpatch.pl items to be reviewed in this patch:
> CHECK: No space is necessary after a cast
> #509: FILE: drivers/thermal/samsung/exynos_tmu.c:821:
> + pdata->gain = (u8) value;
>
> CHECK: No space is necessary after a cast
> #511: FILE: drivers/thermal/samsung/exynos_tmu.c:823:
> + pdata->reference_voltage = (u8) value;
>
>
> Can you please make sure all of your patches pass:
> checkpatch.pl --strict
` ^ Is now checkpatch.pl required to run with
--strict rule?
I've tested those patches only with checkpatch with no errors.
Has kernel policy changed recently? Are all developers now obliged to
use the --strict rule?
>
> ?
>
>
> > ---
> > drivers/thermal/samsung/Makefile | 2 -
> > drivers/thermal/samsung/exynos_tmu.c | 339
> > ++-
> > drivers/thermal/samsung/exynos_tmu.h | 53 +- 3 files changed,
> > 220 insertions(+), 174 deletions(-)
> >
> > diff --git a/drivers/thermal/samsung/Makefile
> > b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
> > --- a/drivers/thermal/samsung/Makefile
> > +++ b/drivers/thermal/samsung/Makefile
> > @@ -3,5 +3,3 @@
> > #
> > obj-$(CONFIG_EXYNOS_THERMAL) +=
> > exynos_thermal.o exynos_thermal-y :=
> > exynos_tmu.o -exynos_thermal-y +=
> > exynos_tmu_data.o
> > -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) +=
> > exynos_thermal_common.o diff --git
> > a/drivers/thermal/samsung/exynos_tmu.c
> > b/drivers/thermal/samsung/exynos_tmu.c index ae30f6a..9d2d685
> > 100644 --- a/drivers/thermal/samsung/exynos_tmu.c +++
> > b/drivers/thermal/samsung/exynos_tmu.c @@ -1,6 +1,10 @@ /*
> > * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
> > *
> > + * Copyright (C) 2014 Samsung Electronics
> > + * Bartlomiej Zolnierkiewicz
> > + * Lukasz Majewski
> > + *
> > * Copyright (C) 2011 Samsung Electronics
> > * Donggeun Kim
> > * Amit Daniel Kachhap
> > @@ -31,8 +35,8 @@
> > #include
> > #include
> >
> > -#include "exynos_thermal_common.h"
> > #include "exynos_tmu.h"
> > +#include "../thermal_core.h"
> >
> > /* Exynos generic registers */
> > #define EXYNOS_TMU_REG_TRIMINFO0x0
> > @@ -115,6 +119,7 @@
> > #define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
> > #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
> >
> > +#define MCELSIUS 1000
> > /**
> > * struct exynos_tmu_data : A structure to hold the private data
> > of the TMU driver
> > @@ -150,7 +155,8 @@ struct exynos_tmu_data {
> > struct clk *clk, *clk_sec;
> > u8 temp_error1, temp_error2;
> > struct regulator *regulator;
> > - struct thermal_sensor_conf *reg_conf;
> > + struct thermal_zone_device *tzd;
> > +
> > int (*tmu_initialize)(struct platform_device *pdev);
> > void (*tmu_control)(struct platform_device *pdev, bool on);
> > int (*tmu_read)(struct exynos_tmu_data *data);
> > @@ -159,6 +165,33 @@ struct exynos_tmu_data {
> > void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
> > };
> >
> > +static void exynos_report_trigger(struct exynos_tmu_data *p)
> > +{
> > + char data[10], *envp[] = { data, NULL };
> > + struct thermal_zone_device *tz = p->tzd;
> > + unsigned long temp;
> > + unsigned int i;
> > +
> > + if (!p) {
> > + pr_err("Wrong temperature configuration data\n");
> > + return;
> > + }
> > +
> > + thermal_zone_device_update(tz);
> > +
> > + mutex_lock(&tz->lock);
> > + /* Find the level for which trip happened */
> > + for (i = 0; i < of_thermal_get_ntrips(tz); i++) {
> > + tz->ops->get_trip_temp(tz, i, &temp);
> > + if (tz->last_temperature < temp)
> > + break;
> > + }
> > +
> > + snprintf(data, sizeof(data), "%u", i);
> > + kobject_uevent_env(&tz->device.kobj, KOBJ_CHANGE, envp);
> > + mutex_unlock(&tz->lock);
> > +}
> > +
> > /*
> > * TMU treats temperature as a mapped temperature code.
> > * The temperature is converted differently depending on the
> > calibration type. @@ -234,14 +267,25 @@ static void
>
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
Hi Viresh,
> Up till now exynos_tmu_data.c was used for storing CPU cooling
> configuration data. Now the Exynos thermal core code uses device tree
> to get this data. For this purpose generic thermal code for
> configuring CPU cooling was used.
>
> Signed-off-by: Lukasz Majewski
> ---
> Changes for v2:
> - None
> Changes for v3:
> - Rewrite code responsible for registering CPU cooling device to not
> depend on explicit "/cpus/cpu@0" path since now Exynos SoCs use new
> cpu node names (e.g. cpu@A00). New approach iterates over "cpus" node
> children.
> - Patch title changed to thermal: exynos
> Changes for v4:
> - None
> Changes for v5:
> - None
>
> ---
> drivers/cpufreq/exynos-cpufreq.c| 30 +-
> drivers/thermal/samsung/exynos_thermal_common.c | 122
> ++--
> drivers/thermal/samsung/exynos_tmu.c| 7 --
> drivers/thermal/samsung/exynos_tmu.h| 5 -
> drivers/thermal/samsung/exynos_tmu_data.c | 42 +--- 5
> files changed, 101 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/cpufreq/exynos-cpufreq.c
> b/drivers/cpufreq/exynos-cpufreq.c index f99a0b0..32bc64d 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -18,10 +18,13 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "exynos-cpufreq.h"
>
> static struct exynos_dvfs_info *exynos_info;
> +static struct thermal_cooling_device *cdev;
> static struct regulator *arm_regulator;
> static unsigned int locking_frequency;
>
> @@ -156,6 +159,7 @@ static struct cpufreq_driver exynos_driver = {
>
> static int exynos_cpufreq_probe(struct platform_device *pdev)
> {
> + struct device_node *cpus, *np;
> int ret = -EINVAL;
>
> exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
> @@ -198,9 +202,31 @@ static int exynos_cpufreq_probe(struct
> platform_device *pdev) /* Done here as we want to capture boot
> frequency */ locking_frequency = clk_get_rate(exynos_info->cpu_clk) /
> 1000;
> - if (!cpufreq_register_driver(&exynos_driver))
> - return 0;
> + if (cpufreq_register_driver(&exynos_driver))
> + goto err;
>
> + cpus = of_find_node_by_path("/cpus");
> + if (!cpus) {
> + pr_err("failed to find cpus node\n");
> + return -ENOENT;
> + }
> +
> + for (np = of_get_next_child(cpus, NULL); np;
> + of_node_put(np), np = of_get_next_child(cpus, np)) {
> + if (of_find_property(np, "#cooling-cells", NULL)) {
> + cdev = of_cpufreq_cooling_register(np,
> +
> cpu_present_mask);
> + if (IS_ERR(cdev))
> + pr_err("running cpufreq without
> cooling device: %ld\n",
> +PTR_ERR(cdev));
> + break;
> + }
> + }
> + of_node_put(np);
> + of_node_put(cpus);
> +
> + return 0;
> + err:
> dev_err(&pdev->dev, "failed to register cpufreq driver\n");
> regulator_put(arm_regulator);
> err_vdd_arm:
Viresh, the above is a small part of the cpufreq related code, which is
necessary for Exynos thermal rework to use device tree.
It is NOT adding any new functionality, but preserves possibility to
use cpufreq as a colling device.
Normally I would exclude this part from this commit, but then I cannot
assure that between commits no regression is slipping in.
> diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
> b/drivers/thermal/samsung/exynos_thermal_common.c index
> 6dc3815..00aa688 100644 ---
> a/drivers/thermal/samsung/exynos_thermal_common.c +++
> b/drivers/thermal/samsung/exynos_thermal_common.c @@ -133,47 +133,62
> @@ static int exynos_get_crit_temp(struct thermal_zone_device
> *thermal, static int exynos_bind(struct thermal_zone_device *thermal,
> struct thermal_cooling_device *cdev) {
> - int ret = 0, i, tab_size, level;
> - struct freq_clip_table *tab_ptr, *clip_data;
> struct exynos_thermal_zone *th_zone = thermal->devdata;
> struct thermal_sensor_conf *data = th_zone->sensor_conf;
> + struct device_node *child, *gchild, *np;
> + struct of_phandle_args cooling_spec;
> + unsigned long max, state = 0;
> + int ret = 0, i = 0;
>
> - tab_ptr = (struct freq_clip_table
> *)data->cooling_data.freq_data;
> - tab_size = data->cooling_data.freq_clip_count;
> -
> - if (tab_ptr == NULL || tab_size == 0)
> + /*
> + * Below code is necessary to skip binding when cpufreq's
> + * frequency table is not yet initialized.
> + */
> + cdev->ops->get_max_state(cdev, &state);
> + if (!state && !th_zone->cool_dev_size) {
> + th_zone->cool_dev_size = 1;
> + th_zone->cool_dev[0] = cdev;
> + th_zone->bind = false;
> return 0;
> + }
>
> - /* find the cooling device registered*/
> - for (i = 0; i < th_zone->cool_dev_size; i++)
> -
Re: [PATCH v5 07/18] thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration
Hi Eduardo,
> On Mon, Jan 19, 2015 at 12:20:51PM +0100, Lukasz Majewski wrote:
> > Up till now exynos_tmu_data.c was used for storing CPU cooling
> > configuration data. Now the Exynos thermal core code uses device
> > tree to get this data. For this purpose generic thermal code for
> > configuring CPU cooling was used.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - None
> > Changes for v3:
> > - Rewrite code responsible for registering CPU cooling device to
> > not depend on explicit "/cpus/cpu@0" path since now Exynos SoCs use
> > new cpu node names (e.g. cpu@A00). New approach iterates over
> > "cpus" node children.
> > - Patch title changed to thermal: exynos
> > Changes for v4:
> > - None
> > Changes for v5:
> > - None
> >
> > ---
> > drivers/cpufreq/exynos-cpufreq.c| 30 +-
> > drivers/thermal/samsung/exynos_thermal_common.c | 122
> > ++--
> > drivers/thermal/samsung/exynos_tmu.c| 7 --
> > drivers/thermal/samsung/exynos_tmu.h| 5 -
> > drivers/thermal/samsung/exynos_tmu_data.c | 42 +--- 5
> > files changed, 101 insertions(+), 105 deletions(-)
> >
> > diff --git a/drivers/cpufreq/exynos-cpufreq.c
> > b/drivers/cpufreq/exynos-cpufreq.c index f99a0b0..32bc64d 100644
> > --- a/drivers/cpufreq/exynos-cpufreq.c
> > +++ b/drivers/cpufreq/exynos-cpufreq.c
> > @@ -18,10 +18,13 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #include "exynos-cpufreq.h"
> >
> > static struct exynos_dvfs_info *exynos_info;
> > +static struct thermal_cooling_device *cdev;
> > static struct regulator *arm_regulator;
> > static unsigned int locking_frequency;
> >
> > @@ -156,6 +159,7 @@ static struct cpufreq_driver exynos_driver = {
> >
> > static int exynos_cpufreq_probe(struct platform_device *pdev)
> > {
> > + struct device_node *cpus, *np;
> > int ret = -EINVAL;
> >
> > exynos_info = kzalloc(sizeof(*exynos_info), GFP_KERNEL);
> > @@ -198,9 +202,31 @@ static int exynos_cpufreq_probe(struct
> > platform_device *pdev) /* Done here as we want to capture boot
> > frequency */ locking_frequency =
> > clk_get_rate(exynos_info->cpu_clk) / 1000;
> > - if (!cpufreq_register_driver(&exynos_driver))
> > - return 0;
> > + if (cpufreq_register_driver(&exynos_driver))
> > + goto err;
> >
> > + cpus = of_find_node_by_path("/cpus");
> > + if (!cpus) {
> > + pr_err("failed to find cpus node\n");
> > + return -ENOENT;
> > + }
> > +
> > + for (np = of_get_next_child(cpus, NULL); np;
> > +of_node_put(np), np = of_get_next_child(cpus, np)) {
> > + if (of_find_property(np, "#cooling-cells", NULL)) {
> > + cdev = of_cpufreq_cooling_register(np,
> > +
> > cpu_present_mask);
> > + if (IS_ERR(cdev))
> > + pr_err("running cpufreq without
> > cooling device: %ld\n",
> > + PTR_ERR(cdev));
> > + break;
> > + }
> > + }
> > + of_node_put(np);
> > + of_node_put(cpus);
> > +
> > + return 0;
> > + err:
> > dev_err(&pdev->dev, "failed to register cpufreq driver\n");
> > regulator_put(arm_regulator);
> > err_vdd_arm:
>
> You need at least an ack from a cpufreq maintainer to get this patch
> in. I would prefer if you split the cpufreq part from the thermal
> part. It avoids merge conflicts in the upstreaming process.
Please note that exynos-cpufreq part has around 30 LOC (which only
prevents from a regression).
When I split it, then if by some mishap this not find its way to
mainline in the same time as thermal, then we would have pretty nasty
regression.
I will ask Viresh to look into this code and NAK/ACK it.
>
> > diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
> > b/drivers/thermal/samsung/exynos_thermal_common.c index
> > 6dc3815..00aa688 100644 ---
> > a/drivers/thermal/samsung/exynos_thermal_common.c +++
> > b/drivers/thermal/samsung/exynos_thermal_common.c @@ -133,47
> > +133,62 @@ static int exynos_get_crit_temp(struct
> > thermal_zone_device *thermal, static int exynos_bind(struct
> > thermal_zone_device *thermal, struct thermal_cooling_device *cdev) {
> > - int ret = 0, i, tab_size, level;
> > - struct freq_clip_table *tab_ptr, *clip_data;
> > struct exynos_thermal_zone *th_zone = thermal->devdata;
> > struct thermal_sensor_conf *data = th_zone->sensor_conf;
> > + struct device_node *child, *gchild, *np;
> > + struct of_phandle_args cooling_spec;
> > + unsigned long max, state = 0;
> > + int ret = 0, i = 0;
> >
> > - tab_ptr = (struct freq_clip_table
> > *)data->cooling_data.freq_data;
> > - tab_size = data->cooling_data.freq_clip_count;
> > -
> > - if (tab_ptr == NULL || tab_size == 0)
> > + /*
> > +* Below code is necessary to skip binding when cpufreq's
> > +* frequency table is not yet initialized.
> > +*/
> >
Re: [PATCH v3 14/16] thermal: samsung: core: Exynos TMU rework to use device tree for configuration
Hi Eduardo,
> On Thu, Jan 15, 2015 at 04:17:52PM +0100, Lukasz Majewski wrote:
> > Hi Eduardo,
> >
> > > On Wed, Jan 14, 2015 at 02:41:12PM +0100, Lukasz Majewski wrote:
> > > > This patch brings support for providing configuration via device
> > > > tree. Previously this data has been hardcoded in the
> > > > exynos_tmu_data.c file. Such approach was not scalable and very
> > > > often required copying the whole data.
> > > >
> > > > Signed-off-by: Lukasz Majewski
> > > > ---
> > > > Changes for v2:
> > > > - Adjust exynos_tmu.c code to the newest ti-soc-thermal
> > > > repository
> > > > - Usage of of-thermal.c exported trip points table
> > > > Changes for v3:
> > > > - Adding exynos_of_get_soc_type() method to set SOC type from
> > > > device's compatible string
> > > > - "samsung,tmu_" prefix for TMU specific properties has been
> > > > added
> > > >
> > > > ---
> > > > drivers/thermal/samsung/Makefile | 2 -
> > > > drivers/thermal/samsung/exynos_tmu.c | 345
> > > > +++
> > > > drivers/thermal/samsung/exynos_tmu.h | 53 +- 3 files
> > > > changed, 226 insertions(+), 174 deletions(-)
> > > >
> > > > diff --git a/drivers/thermal/samsung/Makefile
> > > > b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
> > > > --- a/drivers/thermal/samsung/Makefile
> > > > +++ b/drivers/thermal/samsung/Makefile
> > > > @@ -3,5 +3,3 @@
> > > > #
> > > > obj-$(CONFIG_EXYNOS_THERMAL) +=
> > > > exynos_thermal.o
> > > > exynos_thermal-y:= exynos_tmu.o
> > > > -exynos_thermal-y +=
> > > > exynos_tmu_data.o
> > >
> > > Can this makefile change be part of the patch that removes
> > > exynos_tmu_data.c?
> > >
> > > > -exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) +=
> > > > exynos_thermal_common.o
> > >
> > > Can this makefile change be part of the patch that removes
> > > exynos_thermal_common.c?
> >
> > Unfortunately, this code cannot be moved to the next patch, in
> > which I remove the files, since this causes build break of the
> > series.
> >
> > The code structure as is, provides working, bisectable thermal
> > solution - thermal and cpu_cooling functionality is preserved across
> > all commits in the series.
>
> My concern here is simply that this specific commit is leaving unused
> files in the tree.
>
> One option would be to remove the files altogether in this specific
> commit.
Is is really necessary?
This patch itself changes around 400 LOC. Those changes __are__
important and in my opinion deserve their own commit.
When I squash following patches, which remove old exynos files, we
would have around 1.2K LOC in a single commit.
I think that current approach is far more readable.
Eduardo, is there a chance for this series (the newest version is v5 -
which include Ablibash comments) to be included to yours -next tree
before v3.19 is out?
>
> >
> > >
> > > > diff --git a/drivers/thermal/samsung/exynos_tmu.c
> > > > b/drivers/thermal/samsung/exynos_tmu.c index ae30f6a..633a9e2
> > > > 100644 --- a/drivers/thermal/samsung/exynos_tmu.c
> > > > +++ b/drivers/thermal/samsung/exynos_tmu.c
> > > > @@ -1,6 +1,10 @@
> > > > /*
> > > > * exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
> > > > *
> > > > + * Copyright (C) 2014 Samsung Electronics
> > > > + * Bartlomiej Zolnierkiewicz
> > > > + * Lukasz Majewski
> > > > + *
> > > > * Copyright (C) 2011 Samsung Electronics
> > > > * Donggeun Kim
> > > > * Amit Daniel Kachhap
> > > > @@ -31,8 +35,8 @@
> > > > #include
> > > > #include
> > > >
> > > > -#include "exynos_thermal_common.h"
> > > > #include "exynos_tmu.h"
> > > > +#include "../thermal_core.h"
> > > >
> > > > /* Exynos generic registers */
> > > > #define EXYNOS_TMU_REG_TRIMINFO0x0
> > > > @@ -115,6 +119,7 @@
> > > > #define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
> > > > #define EXYNOS5440_EFUSE_SWAP_OFFSET 8
> > > >
> > > > +#define MCELSIUS 1000
> > > > /**
> > > > * struct exynos_tmu_data : A structure to hold the private
> > > > data of the TMU driver
> > > > @@ -150,7 +155,8 @@ struct exynos_tmu_data {
> > > > struct clk *clk, *clk_sec;
> > > > u8 temp_error1, temp_error2;
> > > > struct regulator *regulator;
> > > > - struct thermal_sensor_conf *reg_conf;
> > > > + struct thermal_zone_device *tzd;
> > > > +
> > > > int (*tmu_initialize)(struct platform_device *pdev);
> > > > void (*tmu_control)(struct platform_device *pdev, bool
> > > > on); int (*tmu_read)(struct exynos_tmu_data *data);
> > > > @@ -159,6 +165,33 @@ struct exynos_tmu_data {
> > > > void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
> > > > };
> > > >
> > > > +static void exynos_report_trigger(struct exynos_tmu_data *p)
> > > > +{
> > > > + char data[10], *envp[] = { data, NULL };
> > > > + struct thermal_zone_device *tz = p->t
