Re: [RFC Patch v2 0/3] add temporary parent migration support
On 4 September 2013 04:06, Tomasz Figa tomasz.f...@gmail.com 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: [RFC Patch v2 1/3] clk: add support for temporary parent clock migration
On 4 September 2013 03:17, Sylwester Nawrocki
sylvester.nawro...@gmail.com 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 Kashyapchander.kash...@linaro.org
---
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;
[...]
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
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma rahul.sha...@samsung.com
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 rahul.sha...@samsung.com
---
.../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 linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -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,
- },
- },
- {
-
Re: [PATCH v11 0/8] PHY framework
On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: 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. Alright, 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: 3.12 merge window exynos cpufreq driver fails to build
Hi Josh, On Wednesday 04 of September 2013 10:13:16 Josh Boyer wrote: Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the exynos-cpufreq driver doesn't build because it includes a file that doesn't exist. + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] #warning TODO: return_address should use unwind tables ^ arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA allocator does not (yet) support huge TLB [-Wcpp] #warning ARM Coherent DMA allocator does not (yet) support huge TLB ^ drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No such file or directory #include plat/cpu.h ^ compilation terminated. make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 I'm guessing that plat/cpu.h file is supposed to come from arch/arm/plat-samsung/include/plat/, but I don't see anything that specifies a -I there. Thoughts? Could you attach config that could be used to trigger this? Thanks in advance. 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 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma rahul.sha...@samsung.com
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 rahul.sha...@samsung.com
---
.../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 linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -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,
Re: 3.12 merge window exynos cpufreq driver fails to build
On Wednesday 04 of September 2013 10:41:31 Josh Boyer wrote: On Wed, Sep 4, 2013 at 10:36 AM, Tomasz Figa t.f...@samsung.com wrote: Hi Josh, On Wednesday 04 of September 2013 10:13:16 Josh Boyer wrote: Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the exynos-cpufreq driver doesn't build because it includes a file that doesn't exist. + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] #warning TODO: return_address should use unwind tables ^ arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA allocator does not (yet) support huge TLB [-Wcpp] #warning ARM Coherent DMA allocator does not (yet) support huge TLB ^ drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No such file or directory #include plat/cpu.h ^ compilation terminated. make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 I'm guessing that plat/cpu.h file is supposed to come from arch/arm/plat-samsung/include/plat/, but I don't see anything that specifies a -I there. Thoughts? Could you attach config that could be used to trigger this? Thanks in advance. Attached. Hmm, this does not look like config for kernel neither from Linus' nor linux-next tree. The first thing I can see is CONFIG_ARCH_EXYNOS_MULTI selected, which is not available in any mainline tree. As for the build error itself, headers from plat/ are available for drivers only in single platform builds, they can't be included when multiplatform is enabled. The exynos-cpufreq driver is not multiplatform-aware yet and so you get the failure. 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: 3.12 merge window exynos cpufreq driver fails to build
On Wed, Sep 4, 2013 at 11:04 AM, Tomasz Figa t.f...@samsung.com wrote: On Wednesday 04 of September 2013 10:41:31 Josh Boyer wrote: On Wed, Sep 4, 2013 at 10:36 AM, Tomasz Figa t.f...@samsung.com wrote: Hi Josh, On Wednesday 04 of September 2013 10:13:16 Josh Boyer wrote: Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the exynos-cpufreq driver doesn't build because it includes a file that doesn't exist. + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] #warning TODO: return_address should use unwind tables ^ arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA allocator does not (yet) support huge TLB [-Wcpp] #warning ARM Coherent DMA allocator does not (yet) support huge TLB ^ drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No such file or directory #include plat/cpu.h ^ compilation terminated. make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 I'm guessing that plat/cpu.h file is supposed to come from arch/arm/plat-samsung/include/plat/, but I don't see anything that specifies a -I there. Thoughts? Could you attach config that could be used to trigger this? Thanks in advance. Attached. Hmm, this does not look like config for kernel neither from Linus' nor linux-next tree. The first thing I can see is CONFIG_ARCH_EXYNOS_MULTI selected, which is not available in any mainline tree. Sigh. Yes, I see the issue now. As for the build error itself, headers from plat/ are available for drivers only in single platform builds, they can't be included when multiplatform is enabled. The exynos-cpufreq driver is not multiplatform-aware yet and so you get the failure. Someone added some exynos multiplatform patches to the Fedora kernel. That seems to have caused these build failures. Our mistake and my apologies for the inconvenience. Thank you for the quick response. josh -- 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
3.12 merge window exynos cpufreq driver fails to build
Using Linus' tree as of this morning (v3.11-2654-g458c3f6), the exynos-cpufreq driver doesn't build because it includes a file that doesn't exist. + make -s ARCH=arm V=1 -j4 bzImage KALLSYMS_EXTRA_PASS=1 arch/arm/kernel/return_address.c:63:2: warning: #warning TODO: return_address should use unwind tables [-Wcpp] #warning TODO: return_address should use unwind tables ^ arch/arm/mm/dma-mapping.c:253:2: warning: #warning ARM Coherent DMA allocator does not (yet) support huge TLB [-Wcpp] #warning ARM Coherent DMA allocator does not (yet) support huge TLB ^ drivers/cpufreq/exynos-cpufreq.c:21:22: fatal error: plat/cpu.h: No such file or directory #include plat/cpu.h ^ compilation terminated. make[2]: *** [drivers/cpufreq/exynos-cpufreq.o] Error 1 I'm guessing that plat/cpu.h file is supposed to come from arch/arm/plat-samsung/include/plat/, but I don't see anything that specifies a -I there. Thoughts? josh -- 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
On Wed, Sep 4, 2013 at 1:47 AM, Rahul Sharma r.sh.o...@gmail.com wrote:
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma rahul.sha...@samsung.com
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 rahul.sha...@samsung.com
---
.../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 linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -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,
Re: [RFC Patch v2 0/3] add temporary parent migration support
Quoting Tomasz Figa (2013-09-03 15:36:50) 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. I agree with Tomasz. 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. Creating a custom clock type is the way to go here. It is possible to wrap the mux clk_ops to re-use that code, or just write a custom clock type from scratch. I do not like using the clock rate-change notifiers for this purpose. The notifiers provide hooks to drivers that need to take care around clock transitions. Using the notifiers from within the clock framework indicates poor design. 2) Using normal mux clock, but registering such notifiers in clock controller or cpufreq driver. This depends on what the data sheet or reference manual states. If using a temporary parent is a property of the clock programming sequence (e.g. to have a glitch-less transition) then that logic belongs in the clock provider driver (i.e. a custom clock type needs to be created with this logic). However if using a temporary parent is not required for programming the clock, but is instead a requirement of the clock consumer (e.g. a CPU, or some I/O controller) then perhaps putting this logic in that driver is the right way to go. In that case the logic could be explicit: clk_set_parent(clk, temp_parent); clk_set_rate(clk, target_rate); clk_set_parent(clk, target_parent); Or it could implicit with the use of rate-change notifiers. Again the rate-change notifiers exist for clock consumer drivers to use, so this is OK. I have a hunch that the right way to do this is for a custom clock type to be created which simply calls clk_set_parent from within the clock's .set_rate callback, but I'll wait on feedback from Chander on the needs of his platform. Regards, Mike 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 0/3] add temporary parent migration support
On Wednesday 04 of September 2013 10:43:28 Mike Turquette wrote: Quoting Tomasz Figa (2013-09-03 15:36:50) 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. I agree with Tomasz. 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. Creating a custom clock type is the way to go here. It is possible to wrap the mux clk_ops to re-use that code, or just write a custom clock type from scratch. I do not like using the clock rate-change notifiers for this purpose. The notifiers provide hooks to drivers that need to take care around clock transitions. Using the notifiers from within the clock framework indicates poor design. I was not sure how a .set_parent() from inside a .set_rate() would interact with rate setting, so I mentioned notifiers here, but now as I think of it, CCF is supposed to be re-entrant, so things should be fine. 2) Using normal mux clock, but registering such notifiers in clock controller or cpufreq driver. This depends on what the data sheet or reference manual states. If using a temporary parent is a property of the clock programming sequence (e.g. to have a glitch-less transition) then that logic belongs in the clock provider driver (i.e. a custom clock type needs to be created with this logic). However if using a temporary parent is not required for programming the clock, but is instead a requirement of the clock consumer (e.g. a CPU, or some I/O controller) then perhaps putting this logic in that driver is the right way to go. In that case the logic could be explicit: clk_set_parent(clk, temp_parent); clk_set_rate(clk, target_rate); clk_set_parent(clk, target_parent); Or it could implicit with the use of rate-change notifiers. Again the rate-change notifiers exist for clock consumer drivers to use, so this is OK. I have a hunch that the right way to do this is for a custom clock type to be created which simply calls clk_set_parent from within the clock's .set_rate callback, but I'll wait on feedback from Chander on the needs of his platform. I believe Chander has exactly the same use case for this as we have for Exynos 4210 and 4x12. On these SoCs, CPU frequency is being scaled by reconfiguring PLL, which needs to be masked for locking time. To let the CPU operate normally, a mux that allows switching CPU clock domain between two PLLs can be switched to the other PLL (MPLL) until the main ARM PLL (APLL) starts operating again. However this issue is not limited to clocks, because there must be also a voltage transition involved if the utility PLL has frequency higher than the one currently being reconfigured. 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 V3 2/4] mmc: dw_mmc: socfpga: move socfpga private init
On Thu, 2013-08-29 at 20:59 +0900, Seungwon Jeon wrote:
On Wed, August 28, 2013, Yuvaraj Kumar C D wrote:
Currently platform specific private data initialisation is done by
dw_mci_socfpga_priv_init and dw_mci_socfpga_parse_dt.As we already have
separate platform specific device tree parser dw_mci_socfpga_parse_dt,
move the dw_mci_socfpga_priv_init code to dw_mci_socfpga_parse_dt.
We can use the dw_mci_socfpga_priv_init to do some actual platform
specific initialisation.
I am looking to remove all of dw_mmc-socfpga file. The only reason for
this file is to set the sdr timing values. But since the register that
controls these SDR values are located out of the IP, it is probably best
to implement the settings in platform specific code.
Dinh
This patch is compile tested only.
CC'ed Dinh Nguyen
Thanks,
Seungwon Jeon
changes since V2: none
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc-socfpga.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-socfpga.c
b/drivers/mmc/host/dw_mmc-socfpga.c
index 14b5961..953f260 100644
--- a/drivers/mmc/host/dw_mmc-socfpga.c
+++ b/drivers/mmc/host/dw_mmc-socfpga.c
@@ -38,20 +38,6 @@ struct dw_mci_socfpga_priv_data {
static int dw_mci_socfpga_priv_init(struct dw_mci *host)
{
- struct dw_mci_socfpga_priv_data *priv;
-
- priv = devm_kzalloc(host-dev, sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- dev_err(host-dev, mem alloc failed for private data\n);
- return -ENOMEM;
- }
-
- priv-sysreg = syscon_regmap_lookup_by_compatible(altr,sys-mgr);
- if (IS_ERR(priv-sysreg)) {
- dev_err(host-dev, regmap for altr,sys-mgr lookup failed.\n);
- return PTR_ERR(priv-sysreg);
- }
- host-priv = priv;
return 0;
}
@@ -79,12 +65,24 @@ static void dw_mci_socfpga_prepare_command(struct
dw_mci *host, u32 *cmdr)
static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
{
- struct dw_mci_socfpga_priv_data *priv = host-priv;
+ struct dw_mci_socfpga_priv_data *priv;
struct device_node *np = host-dev-of_node;
u32 timing[2];
u32 div = 0;
int ret;
+ priv = devm_kzalloc(host-dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(host-dev, mem alloc failed for private data\n);
+ return -ENOMEM;
+ }
+
+ priv-sysreg = syscon_regmap_lookup_by_compatible(altr,sys-mgr);
+ if (IS_ERR(priv-sysreg)) {
+ dev_err(host-dev, regmap for altr,sys-mgr lookup failed.\n);
+ return PTR_ERR(priv-sysreg);
+ }
+
ret = of_property_read_u32(np, altr,dw-mshc-ciu-div, div);
if (ret)
dev_info(host-dev, No dw-mshc-ciu-div specified, assuming 1);
@@ -96,6 +94,7 @@ static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
return ret;
priv-hs_timing = SYSMGR_SDMMC_CTRL_SET(timing[0], timing[1]);
+ host-priv = priv;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] ARM: S3C24XX: add dmaengine based dma-driver
This series tries to provide a basic dmaengine driver for the s3c24xx SoCs to subsequently retire the old one with custom API. Since v3 more smaller fixes were added, and memcpy operations now have a very simple mechanism to try to use higher transfer widths. Since v2 only some small fixes to the dma driver itself were added. Since v1 three big changes happened (appart from fixing received comments): For one the limitation of sg-lists to 1 element is gone.Secondly the specifics of the virtual channels (target bus, handshake, etc) are not encoded with channel ids but in the platformdata - making a later dt binding easier, as these informations can there be gathered by the xlate function. And lastly I also added a preliminary mechanism to handle the specific needs for the earlier variants of the driver. While s3c2443 and later can use any channel for any peripheral with just marking the target-peripheral-id in a register, earlier SoCs can only use specific channels and the target-ids also vary depending on the channel. Therefore on newer SoCs the chansel element only needs to contain the requested target-id, while on the older variants use it to encode both the valid channels and the channel-specific peripheral-id. On affected SoCs the target-id is always 3 bit wide, so we use these and an additional 4th bit to hold the valid state. As the older SoCs all have 4 dma channels this can live happily in an u16 element. The s3c24xx series will most likely not see any new offspring, but even if it happens any new model will probably use the newer more flexible variant of the dma controller, so this should not restrict anything in the future. Example: SDI is valid on channels 0, 2 and 3 - with varying hw request sources. For it the chansel field would look like ((BIT(3) | 1) 3 * 4) | // channel 3, with request source 1 ((BIT(3) | 2) 2 * 4) | // channel 2, with request source 2 ((BIT(3) | 2) 0 * 4) // channel 0, with request source 2 Heiko Stuebner (4): ARM: S3C24XX: number the dma clocks dmaengine: add driver for Samsung s3c24xx SoCs ARM: S3C24XX: add platform-devices for new dma driver for s3c2412 and s3c2443 ARM: SAMSUNG: set s3c24xx_dma_filter for s3c64xx-spi0 device arch/arm/mach-s3c24xx/clock-s3c2412.c |8 +- arch/arm/mach-s3c24xx/common-s3c2443.c| 12 +- arch/arm/mach-s3c24xx/common.c| 106 +++ arch/arm/mach-s3c24xx/common.h|3 + arch/arm/mach-s3c24xx/mach-jive.c |1 + arch/arm/mach-s3c24xx/mach-smdk2413.c |1 + arch/arm/mach-s3c24xx/mach-smdk2416.c |1 + arch/arm/mach-s3c24xx/mach-smdk2443.c |1 + arch/arm/mach-s3c24xx/mach-vstms.c|1 + arch/arm/plat-samsung/devs.c |5 +- drivers/dma/Kconfig | 12 + drivers/dma/Makefile |1 + drivers/dma/s3c24xx-dma.c | 1340 + include/linux/platform_data/dma-s3c24xx.h | 43 + 14 files changed, 1524 insertions(+), 11 deletions(-) create mode 100644 drivers/dma/s3c24xx-dma.c create mode 100644 include/linux/platform_data/dma-s3c24xx.h -- 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
[PATCH v4 2/4] dmaengine: add driver for Samsung s3c24xx SoCs
This adds a new driver to support the s3c24xx dma using the dmaengine and makes the old one in mach-s3c24xx obsolete in the long run. Conceptually the s3c24xx-dma feels like a distant relative of the pl08x with numerous virtual channels being mapped to a lot less physical ones. The driver therefore borrows a lot from the amba-pl08x driver in this regard. Functionality-wise the driver gains a memcpy ability in addition to the slave_sg one. The driver supports both the method for requesting the peripheral used by SoCs before the S3C2443 and the different method for S3C2443 and later. On earlier SoCs the hardware channels usable for specific peripherals is constrainted while on later SoCs all channels can be used for any peripheral. Tested on a s3c2416-based board, memcpy using the dmatest module and slave_sg partially using the spi-s3c64xx driver. Signed-off-by: Heiko Stuebner he...@sntech.de Acked-by: Linus Walleij linus.wall...@linaro.org --- changes since v3: - address comments from Tomasz Figa: - fixed a lot of nitpics - and added a rudimentary mechanism to select higher bus-widths for memcpy - address more comments from Vinod Koul - reorder dma_control contents changes since v2: - add missing channel validation in s3c24xx_dma_phy_free when repurposing a physical channel for another virtual channel - address comments from Vinod Koul: - fix naming of constants to prevent conflicts - better handle the unlikely case of an interrupt happening on an unused channel changes since v1: - address comments from Linus Walleij - support sg-lists with more than 1 element - add support for earlier s3c24xx SoCs - redo the channeldata definitions: - no need for static ids for the virtual channels - provide a way to encode constraints for earlier variants - better base for later dt bindings drivers/dma/Kconfig | 12 + drivers/dma/Makefile |1 + drivers/dma/s3c24xx-dma.c | 1340 + include/linux/platform_data/dma-s3c24xx.h | 43 + 4 files changed, 1396 insertions(+) create mode 100644 drivers/dma/s3c24xx-dma.c create mode 100644 include/linux/platform_data/dma-s3c24xx.h diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 526ec77..d639115 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -154,6 +154,18 @@ config TEGRA20_APB_DMA This DMA controller transfers data from memory to peripheral fifo or vice versa. It does not support memory to memory data transfer. +config S3C24XX_DMAC + tristate Samsung S3C24XX DMA support + depends on ARCH_S3C24XX !S3C24XX_DMA + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + help + Support for the Samsung S3C24XX DMA controller driver. The + DMA controller is having multiple DMA channels which can be + configured for different peripherals like audio, UART, SPI. + The DMA controller can transfer data from memory to peripheral, + periphal to memory, periphal to periphal and memory to memory. + source drivers/dma/sh/Kconfig config COH901318 diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index cb5a77a..afd1b14 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_SIRF_DMA) += sirf-dma.o obj-$(CONFIG_TI_EDMA) += edma.o obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o +obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o obj-$(CONFIG_PL330_DMA) += pl330.o obj-$(CONFIG_PCH_DMA) += pch_dma.o obj-$(CONFIG_AMBA_PL08X) += amba-pl08x.o diff --git a/drivers/dma/s3c24xx-dma.c b/drivers/dma/s3c24xx-dma.c new file mode 100644 index 000..d56a5ef --- /dev/null +++ b/drivers/dma/s3c24xx-dma.c @@ -0,0 +1,1340 @@ +/* + * S3C24XX DMA handling + * + * Copyright (c) 2013 Heiko Stuebner he...@sntech.de + * + * based on amba-pl08x.c + * + * Copyright (c) 2006 ARM Ltd. + * Copyright (c) 2010 ST-Ericsson SA + * + * Author: Peter Pearse peter.pea...@arm.com + * Author: Linus Walleij linus.wall...@stericsson.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. + * + * The DMA controllers in S3C24XX SoCs have a varying number of DMA signals + * that can be routed to any of the 4 to 8 hardware-channels. + * + * Therefore on these DMA controllers the number of channels + * and the number of incoming DMA signals are two totally different things. + * It is usually not possible to theoretically handle all physical signals, + * so a multiplexing scheme with possible denial of use is necessary. + * + * Open items: + * - bursts + */ + +#include linux/platform_device.h +#include linux/types.h +#include linux/dmaengine.h +#include linux/dma-mapping.h +#include linux/interrupt.h
[PATCH v4 1/4] ARM: S3C24XX: number the dma clocks
Each dma channel has its own clock. The upcoming dma driver wants to
handle these itself and therefore needs to be able to get the correct
clock for a channel.
Therefore rename the dma clocks to dma.X for s3c2412, s3c2416 and
s3c2443. This does not change the behaviour for the old dma driver at
all, as all dma clocks are still always on and not handled by the old
dma driver at all.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
changes since v2:
- remove noise from commit message
arch/arm/mach-s3c24xx/clock-s3c2412.c |8
arch/arm/mach-s3c24xx/common-s3c2443.c | 12 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-s3c24xx/clock-s3c2412.c
b/arch/arm/mach-s3c24xx/clock-s3c2412.c
index d8f253f..11b3b28 100644
--- a/arch/arm/mach-s3c24xx/clock-s3c2412.c
+++ b/arch/arm/mach-s3c24xx/clock-s3c2412.c
@@ -484,22 +484,22 @@ static struct clk init_clocks_disable[] = {
static struct clk init_clocks[] = {
{
- .name = dma,
+ .name = dma.0,
.parent = clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA0,
}, {
- .name = dma,
+ .name = dma.1,
.parent = clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA1,
}, {
- .name = dma,
+ .name = dma.2,
.parent = clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA2,
}, {
- .name = dma,
+ .name = dma.3,
.parent = clk_h,
.enable = s3c2412_clkcon_enable,
.ctrlbit= S3C2412_CLKCON_DMA3,
diff --git a/arch/arm/mach-s3c24xx/common-s3c2443.c
b/arch/arm/mach-s3c24xx/common-s3c2443.c
index f6b9f2e..65d3eef 100644
--- a/arch/arm/mach-s3c24xx/common-s3c2443.c
+++ b/arch/arm/mach-s3c24xx/common-s3c2443.c
@@ -438,32 +438,32 @@ static struct clk init_clocks_off[] = {
static struct clk init_clocks[] = {
{
- .name = dma,
+ .name = dma.0,
.parent = clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA0,
}, {
- .name = dma,
+ .name = dma.1,
.parent = clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA1,
}, {
- .name = dma,
+ .name = dma.2,
.parent = clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA2,
}, {
- .name = dma,
+ .name = dma.3,
.parent = clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA3,
}, {
- .name = dma,
+ .name = dma.4,
.parent = clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA4,
}, {
- .name = dma,
+ .name = dma.5,
.parent = clk_h,
.enable = s3c2443_clkcon_enable_h,
.ctrlbit= S3C2443_HCLKCON_DMA5,
--
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
[PATCH v4 3/4] ARM: S3C24XX: add platform-devices for new dma driver for s3c2412 and s3c2443
This includes defining the mapping for the request sources.
Signed-off-by: Heiko Stuebner he...@sntech.de
Acked-by: Linus Walleij linus.wall...@linaro.org
---
changes since v1:
- follow new pdata definition
arch/arm/mach-s3c24xx/common.c| 106 +
arch/arm/mach-s3c24xx/common.h|3 +
arch/arm/mach-s3c24xx/mach-jive.c |1 +
arch/arm/mach-s3c24xx/mach-smdk2413.c |1 +
arch/arm/mach-s3c24xx/mach-smdk2416.c |1 +
arch/arm/mach-s3c24xx/mach-smdk2443.c |1 +
arch/arm/mach-s3c24xx/mach-vstms.c|1 +
7 files changed, 114 insertions(+)
diff --git a/arch/arm/mach-s3c24xx/common.c b/arch/arm/mach-s3c24xx/common.c
index 457261c..16ac669 100644
--- a/arch/arm/mach-s3c24xx/common.c
+++ b/arch/arm/mach-s3c24xx/common.c
@@ -31,6 +31,7 @@
#include linux/platform_device.h
#include linux/delay.h
#include linux/io.h
+#include linux/platform_data/dma-s3c24xx.h
#include mach/hardware.h
#include mach/regs-clock.h
@@ -44,6 +45,7 @@
#include mach/regs-gpio.h
#include plat/regs-serial.h
+#include mach/dma.h
#include plat/cpu.h
#include plat/devs.h
@@ -329,3 +331,107 @@ void __init_or_cpufreq s3c24xx_setup_clocks(unsigned long
fclk,
clk_p.rate = pclk;
clk_f.rate = fclk;
}
+
+#if defined(CONFIG_CPU_S3C2410) || defined(CONFIG_CPU_S3C2412) || \
+defined(CONFIG_CPU_S3C2440) || defined(CONFIG_CPU_S3C2442)
+static struct resource s3c2410_dma_resource[] = {
+ [0] = DEFINE_RES_MEM(S3C24XX_PA_DMA, S3C24XX_SZ_DMA),
+ [1] = DEFINE_RES_IRQ(IRQ_DMA0),
+ [2] = DEFINE_RES_IRQ(IRQ_DMA1),
+ [3] = DEFINE_RES_IRQ(IRQ_DMA2),
+ [4] = DEFINE_RES_IRQ(IRQ_DMA3),
+};
+#endif
+
+#ifdef CONFIG_CPU_S3C2412
+static struct s3c24xx_dma_channel s3c2412_dma_channels[DMACH_MAX] = {
+ [DMACH_XD0] = { S3C24XX_DMA_AHB, true, 17 },
+ [DMACH_XD1] = { S3C24XX_DMA_AHB, true, 18 },
+ [DMACH_SDI] = { S3C24XX_DMA_APB, false, 10 },
+ [DMACH_SPI0_RX] = { S3C24XX_DMA_APB, true, 1 },
+ [DMACH_SPI0_TX] = { S3C24XX_DMA_APB, true, 0 },
+ [DMACH_SPI1_RX] = { S3C24XX_DMA_APB, true, 3 },
+ [DMACH_SPI1_TX] = { S3C24XX_DMA_APB, true, 2 },
+ [DMACH_UART0] = { S3C24XX_DMA_APB, true, 19 },
+ [DMACH_UART1] = { S3C24XX_DMA_APB, true, 21 },
+ [DMACH_UART2] = { S3C24XX_DMA_APB, true, 23 },
+ [DMACH_UART0_SRC2] = { S3C24XX_DMA_APB, true, 20 },
+ [DMACH_UART1_SRC2] = { S3C24XX_DMA_APB, true, 22 },
+ [DMACH_UART2_SRC2] = { S3C24XX_DMA_APB, true, 24 },
+ [DMACH_TIMER] = { S3C24XX_DMA_APB, true, 9 },
+ [DMACH_I2S_IN] = { S3C24XX_DMA_APB, true, 5 },
+ [DMACH_I2S_OUT] = { S3C24XX_DMA_APB, true, 4 },
+ [DMACH_USB_EP1] = { S3C24XX_DMA_APB, true, 13 },
+ [DMACH_USB_EP2] = { S3C24XX_DMA_APB, true, 14 },
+ [DMACH_USB_EP3] = { S3C24XX_DMA_APB, true, 15 },
+ [DMACH_USB_EP4] = { S3C24XX_DMA_APB, true, 16 },
+};
+
+static struct s3c24xx_dma_platdata s3c2412_dma_platdata = {
+ .num_phy_channels = 4,
+ .channels = s3c2412_dma_channels,
+ .num_channels = DMACH_MAX,
+};
+
+struct platform_device s3c2412_device_dma = {
+ .name = s3c2412-dma,
+ .id = 0,
+ .num_resources = ARRAY_SIZE(s3c2410_dma_resource),
+ .resource = s3c2410_dma_resource,
+ .dev= {
+ .platform_data = s3c2412_dma_platdata,
+ },
+};
+#endif
+
+#if defined(CONFIG_CPUS_3C2443) || defined(CONFIG_CPU_S3C2416)
+static struct resource s3c2443_dma_resource[] = {
+ [0] = DEFINE_RES_MEM(S3C24XX_PA_DMA, S3C24XX_SZ_DMA),
+ [1] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA0),
+ [2] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA1),
+ [3] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA2),
+ [4] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA3),
+ [5] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA4),
+ [6] = DEFINE_RES_IRQ(IRQ_S3C2443_DMA5),
+};
+
+static struct s3c24xx_dma_channel s3c2443_dma_channels[DMACH_MAX] = {
+ [DMACH_XD0] = { S3C24XX_DMA_AHB, true, 17 },
+ [DMACH_XD1] = { S3C24XX_DMA_AHB, true, 18 },
+ [DMACH_SDI] = { S3C24XX_DMA_APB, false, 10 },
+ [DMACH_SPI0_RX] = { S3C24XX_DMA_APB, true, 1 },
+ [DMACH_SPI0_TX] = { S3C24XX_DMA_APB, true, 0 },
+ [DMACH_SPI1_RX] = { S3C24XX_DMA_APB, true, 3 },
+ [DMACH_SPI1_TX] = { S3C24XX_DMA_APB, true, 2 },
+ [DMACH_UART0] = { S3C24XX_DMA_APB, true, 19 },
+ [DMACH_UART1] = { S3C24XX_DMA_APB, true, 21 },
+ [DMACH_UART2] = { S3C24XX_DMA_APB, true, 23 },
+ [DMACH_UART3] = { S3C24XX_DMA_APB, true, 25 },
+ [DMACH_UART0_SRC2] = { S3C24XX_DMA_APB, true, 20 },
+ [DMACH_UART1_SRC2] = { S3C24XX_DMA_APB, true, 22 },
+ [DMACH_UART2_SRC2] = { S3C24XX_DMA_APB, true, 24 },
+ [DMACH_UART3_SRC2] = { S3C24XX_DMA_APB, true, 26 },
+ [DMACH_TIMER] = { S3C24XX_DMA_APB, true, 9 },
+ [DMACH_I2S_IN] = { S3C24XX_DMA_APB, true, 5 },
+ [DMACH_I2S_OUT] = { S3C24XX_DMA_APB, true, 4 },
+ [DMACH_PCM_IN]
[PATCH v4 4/4] ARM: SAMSUNG: set s3c24xx_dma_filter for s3c64xx-spi0 device
The spi-s3c64xx device is also used on the s3c2416 and s3c2443 SoCs. The driver also already uses only generic dma-engine operations. Therefore add another elif to set the s3c24xx filter. Signed-off-by: Heiko Stuebner he...@sntech.de Acked-by: Linus Walleij linus.wall...@linaro.org --- arch/arm/plat-samsung/devs.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c index 8ce0ac0..a7b9b9e 100644 --- a/arch/arm/plat-samsung/devs.c +++ b/arch/arm/plat-samsung/devs.c @@ -32,6 +32,7 @@ #include linux/ioport.h #include linux/platform_data/s3c-hsudc.h #include linux/platform_data/s3c-hsotg.h +#include linux/platform_data/dma-s3c24xx.h #include media/s5p_hdmi.h @@ -1499,8 +1500,10 @@ void __init s3c64xx_spi0_set_platdata(int (*cfg_gpio)(void), int src_clk_nr, pd.num_cs = num_cs; pd.src_clk_nr = src_clk_nr; pd.cfg_gpio = (cfg_gpio) ? cfg_gpio : s3c64xx_spi0_cfg_gpio; -#ifdef CONFIG_PL330_DMA +#if defined(CONFIG_PL330_DMA) pd.filter = pl330_filter; +#elif defined(CONFIG_S3C24XX_DMAC) + pd.filter = s3c24xx_dma_filter; #endif s3c_set_platdata(pd, sizeof(pd), s3c64xx_device_spi0); -- 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 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Sean Paul
Sent: Wednesday, September 04, 2013 11:52 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
rahul.sha...@samsung.com
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 rahul.sha...@samsung.com
---
.../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 linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -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
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 5 September 2013 09:46, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Sean Paul
Sent: Wednesday, September 04, 2013 11:52 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
rahul.sha...@samsung.com
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 rahul.sha...@samsung.com
---
.../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 linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -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 @@
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
+static struct hdmiphy_config hdmiphy_4210_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, 0xef, 0xF3, 0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to push
these
into dt (https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy setting
is same as the current board. But if changed, you need to confirm with
measurement of signals, because it may vary slightly by resistance of
board pattern
Right. it seems that the phy configuration should be adjusted according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-board
basis.
In the 5420 datasheet, there are a few register descriptions available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
In that case, we need to test the phy confs for all the exynos boards,
supported in
mainline. Probably needs a analyser as well to precisely compare the
deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards, and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards be
added to their board dts files? Is the above analyzer really needed?
Shirish patch is only for 5420 Peach board. Else, to start with we can
mark
phyconf as optional property which overrides the default Phy Confs for
given SoC.
Hm you mean that hdmiphy driver use the default phy config data in
driver; most boards use the same data, and only in special case; a board
uses different OSC clock rate, the hdmiphy driver use phy config data from
dts file checking hdmiphy-confs property?
regards,
Rahul Sharma.
Sean
--
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 V3 2/4] mmc: dw_mmc: socfpga: move socfpga private init
On Thu, Sep 5, 2013 at 1:01 AM, Dinh Nguyen dingu...@altera.com wrote:
On Thu, 2013-08-29 at 20:59 +0900, Seungwon Jeon wrote:
On Wed, August 28, 2013, Yuvaraj Kumar C D wrote:
Currently platform specific private data initialisation is done by
dw_mci_socfpga_priv_init and dw_mci_socfpga_parse_dt.As we already have
separate platform specific device tree parser dw_mci_socfpga_parse_dt,
move the dw_mci_socfpga_priv_init code to dw_mci_socfpga_parse_dt.
We can use the dw_mci_socfpga_priv_init to do some actual platform
specific initialisation.
I am looking to remove all of dw_mmc-socfpga file. The only reason for
this file is to set the sdr timing values. But since the register that
controls these SDR values are located out of the IP, it is probably best
to implement the settings in platform specific code.
Well,This patch is included in this series becuase PATCHV4 3/4 of this
sereis will affect
dw_mmc-socfpga driver. However, if you are planning to remove the
whole file,still you can do
on top of this patch. :)
Dinh
This patch is compile tested only.
CC'ed Dinh Nguyen
Thanks,
Seungwon Jeon
changes since V2: none
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc-socfpga.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc-socfpga.c
b/drivers/mmc/host/dw_mmc-socfpga.c
index 14b5961..953f260 100644
--- a/drivers/mmc/host/dw_mmc-socfpga.c
+++ b/drivers/mmc/host/dw_mmc-socfpga.c
@@ -38,20 +38,6 @@ struct dw_mci_socfpga_priv_data {
static int dw_mci_socfpga_priv_init(struct dw_mci *host)
{
- struct dw_mci_socfpga_priv_data *priv;
-
- priv = devm_kzalloc(host-dev, sizeof(*priv), GFP_KERNEL);
- if (!priv) {
- dev_err(host-dev, mem alloc failed for private data\n);
- return -ENOMEM;
- }
-
- priv-sysreg = syscon_regmap_lookup_by_compatible(altr,sys-mgr);
- if (IS_ERR(priv-sysreg)) {
- dev_err(host-dev, regmap for altr,sys-mgr lookup failed.\n);
- return PTR_ERR(priv-sysreg);
- }
- host-priv = priv;
return 0;
}
@@ -79,12 +65,24 @@ static void dw_mci_socfpga_prepare_command(struct
dw_mci *host, u32 *cmdr)
static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
{
- struct dw_mci_socfpga_priv_data *priv = host-priv;
+ struct dw_mci_socfpga_priv_data *priv;
struct device_node *np = host-dev-of_node;
u32 timing[2];
u32 div = 0;
int ret;
+ priv = devm_kzalloc(host-dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(host-dev, mem alloc failed for private data\n);
+ return -ENOMEM;
+ }
+
+ priv-sysreg = syscon_regmap_lookup_by_compatible(altr,sys-mgr);
+ if (IS_ERR(priv-sysreg)) {
+ dev_err(host-dev, regmap for altr,sys-mgr lookup failed.\n);
+ return PTR_ERR(priv-sysreg);
+ }
+
ret = of_property_read_u32(np, altr,dw-mshc-ciu-div, div);
if (ret)
dev_info(host-dev, No dw-mshc-ciu-div specified, assuming
1);
@@ -96,6 +94,7 @@ static int dw_mci_socfpga_parse_dt(struct dw_mci *host)
return ret;
priv-hs_timing = SYSMGR_SDMMC_CTRL_SET(timing[0], timing[1]);
+ host-priv = priv;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
