Re: [RFC Patch v2 1/3] clk: add support for temporary parent clock migration
On 4 September 2013 03:17, Sylwester Nawrocki
wrote:
> Hi Chander,
>
>
> On 09/03/2013 01:34 PM, Chander Kashyap wrote:
>>
>> Some platforms use to migrate temporarily to another parent during cpu
>> frequency
>> scaling, e.g. Exynos and Tegra. Once the frequency is changed the latch on
>> to
>> original parent.
>>
>> The generic cpufreq-cpu0 driver use clk_set_rate API to scale cpu
>> frequency.
>> This patch is an attempt to address the above mentioned requirement.
>>
>> This is achieved as follows:
>>
>> Add a clk flag "CLK_SET_RATE_TEMP_PARENT" for clocks which need to migrate
>> to
>> another parent during set_rate operation on them.
>>
>> Add "temp_parent_name" and "tmp_parent" fields to clk structure i.e the
>> name of
>> temp_parent_clock and reference to temp_parent_clock.
>>
>> Hence in clk_set_rate API check for the "CLK_SET_RATE_TEMP_PARENT" flag,
>> then
>> latch on to alternate parent clock temporarily. Once the requested rate is
>> set
>> on the clk, re-parent back to original parent clock.
>>
>> Signed-off-by: Chander Kashyap
>> ---
>> drivers/clk/clk-mux.c| 13 +++--
>> drivers/clk/clk.c| 43
>> --
>> include/linux/clk-private.h | 19 +++
>> include/linux/clk-provider.h | 10 ++
>> 4 files changed, 65 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
>> index 4f96ff3..854b3ac 100644
>> --- a/drivers/clk/clk-mux.c
>> +++ b/drivers/clk/clk-mux.c
>> @@ -115,8 +115,8 @@ EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
>>
>> struct clk *clk_register_mux_table(struct device *dev, const char *name,
>> const char **parent_names, u8 num_parents, unsigned long
>> flags,
>> - void __iomem *reg, u8 shift, u32 mask,
>> - u8 clk_mux_flags, u32 *table, spinlock_t *lock)
>> + const char *temp_parent_name, void __iomem *reg, u8 shift,
>> + u32 mask, u8 clk_mux_flags, u32 *table, spinlock_t *lock)
>
>
> I'm not sure this is a good idea to split the changes like this. Applying
> this patch alone would cause a build break, wouldn't it ?
Yes this will build break if patch 1 is applied only.
>
> The users need to be updated in same patch, so patch 2/3 should be normally
> folded into this one.
ok
>
> [...]
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 2db08c0..0e29a5b 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -1425,8 +1425,8 @@ static void clk_change_rate(struct clk *clk)
>>*/
>> int clk_set_rate(struct clk *clk, unsigned long rate)
>> {
>> - struct clk *top, *fail_clk;
>> - int ret = 0;
>> + struct clk *top, *fail_clk, *parent = NULL;
>> + int ret = 0, index;
>>
>> if (!clk)
>> return 0;
>> @@ -1450,6 +1450,35 @@ int clk_set_rate(struct clk *clk, unsigned long
>> rate)
>> goto out;
>> }
>>
>> + /* Latch on to alternate parent temporarily if needed */
>> + if ((clk->flags& CLK_SET_RATE_TEMP_PARENT)&&
>> clk->temp_parent_name) {
>>
>> + /* Save current parent before latching on to alternate
>> parent */
>> + parent = clk->parent;
>> +
>> + if (!clk->temp_parent) {
>> + for (index = 0; index< clk->num_parents; index++)
>> {
>> + if (!strcmp(clk->parent_names[index],
>> + clk->temp_parent_name))
>> + clk->temp_parent =
>> +
>> __clk_lookup(clk->temp_parent_name);
>> + }
>> +
>> + if (!clk->temp_parent) {
>> + pr_warn("%s: wrong temp_parent_name %s",
>> + __func__, clk->temp_parent_name);
>> + ret = -EINVAL;
>> + goto out;
>> + }
>> + }
>> +
>> + ret = clk_set_parent(clk, clk->temp_parent);
>> + if (ret) {
>> + pr_warn("%s: failed to set %s parent\n",
>> + __func__, clk->temp_parent->name);
>> + goto out;
>> + }
>> + }
>> +
>> /* notify that we are about to change rates */
>> fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE);
>> if (fail_clk) {
>> @@ -1464,6 +1493,14 @@ int clk_set_rate(struct clk *clk, unsigned long
>> rate)
>> clk_change_rate(top);
>>
>> out:
>> + /* Reparent back to original parent */
>> + if (parent) {
>> + ret = clk_set_parent(clk, parent);
>> + if (ret)
>> + pr_warn("%s: failed to set %s parent\n",
>> + __func__, parent->name);
>> + }
>> +
>> clk_prepare_unlock();
>>
>> return ret;
>
Re: [RFC Patch v2 0/3] add temporary parent migration support
On 4 September 2013 04:06, Tomasz Figa wrote: > Hi Chander, > > On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: >> Some platform has provision to change cpu parent clock during >> cpu frequency scaling. This patch series provides a mechanism to >> implement the same using CCF. >> >> Patch1 provides mechanism to migrate to new parent temporarily. >> >> Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are >> modified to add support for clk migration. >> >> Patch3 adds support to Exynos5250 to use the clock parent migration >> feature implemented in CCF. > > I don't really like this approach. A need to change mux setting > temporarily is heavily platform-specific and I don't think it should be > handled by generic code. As of now beside samsung platforms, tegra is doing temporary parent migration. That why i opted to implement this feature in generic code. Here only set_parent operation is called on mux_clk. which is again implemented in generic framework. So i dont think any other platform specific requirements need to be taken care. >First of all there are many factor that you would > have to account for to make this solution generic, such as: > - board specific alternative parents, Yes true, that's why, that information is passed during registration time. > - exact moment of parent change, Here it is only during set rate operation. > - some other platform specific conditions, like CPU voltage that must be That will be handled separately when actual migration of cpufreq driver will be done. > changed when mux is changed, because it changes CPU frequency, > - and probably a lot of more factors that only people working with all > the platforms supported (and unsupported yet) by Linux. > > I can see at least two solutions for this problem that don't require > changing core code of common clock framework: > > 1) Implementing a special clock type using normal mux ops, but also > registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events > to perform parent switching. > > 2) Using normal mux clock, but registering such notifiers in clock > controller or cpufreq driver. > I agree with you, but i am attempting through generic framework be keeping in mind the future usage of this feature by other platforms. > Best regards, > Tomasz > -- with warm regards, Chander Kashyap -- 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] ARM: dts: Add dwmmc DT nodes for exynos5420 SOC
On Mon, Sep 2, 2013 at 5:51 PM, Tomasz Figa wrote:
> On Monday 02 of September 2013 16:45:41 Yuvaraj Kumar wrote:
>> On Fri, Aug 30, 2013 at 12:29 PM, Yuvaraj Kumar
> wrote:
>> > On Wed, Aug 28, 2013 at 5:52 PM, Tomasz Figa
> wrote:
>> >> Hi Yuvaraj,
>> >>
>> >> On Wednesday 28 of August 2013 17:33:06 Yuvaraj Kumar C D wrote:
>> >>> This patch adds the device tree node entries for exynos5420 SOC.
>> >>> Exynos5420 has a different version of DWMMC controller,so a new
>> >>> compatible string is used to distinguish it from the prior SOC's.
>> >>>
>> >>> This patch depends on
>> >>>
>> >>> mmc: dw_mmc: exynos: Add a new compatible string for exynos5420
>> >>>
>> >>> changes since v4:
>> >>> 1.Droppped the bypass-smu binding property.
>> >>> 2.Used compatible string "samsung,exynos5250-dw-mshc"
>> >>>
>> >>> for controller instance which does not have SMU.
>> >>>
>> >>> changes since V3:
>> >>> 1.change fifo-depth size from 0x80 to 0x40
>> >>> 2.Move the below properties
>> >>>
>> >>> a.card-detect-delay
>> >>> b.samsung,dw-mshc-ciu-div
>> >>> c.samsung,dw-mshc-sdr-timing
>> >>> d.samsung,dw-mshc-ddr-timing
>> >>>
>> >>> from SOC dts to board dts file as suggested by Doug Anderson
>> >>>
>> >>> changes since V2:
>> >>> 1.dropped num-slots property from node as its not required
>> >>>
>> >>> if number of card slots available is 1.
>> >>>
>> >>> 2.Move the below properties
>> >>>
>> >>> a.fifo-depth
>> >>> b.card-detect-delay
>> >>> c.samsung,dw-mshc-ciu-div
>> >>> d.samsung,dw-mshc-sdr-timing
>> >>> e.samsung,dw-mshc-ddr-timing
>> >>>
>> >>> from board dts to SOC dts,as these are not board specific
>> >>> properties.
>> >>>
>> >>> 3.Updated the binding document exynos-dw-mshc.txt.
>> >>>
>> >>> changes since V1:
>> >>> 1.disable node by status = disabled in SOC file
>> >>> 2.enable node by status = okay in board specific file
>> >>>
>> >>> Signed-off-by: Yuvaraj Kumar C D
>> >>> ---
>> >>>
>> >>> .../devicetree/bindings/mmc/exynos-dw-mshc.txt |2 +
>> >>> arch/arm/boot/dts/exynos5420-smdk5420.dts | 33
>> >>>
>> >>> + arch/arm/boot/dts/exynos5420.dtsi
>> >>> |
>> >>> 39 3 files changed, 74 insertions(+)
>> >>
>> >> This patch looks good to me now, except some minor comments below.
>> >>
>> >>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> >>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt index
>> >>> 6d1c098..84cd56f 100644
>> >>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> >>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> >>>
>> >>> @@ -16,6 +16,8 @@ Required Properties:
>> >>> specific extensions.
>> >>>
>> >>> - "samsung,exynos5250-dw-mshc": for controllers with Samsung
>> >>> Exynos5250
>> >>>
>> >>> specific extensions.
>> >>> + - "samsung,exynos5420-dw-mshc": for controllers with Samsung
>> >>> Exynos5420 + specific extensions.
>> >>>
>> >>> * samsung,dw-mshc-ciu-div: Specifies the divider value for the card
>> >>>
>> >>> interface unit (ciu) clock. This property is applicable only for
>> >>> Exynos5
>> >>> SoC's and diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> >>> b/arch/arm/boot/dts/exynos5420-smdk5420.dts index bafba25..3ce5c97
>> >>> 100644
>> >>> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> >>> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
>> >>> @@ -31,6 +31,39 @@
>> >>>
>> >>> };
>> >>>
>> >>> };
>> >>>
>> >>> + dwmmc0@1220 {
>> >>
>> >> Node name should not contain instance index. Instead, according to
>> >> ePAPR
>> >> recommendation, I would opt for a generic name such as mmc, mshc or
>> >> sdio- host. mshc is already used on Exynos 4 so it might be a good
>> >> idea to use it for consistency.
>> >
>> > If we change node name's to mshc, debug statements are look like below:
>> > dwmmc_exynos 1220.mshc: num-slots property not found, assuming 1
>> > slot is available
>> > dwmmc_exynos 1220.mshc: no vmmc regulator found: -19
>> > dwmmc_exynos 1220.mshc: Using internal DMA controller.
>> > dwmmc_exynos 1220.mshc: Version ID is 250a
>> > dwmmc_exynos 1220.mshc: DW MMC controller at irq 107, 64 bit host
>> > data width, 64 deep fifo
>> >
>> > "dwmmc_exynos" is platform driver name and "1220.mshc" from dt
>> > node.Is'nt it look like bit confusing?
>
> Well, device tree should be written in an OS-agnostic way, so it's not a
> valid reason to use node names not complying to the recommendations.
>
> Also, I don't see anything wrong in this name. There is a lot of devices
> named this way, like 1392.spi, 139d.pwm or 1380.serial.
>
> Looking at other dts(i) files around the kernel, mmc is the most commonly
> used node name for MMC contro
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul wrote:
> A few comments.
>
> On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
> wrote:
>> Exynos hdmiphy operations and configs are kept inside
>> the hdmi driver. Hdmiphy related code is tightly coupled
>> with hdmi IP driver.
>>
>> This patche moves hdmiphy related code to hdmiphy driver.
>
> s/patche/patch
>
ok.
>> It will help in cleanly supporting the hdmiphy variations
>> in further SoCs.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
>> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
>> +++-
>> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
>> 5 files changed, 533 insertions(+), 296 deletions(-)
>> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index 50decf8..240eca5 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -25,6 +25,7 @@ Required properties:
>> sclk_pixel.
>> - clock-names: aliases as per driver requirements for above clock IDs:
>> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>> +- phy: it points to hdmiphy dt node.
>> Example:
>>
>> hdmi {
>> @@ -32,4 +33,5 @@ Example:
>> reg = <0x1453 0x10>;
>> interrupts = <0 95 0>;
>> hpd-gpio = <&gpx3 7 1>;
>> + phy = <&hdmiphy>;
>> };
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> index 724cab1..1c839f8 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
>> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
>> exynos_drm_hdmi_context *ctx);
>> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
>> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
>> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
>> +
>> +int exynos_hdmiphy_driver_register(void);
>> +void exynos_hdmiphy_driver_unregister(void);
>> +
>> +void exynos_hdmiphy_enable(struct device *dev);
>> +void exynos_hdmiphy_disable(struct device *dev);
>> +int exynos_hdmiphy_check_mode(struct device *dev,
>> + struct drm_display_mode *mode);
>> +int exynos_hdmiphy_set_mode(struct device *dev,
>> + struct drm_display_mode *mode);
>> +int exynos_hdmiphy_conf_apply(struct device *dev);
>> #endif
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index f67ffca..3af4e4c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -34,6 +34,8 @@
>> #include
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include
>>
>> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
>> };
>>
>> struct hdmi_conf_regs {
>> - int pixel_clock;
>> int cea_video_id;
>> union {
>> struct hdmi_v13_conf v13_conf;
>> @@ -193,9 +194,9 @@ struct hdmi_context {
>> int irq;
>>
>> struct i2c_client *ddc_port;
>> - struct i2c_client *hdmiphy_port;
>> + struct device *hdmiphy_dev;
>>
>> - /* current hdmiphy conf regs */
>> + /* current hdmi ip configuration registers. */
>> struct hdmi_conf_regs mode_conf;
>>
>> struct hdmi_resources res;
>> @@ -205,180 +206,6 @@ struct hdmi_context {
>> enum hdmi_type type;
>> };
>>
>> -struct hdmiphy_config {
>> - int pixel_clock;
>> - u8 conf[32];
>> -};
>> -
>> -/* list of phy config settings */
>> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
>> - {
>> - .pixel_clock = 2700,
>> - .conf = {
>> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
>> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
>> - },
>> - },
>> - {
>> - .pixel_clock = 27027000,
>> - .conf = {
>> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
>> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
>> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
>> - },
>> - },
>> -
[PATCH 3/3] thermal: samsung: Add TMU support for Exynos5420 SoCs
This patch adds the neccessary register changes and arch information
to support Exynos5420 SoCs
Exynos5420 has 5 TMU channels one for each CPU 0, 1, 2 and 3 and GPU
Also updated the Documentation at
Documentation/devicetree/bindings/thermal/exynos-thermal.txt
Note: The platform data structure will be handled properly once the driver
moves to complete device driver solution.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
1. modified the platform data structure in order to pass SHARED flag
for channels that need sharing of address space.
2. https://lkml.org/lkml/2013/8/1/38 is merged into this patch.
As the changes are minimum and can be added here.
.../devicetree/bindings/thermal/exynos-thermal.txt | 39 ++
drivers/thermal/samsung/exynos_tmu.c | 14 ++-
drivers/thermal/samsung/exynos_tmu.h |1 +
drivers/thermal/samsung/exynos_tmu_data.c | 130
drivers/thermal/samsung/exynos_tmu_data.h |7 ++
5 files changed, 189 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 116cca0..d70f2a4 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -7,12 +7,23 @@
"samsung,exynos4210-tmu"
"samsung,exynos5250-tmu"
"samsung,exynos5440-tmu"
+ "samsung,exynos5420-tmu"
- interrupt-parent : The phandle for the interrupt controller
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
belongs to each instance of TMU and second set belongs to second set
of common TMU registers.
+ NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ channels 2, 3 and 4
+
+ TRIMINFO at 0x1006c000 contains data for TMU channel 3
+ TRIMINFO at 0x100a contains data for TMU channel 4
+ TRIMINFO at 0x10068000 contains data for TMU channel 2
+
+ The misplaced register address is passed through devicetree as the
+ second base
+
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
@@ -43,6 +54,34 @@ Example 2):
clock-names = "tmu_apbif";
};
+Example 3): (In case of Exynos5420)
+ /* tmu for CPU2 */
+ tmu@10068000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+ interrupts = <0 184 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for CPU3 */
+ tmu@1006c000 {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x1006c000 0x100>, <0x100a 0x4>;
+ interrupts = <0 185 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
+ /* tmu for GPU */
+ tmu@100a {
+ compatible = "samsung,exynos5420-tmu";
+ reg = <0x100a 0x100>, <0x10068000 0x4>;
+ interrupts = <0 215 0>;
+ clocks = <&clock 318>;
+ clock-names = "tmu_apbif";
+ };
+
Note: For multi-instance tmu each instance should have an alias correctly
numbered in "aliases" node.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index 3a55caf..6d34652 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -186,7 +186,12 @@ static int exynos_tmu_initialize(struct platform_device
*pdev)
EXYNOS5440_EFUSE_SWAP_OFFSET + reg->triminfo_data);
}
} else {
- trim_info = readl(data->base + reg->triminfo_data);
+ /* On exynos5420 the triminfo register is in the shared space */
+ if (data->base_second && (data->soc == SOC_ARCH_EXYNOS5420))
+ trim_info = readl(data->base_second +
+ reg->triminfo_data);
+ else
+ trim_info = readl(data->base + reg->triminfo_data);
}
data->temp_error1 = trim_info & EXYNOS_TMU_TEMP_MASK;
data->temp_error2 = ((trim_info >> reg->triminfo_85_shift) &
@@ -499,6 +504,10 @@ static const struct of_device_id exynos_tmu_match[] = {
.compatible = "samsung,exynos5440-tmu",
.data = (void *)EXYNOS5440_TMU_DRV_DATA,
},
+ {
+ .compatible = "samsung,exynos5420-tmu",
+ .data = (void *)EXYNOS5420_TMU_DRV_DATA,
+ },
{},
};
MODULE_DEVICE_TABLE(of, exynos_
[PATCH 2/3] thermal: samsung: change base_common to more meaningful base_second
On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.
To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.
As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v2:
Changed the flag name from SHARED_MEMORY to ADDRESS_MULTIPLE.
https://lkml.org/lkml/2013/8/1/38
.../devicetree/bindings/thermal/exynos-thermal.txt |4 ++--
drivers/thermal/samsung/exynos_tmu.c | 12 ++--
drivers/thermal/samsung/exynos_tmu.h |4 ++--
drivers/thermal/samsung/exynos_tmu_data.c |2 +-
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..116cca0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
- reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
- belongs to each instance of TMU and second set belongs to common TMU
- registers.
+ belongs to each instance of TMU and second set belongs to second set
+ of common TMU registers.
- interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
- clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index d201ed8..3a55caf 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
* @id: identifier of the one instance of the TMU controller.
* @pdata: pointer to the tmu platform/configuration data
* @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
* @irq: irq number of the TMU controller.
* @soc: id of the SOC type.
* @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
- void __iomem *base_common;
+ void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
- writel(0, data->base_common + reg->tmu_pmin);
+ writel(0, data->base_second + reg->tmu_pmin);
out:
clk_disable(data->clk);
mutex_unlock(&data->lock);
@@ -451,7 +451,7 @@ static void exynos_tmu_work(struct work_struct *work)
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
- val_type = readl(data->base_common + reg->tmu_irqstatus);
+ val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -582,7 +582,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
* Check if the TMU shares some registers and then try to map the
* memory of common registers.
*/
- if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+ if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
@@ -590,7 +590,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
- data->base_common = devm_ioremap(&pdev->dev, res.start,
+ data->base_second = devm_ioremap(&pdev->dev, res.start,
resource_size(&res));
if (!data->base) {
dev_err(&pdev->dev, "Failed to ioremap memory\n");
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index 7c6c34a..ebd2ec1 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -59,7 +59,7 @@ enum soc_type {
* state(active/idle) can be checked.
* TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
* sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This feature tells that the different TMU
* sensors shares some common registers.
* TMU_SUPPORT - macro to compare the above features with the supplied.
*/
@@ -69,7 +69,7 @@ enu
[PATCH 1/3] thermal: samsung: correct the fall interrupt en, status bit fields
The FALL interrupt related en, status bits are available at an offset of
16 on INTEN, INTSTAT registers and at an offset of
12 on INTCLEAR register.
This patch corrects the same for exyns5250 and exynos5440
Signed-off-by: Naveen Krishna Chatradhi
---
Changes since v1:
None
drivers/thermal/samsung/exynos_tmu.c |2 +-
drivers/thermal/samsung/exynos_tmu.h |2 ++
drivers/thermal/samsung/exynos_tmu_data.c |2 ++
drivers/thermal/samsung/exynos_tmu_data.h |3 ++-
4 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c
index ec01dfe..d201ed8 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -265,7 +265,7 @@ skip_calib_data:
data->base + reg->threshold_th1);
writel((reg->inten_rise_mask << reg->inten_rise_shift) |
- (reg->inten_fall_mask << reg->inten_fall_shift),
+ (reg->inten_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h
b/drivers/thermal/samsung/exynos_tmu.h
index b364c9e..7c6c34a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -134,6 +134,7 @@ enum soc_type {
* @inten_fall3_shift: shift bits of falling 3 interrupt bits.
* @tmu_intstat: Register containing the interrupt status values.
* @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
* @emul_con: TMU emulation controller register.
* @emul_temp_shift: shift bits of emulation temperature.
* @emul_time_shift: shift bits of emulation time.
@@ -204,6 +205,7 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
u32 tmu_intclear;
+ u32 intclr_fall_shift;
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
b/drivers/thermal/samsung/exynos_tmu_data.c
index 9002499..23fea23 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -122,6 +122,7 @@ static const struct exynos_tmu_registers
exynos5250_tmu_registers = {
.inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
.tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.emul_con = EXYNOS_EMUL_CON,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
.emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
@@ -210,6 +211,7 @@ static const struct exynos_tmu_registers
exynos5440_tmu_registers = {
.inten_fall0_shift = EXYNOS5440_TMU_INTEN_FALL0_SHIFT,
.tmu_intstat = EXYNOS5440_TMU_S0_7_IRQ,
.tmu_intclear = EXYNOS5440_TMU_S0_7_IRQ,
+ .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
.tmu_irqstatus = EXYNOS5440_TMU_IRQ_STATUS,
.emul_con = EXYNOS5440_TMU_S0_7_DEBUG,
.emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/thermal/samsung/exynos_tmu_data.h
index dc7feb5..8788a87 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.h
+++ b/drivers/thermal/samsung/exynos_tmu_data.h
@@ -69,9 +69,10 @@
#define EXYNOS_TMU_RISE_INT_MASK 0x111
#define EXYNOS_TMU_RISE_INT_SHIFT 0
#define EXYNOS_TMU_FALL_INT_MASK 0x111
-#define EXYNOS_TMU_FALL_INT_SHIFT 12
+#define EXYNOS_TMU_FALL_INT_SHIFT 16
#define EXYNOS_TMU_CLEAR_RISE_INT 0x111
#define EXYNOS_TMU_CLEAR_FALL_INT (0x111 << 12)
+#define EXYNOS_TMU_CLEAR_FALL_INT_SHIFT12
#define EXYNOS_TMU_TRIP_MODE_SHIFT 13
#define EXYNOS_TMU_TRIP_MODE_MASK 0x7
#define EXYNOS_TMU_THERM_TRIP_EN_SHIFT 12
--
1.7.9.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: Fix style in s3c-hsotg.c
On 09/02/2013 05:58 PM, Pavel Machek wrote:
> Hi!
>
> checkpatch.pl has some valid complaints about style in s3c-hsotg.c :
> macro with if should be really enclosed in do {} while, and puts is
> going to be slightly faster.
>
> Here's suggested patch. I don't have the hardware, so it is completely
> untested.
CC'ed linux-samsung-soc@vger.kernel.org, Kukjin Kim
Hi Pavel Machek,
I have the hardware. :-)
Also, I am developing USB stuff of Samsung SoCs.
>
> Signed-off-by: Pavel Machek,
>
> diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
> index af22f24..f8e762a 100644
> --- a/drivers/usb/gadget/s3c-hsotg.c
> +++ b/drivers/usb/gadget/s3c-hsotg.c
> @@ -2091,12 +2091,14 @@ static void kill_all_requests(struct s3c_hsotg *hsotg,
> }
>
> #define call_gadget(_hs, _entry) \
> +do { \
> if ((_hs)->gadget.speed != USB_SPEED_UNKNOWN && \
> (_hs)->driver && (_hs)->driver->_entry) { \
> spin_unlock(&_hs->lock); \
> (_hs)->driver->_entry(&(_hs)->gadget); \
> spin_lock(&_hs->lock); \
> }
> +} while (0)
It makes build error.
Thus, it should be fixed as below:
} \
} while(0)
Other things look good.
Thank you for sending the patch. :)
Best regards,
Jingoo Han
--
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: [RFC Patch v2 0/3] add temporary parent migration support
Hi Chander, On Tuesday 03 of September 2013 17:04:28 Chander Kashyap wrote: > Some platform has provision to change cpu parent clock during > cpu frequency scaling. This patch series provides a mechanism to > implement the same using CCF. > > Patch1 provides mechanism to migrate to new parent temporarily. > > Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are > modified to add support for clk migration. > > Patch3 adds support to Exynos5250 to use the clock parent migration > feature implemented in CCF. I don't really like this approach. A need to change mux setting temporarily is heavily platform-specific and I don't think it should be handled by generic code. First of all there are many factor that you would have to account for to make this solution generic, such as: - board specific alternative parents, - exact moment of parent change, - some other platform specific conditions, like CPU voltage that must be changed when mux is changed, because it changes CPU frequency, - and probably a lot of more factors that only people working with all the platforms supported (and unsupported yet) by Linux. I can see at least two solutions for this problem that don't require changing core code of common clock framework: 1) Implementing a special clock type using normal mux ops, but also registering a notifier for its PRE_RATE_CHANGE and POST_RATE_CHANGE events to perform parent switching. 2) Using normal mux clock, but registering such notifiers in clock controller or cpufreq driver. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC Patch v2 1/3] clk: add support for temporary parent clock migration
Hi Chander,
On 09/03/2013 01:34 PM, Chander Kashyap wrote:
Some platforms use to migrate temporarily to another parent during cpu frequency
scaling, e.g. Exynos and Tegra. Once the frequency is changed the latch on to
original parent.
The generic cpufreq-cpu0 driver use clk_set_rate API to scale cpu frequency.
This patch is an attempt to address the above mentioned requirement.
This is achieved as follows:
Add a clk flag "CLK_SET_RATE_TEMP_PARENT" for clocks which need to migrate to
another parent during set_rate operation on them.
Add "temp_parent_name" and "tmp_parent" fields to clk structure i.e the name of
temp_parent_clock and reference to temp_parent_clock.
Hence in clk_set_rate API check for the "CLK_SET_RATE_TEMP_PARENT" flag, then
latch on to alternate parent clock temporarily. Once the requested rate is set
on the clk, re-parent back to original parent clock.
Signed-off-by: Chander Kashyap
---
drivers/clk/clk-mux.c| 13 +++--
drivers/clk/clk.c| 43 --
include/linux/clk-private.h | 19 +++
include/linux/clk-provider.h | 10 ++
4 files changed, 65 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 4f96ff3..854b3ac 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -115,8 +115,8 @@ EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
struct clk *clk_register_mux_table(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
- void __iomem *reg, u8 shift, u32 mask,
- u8 clk_mux_flags, u32 *table, spinlock_t *lock)
+ const char *temp_parent_name, void __iomem *reg, u8 shift,
+ u32 mask, u8 clk_mux_flags, u32 *table, spinlock_t *lock)
I'm not sure this is a good idea to split the changes like this. Applying
this patch alone would cause a build break, wouldn't it ?
The users need to be updated in same patch, so patch 2/3 should be normally
folded into this one.
[...]
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2db08c0..0e29a5b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1425,8 +1425,8 @@ static void clk_change_rate(struct clk *clk)
*/
int clk_set_rate(struct clk *clk, unsigned long rate)
{
- struct clk *top, *fail_clk;
- int ret = 0;
+ struct clk *top, *fail_clk, *parent = NULL;
+ int ret = 0, index;
if (!clk)
return 0;
@@ -1450,6 +1450,35 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
goto out;
}
+ /* Latch on to alternate parent temporarily if needed */
+ if ((clk->flags& CLK_SET_RATE_TEMP_PARENT)&& clk->temp_parent_name) {
+ /* Save current parent before latching on to alternate parent */
+ parent = clk->parent;
+
+ if (!clk->temp_parent) {
+ for (index = 0; index< clk->num_parents; index++) {
+ if (!strcmp(clk->parent_names[index],
+ clk->temp_parent_name))
+ clk->temp_parent =
+ __clk_lookup(clk->temp_parent_name);
+ }
+
+ if (!clk->temp_parent) {
+ pr_warn("%s: wrong temp_parent_name %s",
+ __func__, clk->temp_parent_name);
+ ret = -EINVAL;
+ goto out;
+ }
+ }
+
+ ret = clk_set_parent(clk, clk->temp_parent);
+ if (ret) {
+ pr_warn("%s: failed to set %s parent\n",
+ __func__, clk->temp_parent->name);
+ goto out;
+ }
+ }
+
/* notify that we are about to change rates */
fail_clk = clk_propagate_rate_change(top, PRE_RATE_CHANGE);
if (fail_clk) {
@@ -1464,6 +1493,14 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
clk_change_rate(top);
out:
+ /* Reparent back to original parent */
+ if (parent) {
+ ret = clk_set_parent(clk, parent);
+ if (ret)
+ pr_warn("%s: failed to set %s parent\n",
+ __func__, parent->name);
+ }
+
clk_prepare_unlock();
return ret;
[...]
diff --git a/include/linux/clk-private.h b/include/linux/clk-private.h
index 8138c94..b70ba4d 100644
--- a/include/linux/clk-private.h
+++ b/include/linux/clk-private.h
@@ -47,6 +47,8 @@ struct clk {
#ifdef CONFIG_COMMON_CLK_DEBUG
struct dentry *dentry;
#endif
+ const char *temp_parent_name;
+ struct clk *temp_parent;
Shouldn't such data rather be on struct clk_mux level ? It's
Re: [PATCH 4/7] drm/exynos: add support for exynos5420 hdmiphy
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos5420 hdmiphy device is a platform device, unlike
> predecessor SoCs where it used to be a I2C device. This
> support is added to the hdmiphy driver.
>
Stuffing a platform driver in the same place as your i2c driver seems
weird. I think you should split them up.
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmiphy.c | 224
> ++-
> 1 file changed, 221 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index b1b8a0f..33e89d9 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -32,6 +32,7 @@ struct hdmiphy_context {
>
> /* hdmiphy resources */
> void __iomem*phy_pow_ctrl_reg;
> + void __iomem*regs;
>
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> @@ -48,6 +49,135 @@ struct hdmiphy_drv_data {
> };
>
> /* list of all required phy config settings */
> +static struct hdmiphy_config hdmiphy_5420_configs[] = {
> + {
> + .pixel_clock = 2520,
> + .conf = {
> + 0x01, 0x52, 0x3F, 0x55, 0x40, 0x01, 0x00, 0xC8,
> + 0x82, 0xC8, 0xBD, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x01, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xF4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 2700,
> + .conf = {
> + 0x01, 0xD1, 0x22, 0x51, 0x40, 0x08, 0xFC, 0xE0,
> + 0x98, 0xE8, 0xCB, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE4, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 27027000,
> + .conf = {
> + 0x01, 0xD1, 0x2D, 0x72, 0x40, 0x64, 0x12, 0xC8,
> + 0x43, 0xE8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x06, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xE3, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 3600,
> + .conf = {
> + 0x01, 0x51, 0x2D, 0x55, 0x40, 0x40, 0x00, 0xC8,
> + 0x02, 0xC8, 0x0E, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xAB, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 4000,
> + .conf = {
> + 0x01, 0xD1, 0x21, 0x31, 0x40, 0x3C, 0x28, 0xC8,
> + 0x87, 0xE8, 0xC8, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x9A, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 6500,
> + .conf = {
> + 0x01, 0xD1, 0x36, 0x34, 0x40, 0x0C, 0x04, 0xC8,
> + 0x82, 0xE8, 0x45, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xBD, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7100,
> + .conf = {
> + 0x01, 0xD1, 0x3B, 0x35, 0x40, 0x0C, 0x04, 0xC8,
> + 0x85, 0xE8, 0x63, 0xD9, 0x45, 0xA0, 0xAC, 0x80,
> + 0x08, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0x57, 0x24, 0x00, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 74176000,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x5B, 0xEF, 0xC8,
> + 0x81, 0xE8, 0xB9, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA6, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 7425,
> + .conf = {
> + 0x01, 0xD1, 0x1F, 0x10, 0x40, 0x40, 0xF8, 0xC8,
> + 0x81, 0xE8, 0xBA, 0xD8, 0x45, 0xA0, 0xAC, 0x80,
> + 0x56, 0x80, 0x09, 0x84, 0x05, 0x02, 0x24, 0x66,
> + 0x54, 0xA5, 0x24, 0x01, 0x00, 0x00, 0x01, 0x80,
> + },
> + },
> + {
> + .pixel_clock = 8350,
> + .conf = {
> + 0x01, 0xD1, 0x
Re: [PATCH 3/7] drm/exynos: add hdmiphy pmu bit control in hdmiphy driver
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Before hdmiphy operation like config, start etc, hdmiphy
> bit in PMU block should be enabled. Earlier this happens
> in hdmi drvier through a dummy "hdmiphy" clock.
s/drvier/driver/
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmiphy.txt |6 ++
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
> drivers/gpu/drm/exynos/exynos_hdmi.c |2 +
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 82
>
> 4 files changed, 92 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> index 162f641..f6bf096 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
> @@ -6,10 +6,16 @@ Required properties:
> 2) "samsung,exynos4210-hdmiphy".
> 3) "samsung,exynos4212-hdmiphy".
> - reg: I2C address of the hdmiphy device.
> +- phy-power-control: this child node represents phy power control
> + register which is inside the pmu block (power management unit).
Should you include devicetree-discuss on this?
>
> Example:
>
> hdmiphy {
> compatible = "samsung,exynos4210-hdmiphy";
> reg = <0x38>;
> +
> + phy-power-control {
> + reg = <0x10040700 0x04>;
> + };
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 1c839f8..9a14f96 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -68,6 +68,8 @@ void exynos_mixer_ops_register(struct exynos_mixer_ops
> *ops);
> int exynos_hdmiphy_driver_register(void);
> void exynos_hdmiphy_driver_unregister(void);
>
> +void exynos_hdmiphy_poweron(struct device *dev);
> +void exynos_hdmiphy_poweroff(struct device *dev);
> void exynos_hdmiphy_enable(struct device *dev);
> void exynos_hdmiphy_disable(struct device *dev);
> int exynos_hdmiphy_check_mode(struct device *dev,
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index cd1d921..a6234fc 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1131,6 +1131,7 @@ static void hdmiphy_poweron(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweron(hdata->hdmiphy_dev);
> }
>
> static void hdmiphy_poweroff(struct hdmi_context *hdata)
> @@ -1138,6 +1139,7 @@ static void hdmiphy_poweroff(struct hdmi_context *hdata)
> if (hdata->type == HDMI_TYPE14)
> hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0,
> HDMI_PHY_POWER_OFF_EN);
> + exynos_hdmiphy_poweroff(hdata->hdmiphy_dev);
Shouldn't the phy power off before HDMI?
> }
>
> static void hdmi_conf_apply(struct hdmi_context *hdata)
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> index 82daa42..b1b8a0f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmiphy.c
> @@ -30,6 +30,9 @@ struct hdmiphy_context {
> struct device *dev;
> struct hdmiphy_config *current_conf;
>
> + /* hdmiphy resources */
> + void __iomem*phy_pow_ctrl_reg;
> +
> struct hdmiphy_config *confs;
> unsigned intnr_confs;
> };
> @@ -225,6 +228,49 @@ static struct hdmiphy_config *hdmiphy_find_conf(struct
> hdmiphy_context *hdata,
> return NULL;
> }
>
> +static int hdmiphy_dt_parse_power_control(struct hdmiphy_context *hdata)
> +{
> + struct device_node *phy_pow_ctrl_node;
> + u32 buf[2];
> + int ret = 0;
> +
> + phy_pow_ctrl_node = of_get_child_by_name(hdata->dev->of_node,
> + "phy-power-control");
> + if (!phy_pow_ctrl_node) {
> + DRM_ERROR("Failed to find phy power control node\n");
> + ret = -ENODEV;
> + goto fail;
You can just return -ENODEV here.
> + }
> +
> + /* reg property holds two informations: addr of pmu register, size */
> + if (of_property_read_u32_array(phy_pow_ctrl_node, "reg",
> + (u32 *)&buf, 2)) {
Maybe I'm missing something, but this looks bad. I think this should be:
of_property_read_u32_array(phy_pow_ctrl_node, "reg", buf, ARRAY_SIZE(buf))
ie: dereferencing buf won't do what you expect it to.
> + DRM_ERROR("faild to get phy power control reg\n");
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + hdata->phy_pow_ctrl_reg = devm_ioremap(hdata->dev, buf[0], buf[1]);
>
Re: [PATCH v11 0/8] PHY framework
Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: > Hi, > > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: >>> Added a generic PHY framework that provides a set of APIs for the PHY >>> drivers >>> to create/destroy a PHY and APIs for the PHY users to obtain a reference to >>> the PHY with or without using phandle. >>> >>> This framework will be of use only to devices that uses external PHY (PHY >>> functionality is not embedded within the controller). >>> >>> The intention of creating this framework is to bring the phy drivers spread >>> all over the Linux kernel to drivers/phy to increase code re-use and to >>> increase code maintainability. >>> >>> Comments to make PHY as bus wasn't done because PHY devices can be part of >>> other bus and making a same device attached to multiple bus leads to bad >>> design. >>> >>> If the PHY driver has to send notification on connect/disconnect, the PHY >>> driver should make use of the extcon framework. Using this susbsystem >>> to use extcon framwork will have to be analysed. >>> >>> You can find this patch series @ >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing >> >> Looks like there are not further comments on this series. Can you take this >> in >> your misc tree? > > Do you want me to queue these for you ? There are quite a few users for > this framework already and I know of at least 2 others which will show > up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] drm/exynos: remove dummy hdmiphy clock
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> hdmiphy is a dummy clock which actually controls the PMU bit
> to enable/disbale hdmiphy (before CCF). This clock is cleaned
s/disbale/disable/
> from the hdmi driver.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c |8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 3af4e4c..cd1d921 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -84,7 +84,6 @@ struct hdmi_resources {
> struct clk *sclk_hdmi;
> struct clk *sclk_pixel;
> struct clk *sclk_hdmiphy;
> - struct clk *hdmiphy;
> struct clk *mout_hdmi;
> struct regulator_bulk_data *regul_bulk;
> int regul_count;
> @@ -1431,7 +1430,6 @@ static void hdmi_poweron(struct hdmi_context *hdata)
> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>
> - clk_prepare_enable(res->hdmiphy);
> clk_prepare_enable(res->hdmi);
> clk_prepare_enable(res->sclk_hdmi);
>
> @@ -1456,7 +1454,6 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
>
> clk_disable_unprepare(res->sclk_hdmi);
> clk_disable_unprepare(res->hdmi);
> - clk_disable_unprepare(res->hdmiphy);
> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>
> mutex_lock(&hdata->hdmi_mutex);
> @@ -1549,11 +1546,6 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
> DRM_ERROR("failed to get clock 'sclk_hdmiphy'\n");
> goto fail;
> }
> - res->hdmiphy = devm_clk_get(dev, "hdmiphy");
> - if (IS_ERR(res->hdmiphy)) {
> - DRM_ERROR("failed to get clock 'hdmiphy'\n");
> - goto fail;
> - }
> res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
> if (IS_ERR(res->mout_hdmi)) {
> DRM_ERROR("failed to get clock 'mout_hdmi'\n");
> --
> 1.7.10.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 v11 0/8] PHY framework
On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: > >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: > >>> Added a generic PHY framework that provides a set of APIs for the PHY > >>> drivers > >>> to create/destroy a PHY and APIs for the PHY users to obtain a reference > >>> to > >>> the PHY with or without using phandle. > >>> > >>> This framework will be of use only to devices that uses external PHY (PHY > >>> functionality is not embedded within the controller). > >>> > >>> The intention of creating this framework is to bring the phy drivers > >>> spread > >>> all over the Linux kernel to drivers/phy to increase code re-use and to > >>> increase code maintainability. > >>> > >>> Comments to make PHY as bus wasn't done because PHY devices can be part of > >>> other bus and making a same device attached to multiple bus leads to bad > >>> design. > >>> > >>> If the PHY driver has to send notification on connect/disconnect, the PHY > >>> driver should make use of the extcon framework. Using this susbsystem > >>> to use extcon framwork will have to be analysed. > >>> > >>> You can find this patch series @ > >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing > >> > >> Looks like there are not further comments on this series. Can you take > >> this in > >> your misc tree? > > > > Do you want me to queue these for you ? There are quite a few users for > > this framework already and I know of at least 2 others which will show > > up for v3.13. > > Can you queue this patch series? There are quite a few users already for this > framework. It will have to wait for 3.13 as the merge window for new features has been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 is out. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma wrote:
> Exynos hdmiphy operations and configs are kept inside
> the hdmi driver. Hdmiphy related code is tightly coupled
> with hdmi IP driver.
>
> This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
> It will help in cleanly supporting the hdmiphy variations
> in further SoCs.
>
> Signed-off-by: Rahul Sharma
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt |2 +
> drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 343 +++
> drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
> +++-
> drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
> 5 files changed, 533 insertions(+), 296 deletions(-)
> create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> index 50decf8..240eca5 100644
> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
> @@ -25,6 +25,7 @@ Required properties:
> sclk_pixel.
> - clock-names: aliases as per driver requirements for above clock IDs:
> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
> +- phy: it points to hdmiphy dt node.
> Example:
>
> hdmi {
> @@ -32,4 +33,5 @@ Example:
> reg = <0x1453 0x10>;
> interrupts = <0 95 0>;
> hpd-gpio = <&gpx3 7 1>;
> + phy = <&hdmiphy>;
> };
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> index 724cab1..1c839f8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
> @@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context
> *ctx);
> void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
> void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
> void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
> +
> +int exynos_hdmiphy_driver_register(void);
> +void exynos_hdmiphy_driver_unregister(void);
> +
> +void exynos_hdmiphy_enable(struct device *dev);
> +void exynos_hdmiphy_disable(struct device *dev);
> +int exynos_hdmiphy_check_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_set_mode(struct device *dev,
> + struct drm_display_mode *mode);
> +int exynos_hdmiphy_conf_apply(struct device *dev);
> #endif
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index f67ffca..3af4e4c 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -34,6 +34,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -172,7 +174,6 @@ struct hdmi_v14_conf {
> };
>
> struct hdmi_conf_regs {
> - int pixel_clock;
> int cea_video_id;
> union {
> struct hdmi_v13_conf v13_conf;
> @@ -193,9 +194,9 @@ struct hdmi_context {
> int irq;
>
> struct i2c_client *ddc_port;
> - struct i2c_client *hdmiphy_port;
> + struct device *hdmiphy_dev;
>
> - /* current hdmiphy conf regs */
> + /* current hdmi ip configuration registers. */
> struct hdmi_conf_regs mode_conf;
>
> struct hdmi_resources res;
> @@ -205,180 +206,6 @@ struct hdmi_context {
> enum hdmi_type type;
> };
>
> -struct hdmiphy_config {
> - int pixel_clock;
> - u8 conf[32];
> -};
> -
> -/* list of phy config settings */
> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> - {
> - .pixel_clock = 2700,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 27027000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09, 0x64,
> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
> - 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10, 0xE0,
> - 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00, 0x00,
> - },
> - },
> - {
> - .pixel_clock = 74176000,
> - .conf = {
> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef, 0x5B,
> - 0x6D, 0x10, 0x01, 0x51, 0
[RFC Patch v2 3/3] clk: samsung: Exynos5250: Add alternate parent name for mout_cpu
Temporary parent migration is required during cpu frequency scaling. Hence
this patch adds support to supply alternate parent name for cpu clock i.e.
"mout_cpu".
Signed-off-by: Chander Kashyap
---
drivers/clk/samsung/clk-exynos5250.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index d90e593..aec2e09 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -239,7 +239,9 @@ static struct samsung_mux_clock exynos5250_pll_pmux_clks[]
__initdata = {
static struct samsung_mux_clock exynos5250_mux_clks[] __initdata = {
MUX_A(none, "mout_apll", mout_apll_p, SRC_CPU, 0, 1, "mout_apll"),
- MUX_A(none, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1, "mout_cpu"),
+ MUX_FA(none, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1,
+ CLK_SET_RATE_PARENT | CLK_SET_RATE_TEMP_PARENT,
+ 0, "mout_cpu", "sclk_mpll"),
MUX(none, "mout_mpll_fout", mout_mpll_fout_p, PLL_DIV2_SEL, 4, 1),
MUX_A(none, "sclk_mpll", mout_mpll_p, SRC_CORE1, 8, 1, "mout_mpll"),
MUX(none, "mout_bpll_fout", mout_bpll_fout_p, PLL_DIV2_SEL, 0, 1),
--
1.7.9.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
[RFC Patch v2 0/3] add temporary parent migration support
Some platform has provision to change cpu parent clock during cpu frequency scaling. This patch series provides a mechanism to implement the same using CCF. Patch1 provides mechanism to migrate to new parent temporarily. Patch2 updates the user of clk_register_mux and DEFINE_CLK_MUX which are modified to add support for clk migration. Patch3 adds support to Exynos5250 to use the clock parent migration feature implemented in CCF. Changes in v2: - Renamed flag name from CLK_SET_RATE_ALTERNATE to CLK_SET_RATE_TEMP_PARENT - Renamed "alternate_parent_name" to "temp_parent_name" and "alternate_parent" to "temp_parent" Chander Kashyap (3): clk: add support for temporary parent clock migration clk: update users of "clk_register_mux" and "DEFINE_CLK_MUX" clk: samsung: Exynos5250: Add alternate parent name for mout_cpu arch/arm/mach-imx/clk.h|6 +-- arch/arm/mach-omap2/cclock2420_data.c |2 +- arch/arm/mach-omap2/cclock2430_data.c |4 +- arch/arm/mach-omap2/cclock33xx_data.c |7 +-- arch/arm/mach-omap2/cclock3xxx_data.c |8 ++-- arch/arm/mach-omap2/cclock44xx_data.c | 61 + drivers/clk/clk-mux.c | 13 +++--- drivers/clk/clk.c | 43 +- drivers/clk/mmp/clk-mmp2.c | 39 ++-- drivers/clk/mmp/clk-pxa910.c | 30 drivers/clk/mxs/clk.h |2 +- drivers/clk/samsung/clk-exynos-audss.c |4 +- drivers/clk/samsung/clk-exynos4.c | 10 ++-- drivers/clk/samsung/clk-exynos5250.c |4 +- drivers/clk/samsung/clk.c |3 +- drivers/clk/samsung/clk.h | 17 --- drivers/clk/spear/spear1310_clock.c| 78 ++-- drivers/clk/spear/spear1340_clock.c| 47 ++- drivers/clk/spear/spear3xx_clock.c | 36 +++ drivers/clk/spear/spear6xx_clock.c | 20 drivers/clk/sunxi/clk-sunxi.c |2 +- drivers/clk/tegra/clk-tegra114.c | 24 +- drivers/clk/tegra/clk-tegra20.c|4 +- drivers/clk/tegra/clk-tegra30.c| 22 - drivers/clk/versatile/clk-vexpress.c |2 +- drivers/clk/zynq/clkc.c| 65 +- include/linux/clk-private.h| 19 include/linux/clk-provider.h | 10 ++-- 28 files changed, 338 insertions(+), 244 deletions(-) -- 1.7.9.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
[RFC Patch v2 1/3] clk: add support for temporary parent clock migration
Some platforms use to migrate temporarily to another parent during cpu frequency
scaling, e.g. Exynos and Tegra. Once the frequency is changed the latch on to
original parent.
The generic cpufreq-cpu0 driver use clk_set_rate API to scale cpu frequency.
This patch is an attempt to address the above mentioned requirement.
This is achieved as follows:
Add a clk flag "CLK_SET_RATE_TEMP_PARENT" for clocks which need to migrate to
another parent during set_rate operation on them.
Add "temp_parent_name" and "tmp_parent" fields to clk structure i.e the name of
temp_parent_clock and reference to temp_parent_clock.
Hence in clk_set_rate API check for the "CLK_SET_RATE_TEMP_PARENT" flag, then
latch on to alternate parent clock temporarily. Once the requested rate is set
on the clk, re-parent back to original parent clock.
Signed-off-by: Chander Kashyap
---
drivers/clk/clk-mux.c| 13 +++--
drivers/clk/clk.c| 43 --
include/linux/clk-private.h | 19 +++
include/linux/clk-provider.h | 10 ++
4 files changed, 65 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 4f96ff3..854b3ac 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -115,8 +115,8 @@ EXPORT_SYMBOL_GPL(clk_mux_ro_ops);
struct clk *clk_register_mux_table(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
- void __iomem *reg, u8 shift, u32 mask,
- u8 clk_mux_flags, u32 *table, spinlock_t *lock)
+ const char *temp_parent_name, void __iomem *reg, u8 shift,
+ u32 mask, u8 clk_mux_flags, u32 *table, spinlock_t *lock)
{
struct clk_mux *mux;
struct clk *clk;
@@ -146,6 +146,7 @@ struct clk *clk_register_mux_table(struct device *dev,
const char *name,
init.flags = flags | CLK_IS_BASIC;
init.parent_names = parent_names;
init.num_parents = num_parents;
+ init.temp_parent_name = temp_parent_name;
/* struct clk_mux assignments */
mux->reg = reg;
@@ -167,13 +168,13 @@ EXPORT_SYMBOL_GPL(clk_register_mux_table);
struct clk *clk_register_mux(struct device *dev, const char *name,
const char **parent_names, u8 num_parents, unsigned long flags,
- void __iomem *reg, u8 shift, u8 width,
- u8 clk_mux_flags, spinlock_t *lock)
+ const char *temp_parent_name, void __iomem *reg, u8 shift,
+ u8 width, u8 clk_mux_flags, spinlock_t *lock)
{
u32 mask = BIT(width) - 1;
return clk_register_mux_table(dev, name, parent_names, num_parents,
- flags, reg, shift, mask, clk_mux_flags,
- NULL, lock);
+ flags, temp_parent_name, reg, shift,
+ mask, clk_mux_flags, NULL, lock);
}
EXPORT_SYMBOL_GPL(clk_register_mux);
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2db08c0..0e29a5b 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1425,8 +1425,8 @@ static void clk_change_rate(struct clk *clk)
*/
int clk_set_rate(struct clk *clk, unsigned long rate)
{
- struct clk *top, *fail_clk;
- int ret = 0;
+ struct clk *top, *fail_clk, *parent = NULL;
+ int ret = 0, index;
if (!clk)
return 0;
@@ -1450,6 +1450,35 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
goto out;
}
+ /* Latch on to alternate parent temporarily if needed */
+ if ((clk->flags & CLK_SET_RATE_TEMP_PARENT) && clk->temp_parent_name) {
+ /* Save current parent before latching on to alternate parent */
+ parent = clk->parent;
+
+ if (!clk->temp_parent) {
+ for (index = 0; index < clk->num_parents; index++) {
+ if (!strcmp(clk->parent_names[index],
+ clk->temp_parent_name))
+ clk->temp_parent =
+ __clk_lookup(clk->temp_parent_name);
+ }
+
+ if (!clk->temp_parent) {
+ pr_warn("%s: wrong temp_parent_name %s",
+ __func__, clk->temp_parent_name);
+ ret = -EINVAL;
+ goto out;
+ }
+ }
+
+ ret = clk_set_parent(clk, clk->temp_parent);
+ if (ret) {
+ pr_warn("%s: failed to set %s parent\n",
+ __func__, clk->temp_parent->name);
+ goto out;
+ }
+ }
+
/* notify that we are about to change rates */
fail_clk =
Re: [PATCH] ARM: dts: Fix gpio pin of lcd_en node for exynos4210
On Tuesday, September 03, 2013 5:48 PM, Tushar Behera wrote:
> On 3 September 2013 13:03, Jingoo Han wrote:
> > On Tuesday, September 03, 2013 3:52 PM, Tushar Behera wrote:
> >> On 3 September 2013 07:44, Jingoo Han wrote:
> >> > According to datasheet, 'lcd_en' node should use gpf0-2,
> >> > instead of gpe3-4. gpe3-4 is used for MDM_DATA[4]; thus,
> >> > it should be fixed.
> >> >
> >> > Signed-off-by: Jingoo Han
> >> > ---
> >> > arch/arm/boot/dts/exynos4210-pinctrl.dtsi |2 +-
> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> >> > b/arch/arm/boot/dts/exynos4210-
> pinctrl.dtsi
> >> > index a7c2128..da5dd8d 100644
> >> > --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> >> > +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> >> > @@ -374,7 +374,7 @@
> >> > };
> >> >
> >> > lcd_en: lcd-en {
> >> > - samsung,pins = "gpe3-4";
> >> > + samsung,pins = "gpf0-2";
> >> > samsung,pin-function = <2>;
> >> > samsung,pin-pud = <0>;
> >> > samsung,pin-drv = <0>;
> >>
> >> With this change, the LCD display stops working on Origen board.
> >
> > The smdkv310 board worked properly.
> > gpe3-4 seems to be necessary for Origen board.
> > Can you describe why gpe3-4 is necessary for Origen board?
> >
>
> Without setting this pin, LCD panel doesn't power up. It is quite
> possible that this is Origen specific. In that case, how do you
> suggest to implement this for Origen board?
OK, I see.
'gpe3-4' on Origen board is used as LCD panel reset pin.
Then, it should be handled as reset-pin control for LCD panel.
Also, one this is clear.
'gpe3-4' should NOT be used as pin-function <2>, because
it means MDM_DATA[4]. MDM_DATA[4] is not related to LCD control.
It is a definitely wrong usage.
Best regards,
Jingoo Han
--
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: Fix gpio pin of lcd_en node for exynos4210
On 3 September 2013 13:03, Jingoo Han wrote:
> On Tuesday, September 03, 2013 3:52 PM, Tushar Behera wrote:
>> On 3 September 2013 07:44, Jingoo Han wrote:
>> > According to datasheet, 'lcd_en' node should use gpf0-2,
>> > instead of gpe3-4. gpe3-4 is used for MDM_DATA[4]; thus,
>> > it should be fixed.
>> >
>> > Signed-off-by: Jingoo Han
>> > ---
>> > arch/arm/boot/dts/exynos4210-pinctrl.dtsi |2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> > b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> > index a7c2128..da5dd8d 100644
>> > --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> > +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
>> > @@ -374,7 +374,7 @@
>> > };
>> >
>> > lcd_en: lcd-en {
>> > - samsung,pins = "gpe3-4";
>> > + samsung,pins = "gpf0-2";
>> > samsung,pin-function = <2>;
>> > samsung,pin-pud = <0>;
>> > samsung,pin-drv = <0>;
>>
>> With this change, the LCD display stops working on Origen board.
>
> The smdkv310 board worked properly.
> gpe3-4 seems to be necessary for Origen board.
> Can you describe why gpe3-4 is necessary for Origen board?
>
Without setting this pin, LCD panel doesn't power up. It is quite
possible that this is Origen specific. In that case, how do you
suggest to implement this for Origen board?
> According to the datasheet, pin-function of gpe3-4 is defined
> as MDM_DATA[4]. So, the node name 'lcd_en' is wrong or confusing.
>
>>
>> gpf0-{0,1,2,3} are defined under lcd_clk.
>
> Then will you test the following on Origen board?
>
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -293,7 +293,7 @@
> };
>
> fimd@11c0 {
> - pinctrl-0 = <&lcd_en &lcd_clk &lcd_data24 &pwm0_out>;
> + pinctrl-0 = <&lcd_clk &lcd_data24 &pwm0_out>;
>
No, this doesn't work on Origen.
--
Tushar Behera
--
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 0/4] exynos dwmmc device tree node cleanup
Hi Yuvaraj, On Tuesday 03 of September 2013 11:34:20 Yuvaraj Kumar C D wrote: > changes from V3: > 1.Added two new patch in the series > [1] ARM: dts: Move fifo-depth property from board dts > [2] ARM: dts: rename mmc dts node for exynos5 series > changes from V2: > 1.remove from exynos5.dtsi and add in exynos5250.dtsi > in single patch.Suggested by Tomasz Figa. > 2.Separate patch for changing status property of dwmmc node > in smdk5250 and arndale board dts file. > > V1 Patches: > 1.[PATCH 1/2] ARM: dts: remove dwmmc nodes from exynos5 common dts file. > http://www.spinics.net/lists/linux-samsung-soc/msg21602.html > 2.[PATCH 2/2] ARM: dts: Add dwmmc nodes in SOC specific dts file > http://www.spinics.net/lists/linux-samsung-soc/msg21603.html > > Yuvaraj Kumar C D (4): > ARM: dts: Move dwmmc nodes from exynos5.dtsi to exynos5250.dtsi > ARM: dts: exynos: change status property of dwmmc nodes > ARM: dts: Move fifo-depth property from board dts > ARM: dts: rename mmc dts node for exynos5 series > > arch/arm/boot/dts/cros5250-common.dtsi|8 +++ > arch/arm/boot/dts/exynos5.dtsi| 21 - > arch/arm/boot/dts/exynos5250-arndale.dts | 16 - > arch/arm/boot/dts/exynos5250-smdk5250.dts | 16 - > arch/arm/boot/dts/exynos5250-snow.dts |2 +- > arch/arm/boot/dts/exynos5250.dtsi | 36 > ++--- 6 files changed, 41 insertions(+), 58 > deletions(-) Reviewed-by: Tomasz Figa Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Fix gpio pin of lcd_en node for exynos4210
On Tuesday, September 03, 2013 3:52 PM, Tushar Behera wrote:
> On 3 September 2013 07:44, Jingoo Han wrote:
> > According to datasheet, 'lcd_en' node should use gpf0-2,
> > instead of gpe3-4. gpe3-4 is used for MDM_DATA[4]; thus,
> > it should be fixed.
> >
> > Signed-off-by: Jingoo Han
> > ---
> > arch/arm/boot/dts/exynos4210-pinctrl.dtsi |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> > b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> > index a7c2128..da5dd8d 100644
> > --- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> > +++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
> > @@ -374,7 +374,7 @@
> > };
> >
> > lcd_en: lcd-en {
> > - samsung,pins = "gpe3-4";
> > + samsung,pins = "gpf0-2";
> > samsung,pin-function = <2>;
> > samsung,pin-pud = <0>;
> > samsung,pin-drv = <0>;
>
> With this change, the LCD display stops working on Origen board.
The smdkv310 board worked properly.
gpe3-4 seems to be necessary for Origen board.
Can you describe why gpe3-4 is necessary for Origen board?
According to the datasheet, pin-function of gpe3-4 is defined
as MDM_DATA[4]. So, the node name 'lcd_en' is wrong or confusing.
>
> gpf0-{0,1,2,3} are defined under lcd_clk.
Then will you test the following on Origen board?
+++ b/arch/arm/boot/dts/exynos4210-origen.dts
@@ -293,7 +293,7 @@
};
fimd@11c0 {
- pinctrl-0 = <&lcd_en &lcd_clk &lcd_data24 &pwm0_out>;
+ pinctrl-0 = <&lcd_clk &lcd_data24 &pwm0_out>;
Best regards,
Jingoo Han
--
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
