Re: [PATCH 03/27] ARM: EXYNOS: Add IO mapping for PMU of Exynos3250

2014-04-14 Thread Chanwoo Choi
Dear Arnd and Kukjin,

On 04/10/2014 06:46 PM, Arnd Bergmann wrote:
 On Thursday 10 April 2014 18:28:20 Chanwoo Choi wrote:
 This patch add memory mapping for PMU (Power Management Unit) which is used
 for power control of Exynos3250.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 
 Same thing as for the SRAM here, can you work on making this a proper
 driver instead?
 

As Chanho Park said, Sachin already submitted the DT support[1] for SYSRAM area.
[1] : http://www.spinics.net/lists/linux-samsung-soc/msg27647.html

But, this patch has not yet to merge git repository(linux-samsung.git, 
arm-soc.git).
So, I'll make a driver to handle PMU memory mapping after Sachin's patch is 
merged.

Best Regards,
Chanwoo Choi
--
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 6/9] exynos/drm: add DT bindings

2014-04-14 Thread Inki Dae
This patch adds bindings for Exynos drm display subsystem.
The bindings describes ports containing a list of phandles
pointing to display controller, image enhancer, and display
interfaces nodes.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 
 1 file changed, 32 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt

diff --git 
a/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt 
b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
new file mode 100644
index 000..6f7fae0
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
@@ -0,0 +1,32 @@
+Samsung Exynos DRM master device
+
+
+The Samsung Exynos DRM master device is a virtual device needed to list all
+display controller, image enhancer, and display interface nodes that comprise
+the graphics subsystem.
+
+Required properties:
+- compatible: Should be samsung,exynos-display-subsystem
+- ports: Should contain a list of phandles pointing to display controller,
+  image enhancer, and display interface ports.
+
+Examples:
+
+In case of using MIPI-DSI,
+display-subsystem {
+   compatible = samsung,exynos-display-subsystem;
+   ports = fimd, dsi;
+};
+
+
+In case of using DisplayPort,
+display-subsystem {
+   compatible = samsung,exynos-display-subsystem;
+   ports = fimd, dp;
+};
+
+In case of using parallel panel,
+display-subsystem {
+   compatible = samsung,exynos-display-subsystem;
+   ports = fimd;
+};
-- 
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


[PATCH 2/9] drm/exynos: dpi: fix hotplug fail issue

2014-04-14 Thread Inki Dae
When connector is created, if connector-polled is
DRM_CONNECTOR_POLL_CONNECT then drm_kms_helper_hotplug_event
function isn't called at drm_helper_hpd_irq_event because the
function will be called only in case of DRM_CONNECTOR_POLL_HPD.

So this patch sets always DRM_CONNECTOR_POLL_HPD flag to
connector-polled of parallel panel driver at connector creation.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index c1f4b35..ac206e7 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -123,10 +123,7 @@ static int exynos_dpi_create_connector(struct 
exynos_drm_display *display,
 
ctx-encoder = encoder;
 
-   if (ctx-panel_node)
-   connector-polled = DRM_CONNECTOR_POLL_CONNECT;
-   else
-   connector-polled = DRM_CONNECTOR_POLL_HPD;
+   connector-polled = DRM_CONNECTOR_POLL_HPD;
 
ret = drm_connector_init(encoder-dev, connector,
 exynos_dpi_connector_funcs,
-- 
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


[PATCH v3 0/9] drm/exynos: more cleanup with super device support

2014-04-14 Thread Inki Dae
This patch series cleans up exynos drm framework and kms sub drivers
using the component framework[1]

[1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html

Previous patches,
RFC: http://comments.gmane.org/gmane.comp.video.dri.devel/101200
v1: http://lists.freedesktop.org/archives/dri-devel/2014-March/056387.html
v2: http://www.spinics.net/lists/dri-devel/msg56372.html

Changelog v3:
- Add a patch for separating dpi from fimd
- Add legacy dt binding support
- Add more cleanup patches

Thanks,
Inki Dae


Andrzej Hajda (1):
  drm/exynos: separate dpi from fimd

Inki Dae (8):
  drm/exynos: add super device support
  drm/exynos: dpi: fix hotplug fail issue
  ARM: dts: exynos4210-universal: add super device node for exynos drm
  ARM: dts: exynos4210-trats: add super device node for exynos drm
  ARM: dts: exynos4412-trats2: add super device node for exynos drm
  exynos/drm: add DT bindings
  drm/exynos: fix comment to exynos_drm_device_subdrv_prove call
  drm/exynos: modify goto labels to meaningful names

 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 ++
 arch/arm/boot/dts/exynos4210-trats.dts |5 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts|5 +
 arch/arm/boot/dts/exynos4412-trats2.dts|5 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|   45 +--
 drivers/gpu/drm/exynos/exynos_drm_core.c   |  216 +++---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   17 ++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c|   51 ++--
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  313 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   69 ++---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c|  110 ---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   74 +++--
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  101 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   59 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |   54 +++-
 16 files changed, 675 insertions(+), 485 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt

-- 
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


[PATCH v5 1/9] drm/exynos: add super device support

2014-04-14 Thread Inki Dae
This patch adds super device support to bind sub drivers
using device tree.

For this, you should add a super device node to each machine dt files
like belows,

In case of using MIPI-DSI,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dsi;
};

In case of using DisplayPort,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd, dp;
};

In case of using Parallel panel,
display-subsystem {
compatible = samsung,exynos-display-subsystem;
ports = fimd;
};

And if you don't add connector device node to ports property,
default parallel panel driver, exynos_drm_dpi module, will be used.

ports property can have the following device nodes,
fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI

With this patch, we can resolve the probing order issue without
some global lists. So this patch also removes the unnecessary lists and
stuff related to these lists.

Previous RFC patch,
 http://www.spinics.net/lists/dri-devel/msg54671.html

Changelog since RFC patch:
- Register sub drivers and probe them at load(). In case of non sub
  drivers, sub driver probe is needed.
- Enable runtime pm at fimd_probe() instead of fimd_bind(). runtime pm
  should be enabled before iommu device is attached to fimd device.
- Do not return an error with component_master_add fail.
- Remove super device support from mipi dsi driver which was in RFC.
- Add super device support to parallel driver.

Changelog v2:
- Add super device support to mipi dsi driver.
- Bind fimd driver only in case that a drm_panel for parallel panel driver
  is added to panel_list of drm_panel module.
- Change super node name to 'display-subsystem'
  . 'exynos-drm' is specific to Linux so change it to generic name.
- Change propery name of super node to 'ports'
  . crtcs and connectors propery names are also specific to Linux so
change them to generic name.

Changlog v3:
- Do not probe/remove dpi module if fimd node has no port node.

Changelog v4:
- Move some codes for getting resources from each bind function to
  each probe function.
  . if -EPROBE_DEFER is returned at bind context, components will be
bound and unbound repeatedly by deferred probe feature.

Changelog v5:
- Return error only in case that there is no any compoment attached
  to master.
- Add legacy dt binding support
- Probe vidi driver in exynos_drm_init(), and release vidi driver
  correctly.
- Remove duplicated coherent_dma_mask setting.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |   45 +++--
 drivers/gpu/drm/exynos/exynos_drm_core.c |  216 ---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   17 ++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |   16 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |  273 --
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   78 -
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |  110 +++-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |   87 --
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |  101 +--
 drivers/gpu/drm/exynos/exynos_hdmi.c |   59 ---
 drivers/gpu/drm/exynos/exynos_mixer.c|   54 --
 12 files changed, 616 insertions(+), 444 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index aed533b..1cc3981 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -18,6 +18,7 @@
 #include linux/interrupt.h
 #include linux/delay.h
 #include linux/of.h
+#include linux/component.h
 #include linux/phy/phy.h
 #include video/of_display_timing.h
 #include video/of_videomode.h
@@ -969,16 +970,6 @@ static struct drm_connector_helper_funcs 
exynos_dp_connector_helper_funcs = {
.best_encoder = exynos_dp_best_encoder,
 };
 
-static int exynos_dp_initialize(struct exynos_drm_display *display,
-   struct drm_device *drm_dev)
-{
-   struct exynos_dp_device *dp = display-ctx;
-
-   dp-drm_dev = drm_dev;
-
-   return 0;
-}
-
 static bool find_bridge(const char *compat, struct bridge_init *bridge)
 {
bridge-client = NULL;
@@ -1106,7 +1097,6 @@ static void exynos_dp_dpms(struct exynos_drm_display 
*display, int mode)
 }
 
 static struct exynos_drm_display_ops exynos_dp_display_ops = {
-   .initialize = exynos_dp_initialize,
.create_connector = exynos_dp_create_connector,
.dpms = exynos_dp_dpms,
 };
@@ -1230,8 +1220,10 @@ static int exynos_dp_dt_parse_panel(struct 
exynos_dp_device *dp)
return 0;
 }
 
-static int exynos_dp_probe(struct platform_device *pdev)
+static int exynos_dp_bind(struct device *dev, struct device *master, void 
*data)
 {
+  

[PATCH 3/9] ARM: dts: exynos4210-universal: add super device node for exynos drm

2014-04-14 Thread Inki Dae
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/boot/dts/exynos4210-universal_c210.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 0a80a72..5351ac4 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -409,6 +409,11 @@
};
};
 
+   display-subsystem {
+   compatible = samsung,exynos-display-subsystem;
+   ports = fimd;
+   };
+
pwm@139D {
compatible = samsung,s5p6440-pwm;
status = okay;
-- 
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


[PATCH 5/9] ARM: dts: exynos4412-trats2: add super device node for exynos drm

2014-04-14 Thread Inki Dae
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 53c717b..115b9ed 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -581,6 +581,11 @@
status = okay;
};
 
+   display-subsystem {
+   compatible = samsung,exynos-display-subsystem;
+   ports = fimd, dsi_0;
+   };
+
camera {
pinctrl-0 = cam_port_b_clk_active;
pinctrl-names = default;
-- 
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


[PATCH v2 7/9] drm/exynos: separate dpi from fimd

2014-04-14 Thread Inki Dae
From: Andrzej Hajda a.ha...@samsung.com

The patch separates dpi related routines from fimd.

Changelog v2:
- Rename ctx-dpi to ctx-display

Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_dpi.c  |   40 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |   15 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |  109 --
 3 files changed, 69 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index ac206e7..03cb126 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -40,20 +40,10 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
force)
 {
struct exynos_dpi *ctx = connector_to_dpi(connector);
 
-   /* panels supported only by boot-loader are always connected */
-   if (!ctx-panel_node)
-   return connector_status_connected;
-
-   if (!ctx-panel) {
-   ctx-panel = of_drm_find_panel(ctx-panel_node);
-   if (ctx-panel)
-   drm_panel_attach(ctx-panel, ctx-connector);
-   }
+   if (!ctx-panel-connector)
+   drm_panel_attach(ctx-panel, ctx-connector);
 
-   if (ctx-panel)
-   return connector_status_connected;
-
-   return connector_status_disconnected;
+   return connector_status_connected;
 }
 
 static void exynos_dpi_connector_destroy(struct drm_connector *connector)
@@ -291,8 +281,10 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return -ENOMEM;
 
ret = of_get_videomode(dn, vm, 0);
-   if (ret  0)
+   if (ret  0) {
+   devm_kfree(dev, vm);
return ret;
+   }
 
ctx-vm = vm;
 
@@ -305,27 +297,35 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
return 0;
 }
 
-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev)
+struct exynos_drm_display *exynos_dpi_probe(struct device *dev)
 {
struct exynos_dpi *ctx;
int ret;
 
ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
if (!ctx)
-   return -ENOMEM;
+   return NULL;
 
ctx-dev = dev;
exynos_dpi_display.ctx = ctx;
ctx-dpms_mode = DRM_MODE_DPMS_OFF;
 
ret = exynos_dpi_parse_dt(ctx);
-   if (ret  0)
-   return ret;
+   if (ret  0) {
+   devm_kfree(dev, ctx);
+   return NULL;
+   }
+
+   if (ctx-panel_node) {
+   ctx-panel = of_drm_find_panel(ctx-panel_node);
+   if (!ctx-panel)
+   return ERR_PTR(-EPROBE_DEFER);
+   }
 
-   return exynos_drm_create_enc_conn(drm_dev, exynos_dpi_display);
+   return exynos_dpi_display;
 }
 
-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev)
+int exynos_dpi_remove(struct device *dev)
 {
struct drm_encoder *encoder = exynos_dpi_display.encoder;
struct exynos_dpi *ctx = exynos_dpi_display.ctx;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a589dfb..257ce09 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -334,17 +334,12 @@ int exynos_platform_device_ipp_register(void);
 void exynos_platform_device_ipp_unregister(void);
 
 #ifdef CONFIG_DRM_EXYNOS_DPI
-int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev);
-int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev);
-struct device_node *exynos_dpi_of_find_panel_node(struct device *dev);
+struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
+int exynos_dpi_remove(struct device *dev);
 #else
-static inline int exynos_dpi_probe(struct drm_device *drm_dev,
-   struct device *dev) { return 0; }
-static inline int exynos_dpi_remove(struct drm_device *drm_dev,
-   struct device *dev) { return 0; }
-static inline struct device_node
-   *exynos_dpi_of_find_panel_node(struct device *dev)
-{ return NULL; }
+static inline struct exynos_drm_display *
+exynos_dpi_probe(struct device *dev) { return 0; }
+static inline int exynos_dpi_remove(struct device *dev) { return 0; }
 #endif
 
 /*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b26b27e..dd8637b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -24,7 +24,6 @@
 #include video/of_display_timing.h
 #include video/of_videomode.h
 #include video/samsung_fimd.h
-#include drm/drm_panel.h
 #include drm/exynos_drm.h
 
 #include exynos_drm_drv.h
@@ -124,6 +123,7 @@ struct fimd_context {
 
struct exynos_drm_panel_info panel;
struct 

[PATCH 9/9] drm/exynos: modify goto labels to meaningful names

2014-04-14 Thread Inki Dae
Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   40 +++
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cdd74e2..1d1c604 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -508,56 +508,56 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
 #ifdef CONFIG_DRM_EXYNOS_DSI
ret = platform_driver_register(dsi_driver);
if (ret  0)
-   goto out_dsi;
+   goto err_unregister_dp;
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_FIMD
ret = platform_driver_register(fimd_driver);
if (ret  0)
-   goto out_fimd;
+   goto err_unregister_dsi;
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_HDMI
ret = platform_driver_register(hdmi_driver);
if (ret  0)
-   goto out_hdmi;
+   goto err_unregister_fimd;
ret = platform_driver_register(mixer_driver);
if (ret  0)
-   goto out_mixer;
+   goto err_unregister_hdmi;
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_G2D
ret = platform_driver_register(g2d_driver);
if (ret  0)
-   goto out_g2d;
+   goto err_unregister_mixer;
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_FIMC
ret = platform_driver_register(fimc_driver);
if (ret  0)
-   goto out_fimc;
+   goto err_unregister_g2d;
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
ret = platform_driver_register(rotator_driver);
if (ret  0)
-   goto out_rotator;
+   goto err_unregister_fimc;
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_GSC
ret = platform_driver_register(gsc_driver);
if (ret  0)
-   goto out_gsc;
+   goto err_unregister_rotator;
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_IPP
ret = platform_driver_register(ipp_driver);
if (ret  0)
-   goto out_ipp;
+   goto err_unregister_gsc;
 
ret = exynos_platform_device_ipp_register();
if (ret  0)
-   goto out_ipp_dev;
+   goto err_unregister_ipp;
 #endif
 
ret = component_master_add(pdev-dev, exynos_drm_ops);
@@ -568,46 +568,46 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
 
 #ifdef CONFIG_DRM_EXYNOS_IPP
exynos_platform_device_ipp_unregister();
-out_ipp_dev:
+err_unregister_ipp:
platform_driver_unregister(ipp_driver);
-out_ipp:
+err_unregister_gsc:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_GSC
platform_driver_unregister(gsc_driver);
-out_gsc:
+err_unregister_rotator:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_ROTATOR
platform_driver_unregister(rotator_driver);
-out_rotator:
+err_unregister_fimc:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_FIMC
platform_driver_unregister(fimc_driver);
-out_fimc:
+err_unregister_g2d:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_G2D
platform_driver_unregister(g2d_driver);
-out_g2d:
+err_unregister_mixer:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_HDMI
platform_driver_unregister(mixer_driver);
-out_mixer:
+err_unregister_hdmi:
platform_driver_unregister(hdmi_driver);
-out_hdmi:
+err_unregister_fimd:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_FIMD
platform_driver_unregister(fimd_driver);
-out_fimd:
+err_unregister_dsi:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_DSI
platform_driver_unregister(dsi_driver);
-out_dsi:
+err_unregister_dp:
 #endif
 
 #ifdef CONFIG_DRM_EXYNOS_DP
-- 
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


[PATCH 8/9] drm/exynos: fix comment to exynos_drm_device_subdrv_prove call

2014-04-14 Thread Inki Dae
subdrv_probe callback of virtual display driver will be
called by exynos_drm_device_subdrv_probe() to create crtc
and encoder/connector for virtual display driver.
So it fixes comments to exynos_drm_device_subdrv probe call.

Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 63dabba..cdd74e2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -101,7 +101,7 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
if (ret)
goto err_cleanup_vblank;
 
-   /* Probe non kms sub drivers. */
+   /* Probe non kms sub drivers and virtual display driver. */
ret = exynos_drm_device_subdrv_probe(dev);
if (ret)
goto err_unbind_all;
-- 
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


[PATCH 4/9] ARM: dts: exynos4210-trats: add super device node for exynos drm

2014-04-14 Thread Inki Dae
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/boot/dts/exynos4210-trats.dts |5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index 02c6768..a41c109 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -414,6 +414,11 @@
status = okay;
};
 
+   display-subsystem {
+   compatible = samsung,exynos-display-subsystem;
+   ports = fimd, dsi_0;
+   };
+
camera {
pinctrl-names = default;
pinctrl-0 = ;
-- 
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: [PATCH 01/27] ARM: EXYNOS: Add Exynos3250 SoC ID

2014-04-14 Thread Chanwoo Choi
Dear Kukjin and Tomasz,

On 04/11/2014 10:31 AM, Chanwoo Choi wrote:
 Hi,
 
 On 04/10/2014 06:43 PM, Arnd Bergmann wrote:
 On Thursday 10 April 2014 18:28:18 Chanwoo Choi wrote:
 This patch add Exynos3250's SoC ID. Exynos 3250 is System-On-Chip(SoC) that
 is based on the 32-bit RISC processor for Smartphone. Exynos3250 uses 
 Cortex-A7
 dual cores and has a target speed of 1.0GHz.

 Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  arch/arm/mach-exynos/Kconfig | 22 ++
  arch/arm/mach-exynos/exynos.c|  1 +
  arch/arm/plat-samsung/include/plat/cpu.h | 10 ++
  3 files changed, 33 insertions(+)

 diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
 index fc8bf18..6da8a68 100644
 --- a/arch/arm/mach-exynos/Kconfig
 +++ b/arch/arm/mach-exynos/Kconfig
 @@ -11,6 +11,17 @@ if ARCH_EXYNOS
  
  menu SAMSUNG EXYNOS SoCs Support
  
 +config ARCH_EXYNOS3
 +   bool SAMSUNG EXYNOS3
 +   select ARM_AMBA
 +   select CLKSRC_OF
 +   select HAVE_ARM_SCU if SMP
 +   select HAVE_SMP
 +   select PINCTRL
 +   select PM_GENERIC_DOMAINS if PM_RUNTIME
 +   help
 + Samsung EXYNOS3 SoCs based systems
 +

 Isn't S5PV210 also called an Exynos3 these days? Are we going to get
 any conflicts here when merging that code into Exynos as Tomasz has
 suggested in the past?
 
 I knew. But, S5PV210/S5PC110 has not yet included in Exynos3 category on 
 mainline.
 Need opinion of Exynos SoC Maintainer to clear this ambiguous stuff.
 
 Dear Kukjin and Tomasz,
 I need your opinion about this patch.
 

Please review this patch and reply about Arnd's comment.

Best Regards,
Chanwoo Choi

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: dts: Add atmel trackpad node to 5250 cros

2014-04-14 Thread Arun Kumar K
The newer versions of exynos5250 based Snow boards have
atmel trackpad. Updating relevant nodes for the same.

Signed-off-by: Arun Kumar K arun...@samsung.com
---
 arch/arm/boot/dts/exynos5250-cros-common.dtsi |   24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-cros-common.dtsi 
b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
index 2c1560d..658f086 100644
--- a/arch/arm/boot/dts/exynos5250-cros-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-cros-common.dtsi
@@ -28,6 +28,13 @@
samsung,pin-pud = 0;
};
 
+   trackpad_irq: trackpad-irq {
+   samsung,pins = gpx1-2;
+   samsung,pin-function = 0;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
max77686_irq: max77686-irq {
samsung,pins = gpx3-2;
samsung,pin-function = 0;
@@ -191,6 +198,9 @@
samsung,i2c-sda-delay = 100;
samsung,i2c-max-bus-freq = 378000;
 
+   pinctrl-names = default;
+   pinctrl-0 = i2c1_bus trackpad_irq;
+
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
@@ -198,6 +208,20 @@
interrupt-parent = gpx1;
wakeup-source;
};
+   trackpad-alt {
+   reg = 0x4b;
+   compatible = atmel,atmel_mxt_tp;
+   interrupts = 2 0;
+   interrupt-parent = gpx1;
+   wakeup-source;
+   };
+   trackpad-bootloader {
+   reg = 0x25;
+   compatible = atmel,atmel_mxt_tp;
+   interrupts = 2 0;
+   interrupt-parent = gpx1;
+   wakeup-source;
+   };
};
 
i2c@12C8 {
-- 
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


[PATCH v8 0/3] Exynos 5410 support

2014-04-14 Thread Tarek Dakhran
The series of patches represent support of Exynos 5410 SoC

The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture

Patches add new platform description, support of clock controller and device
tree for Exynos 5410.

Has been build on Linux Kernel v3.15-rc1
Has been tested on: 1) Exynos 5410 reference board (exynos_defconfig)
2) Odroid-XU board (exynos_defconfig)

I hope, this will be commited to Linux v3.15...

Tarek.

Tarek Dakhran (3):
  ARM: EXYNOS: Add support for EXYNOS5410 SoC
  clk: exynos5410: register clocks using common clock framework
  ARM: dts: Add initial device tree support for EXYNOS5410

 .../devicetree/bindings/clock/exynos5410-clock.txt |   51 +
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/exynos5410-smdk5410.dts  |   65 ++
 arch/arm/boot/dts/exynos5410.dtsi  |  140 
 arch/arm/mach-exynos/Kconfig   |8 +
 arch/arm/mach-exynos/exynos.c  |   12 ++
 arch/arm/mach-exynos/hotplug.c |4 +-
 arch/arm/mach-exynos/include/mach/map.h|1 +
 arch/arm/mach-exynos/platsmp.c |   10 +-
 arch/arm/mach-exynos/regs-pmu.h|4 +-
 arch/arm/plat-samsung/include/plat/cpu.h   |   11 +-
 drivers/clk/samsung/Makefile   |1 +
 drivers/clk/samsung/clk-exynos5410.c   |  223 
 include/dt-bindings/clock/exynos5410.h |   33 +++
 14 files changed, 556 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt
 create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
 create mode 100644 arch/arm/boot/dts/exynos5410.dtsi
 create mode 100644 drivers/clk/samsung/clk-exynos5410.c
 create mode 100644 include/dt-bindings/clock/exynos5410.h

-- 
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


[PATCH v8 2/3] clk: exynos5410: register clocks using common clock framework

2014-04-14 Thread Tarek Dakhran
The EXYNOS5410 clocks are statically listed and registered
using the Samsung specific common clock helper functions.

Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
Acked-by: Tomasz Figa t.f...@samsung.com
---
 .../devicetree/bindings/clock/exynos5410-clock.txt |   51 +
 drivers/clk/samsung/Makefile   |1 +
 drivers/clk/samsung/clk-exynos5410.c   |  223 
 include/dt-bindings/clock/exynos5410.h |   33 +++
 4 files changed, 308 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/exynos5410-clock.txt
 create mode 100644 drivers/clk/samsung/clk-exynos5410.c
 create mode 100644 include/dt-bindings/clock/exynos5410.h

diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt 
b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000..82337c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,51 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be samsung,exynos5410-clock
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+There is clock that is generated outside the SoC. It is expected
+that it is defined using standard clock bindings with following
+ - compatible: should be samsung,exynos5410-oscclk
+
+Example 1: An example of a clock controller node is listed below.
+
+   clock: clock-controller@0x1001 {
+   compatible = samsung,exynos5410-clock;
+   reg = 0x1001 0x3;
+   #clock-cells = 1;
+   };
+
+Example 2: Required external clock.
+
+   fixed-rate-clocks {
+   oscclk {
+   compatible = samsung,exynos5410-oscclk;
+   clock-frequency = 2400;
+   };
+   };
+
+Example 3: UART controller node that consumes the clock generated by the clock
+  controller. Refer to the standard clock bindings for information
+  about 'clocks' and 'clock-names' property.
+
+   serial@12C2 {
+   compatible = samsung,exynos4210-uart;
+   reg = 0x12C0 0x100;
+   interrupts = 0 51 0;
+   clocks = clock CLK_UART0, clock CLK_SCLK_UART0;
+   clock-names = uart, clk_uart_baud0;
+   };
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..b572dd7 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -5,6 +5,7 @@
 obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
+obj-$(CONFIG_SOC_EXYNOS5410)   += clk-exynos5410.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
 obj-$(CONFIG_SOC_EXYNOS5440)   += clk-exynos5440.o
 obj-$(CONFIG_ARCH_EXYNOS)  += clk-exynos-audss.o
diff --git a/drivers/clk/samsung/clk-exynos5410.c 
b/drivers/clk/samsung/clk-exynos5410.c
new file mode 100644
index 000..7fdc17a
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos5410.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran t.dakh...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for Exynos5410 SoC.
+*/
+
+#include dt-bindings/clock/exynos5410.h
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+#include linux/of_address.h
+
+#include clk.h
+
+#define APLL_LOCK   0x0
+#define APLL_CON0   0x100
+#define CPLL_LOCK   0x10020
+#define CPLL_CON0   0x10120
+#define MPLL_LOCK   0x4000
+#define MPLL_CON0   0x4100
+#define BPLL_LOCK   0x20010
+#define BPLL_CON0   0x20110
+#define KPLL_LOCK   0x28000
+#define KPLL_CON0   0x28100
+
+#define SRC_CPU0x200
+#define DIV_CPU0   0x500
+#define SRC_CPERI1 0x4204
+#define DIV_TOP0   0x10510
+#define DIV_TOP1   0x10514
+#define DIV_FSYS1  0x1054c
+#define DIV_FSYS2  0x10550
+#define DIV_PERIC0 0x10558
+#define SRC_TOP0   0x10210
+#define SRC_TOP1   0x10214
+#define SRC_TOP2   0x10218
+#define SRC_FSYS   0x10244
+#define SRC_PERIC0 0x10250
+#define 

[PATCH v8 3/3] ARM: dts: Add initial device tree support for EXYNOS5410

2014-04-14 Thread Tarek Dakhran
Add initial device tree nodes for EXYNOS5410 SoC and SMDK5410 board.

Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
 arch/arm/boot/dts/Makefile|1 +
 arch/arm/boot/dts/exynos5410-smdk5410.dts |   65 ++
 arch/arm/boot/dts/exynos5410.dtsi |  140 +
 3 files changed, 206 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos5410-smdk5410.dts
 create mode 100644 arch/arm/boot/dts/exynos5410.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 35c146f..191dd19 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -74,6 +74,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos5250-smdk5250.dtb \
exynos5250-snow.dtb \
exynos5420-arndale-octa.dtb \
+   exynos5410-smdk5410.dtb \
exynos5420-smdk5420.dtb \
exynos5440-sd5v1.dtb \
exynos5440-ssdk5440.dtb
diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
new file mode 100644
index 000..d69e152
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -0,0 +1,65 @@
+/*
+ * SAMSUNG SMDK5410 board device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/dts-v1/;
+#include exynos5410.dtsi
+/ {
+   model = Samsung SMDK5410 board based on EXYNOS5410;
+   compatible = samsung,smdk5410, samsung,exynos5410;
+
+   memory {
+   reg = 0x4000 0x8000;
+   };
+
+   chosen {
+   bootargs = console=ttySAC2,115200;
+   };
+
+   fixed-rate-clocks {
+   oscclk {
+   compatible = samsung,exynos5410-oscclk;
+   clock-frequency = 2400;
+   };
+   };
+
+   mmc@1220 {
+   status = okay;
+   num-slots = 1;
+   supports-highspeed;
+   broken-cd;
+   card-detect-delay = 200;
+   samsung,dw-mshc-ciu-div = 3;
+   samsung,dw-mshc-sdr-timing = 2 3;
+   samsung,dw-mshc-ddr-timing = 1 2;
+
+   slot@0 {
+   reg = 0;
+   bus-width = 8;
+   };
+   };
+
+   mmc@1222 {
+   status = okay;
+   num-slots = 1;
+   supports-highspeed;
+   card-detect-delay = 200;
+   samsung,dw-mshc-ciu-div = 3;
+   samsung,dw-mshc-sdr-timing = 2 3;
+   samsung,dw-mshc-ddr-timing = 1 2;
+
+   slot@0 {
+   reg = 0;
+   bus-width = 4;
+   disable-wp;
+   };
+   };
+
+};
diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
new file mode 100644
index 000..e7cc930
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -0,0 +1,140 @@
+/*
+ * SAMSUNG EXYNOS5410 SoC device tree source
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SAMSUNG EXYNOS5410 SoC device nodes are listed in this file.
+ * EXYNOS5410 based board files can include this file and provide
+ * values for board specfic bindings.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include dt-bindings/clock/exynos5410.h
+#include exynos5.dtsi
+/ {
+   compatible = samsung,exynos5410, samsung,exynos5;
+
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   CPU0: cpu@0 {
+   device_type = cpu;
+   compatible = arm,cortex-a15;
+   reg = 0;
+   clock-frequency = 16;
+   };
+
+   CPU1: cpu@1 {
+   device_type = cpu;
+   compatible = arm,cortex-a15;
+   reg = 1;
+   clock-frequency = 16;
+   };
+
+   CPU2: cpu@2 {
+   device_type = cpu;
+   compatible = arm,cortex-a15;
+   reg = 2;
+   clock-frequency = 16;
+   };
+
+   CPU3: cpu@3 {
+   device_type = cpu;
+   compatible = arm,cortex-a15;
+   reg = 3;
+   clock-frequency = 16;
+   };
+   };
+
+   clock: clock-controller@1001 

[PATCH v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC

2014-04-14 Thread Tarek Dakhran
EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
Add initial support for this SoC.

Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
 arch/arm/mach-exynos/Kconfig |8 
 arch/arm/mach-exynos/exynos.c|   12 
 arch/arm/mach-exynos/hotplug.c   |4 ++--
 arch/arm/mach-exynos/include/mach/map.h  |1 +
 arch/arm/mach-exynos/platsmp.c   |   10 +++---
 arch/arm/mach-exynos/regs-pmu.h  |4 ++--
 arch/arm/plat-samsung/include/plat/cpu.h |   11 ++-
 7 files changed, 42 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18..92f2593 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -84,6 +84,14 @@ config SOC_EXYNOS5250
help
  Enable EXYNOS5250 SoC support
 
+config SOC_EXYNOS5410
+   bool SAMSUNG EXYNOS5410
+   default y
+   depends on ARCH_EXYNOS5
+   select PM_GENERIC_DOMAINS if PM_RUNTIME
+   help
+ Enable EXYNOS5410 SoC support
+
 config SOC_EXYNOS5420
bool SAMSUNG EXYNOS5420
default y
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index b32a907..fdb3fb5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[] __initdata = {
},
 };
 
+static struct map_desc exynos5410_iodesc[] __initdata = {
+   {
+   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+   .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   },
+};
+
 static struct map_desc exynos5_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -294,6 +303,8 @@ static void __init exynos_map_io(void)
iotable_init(exynos4x12_iodesc, ARRAY_SIZE(exynos4x12_iodesc));
if (soc_is_exynos5250())
iotable_init(exynos5250_iodesc, ARRAY_SIZE(exynos5250_iodesc));
+   if (soc_is_exynos5410())
+   iotable_init(exynos5410_iodesc, ARRAY_SIZE(exynos5410_iodesc));
 }
 
 void __init exynos_init_io(void)
@@ -376,6 +387,7 @@ static char const *exynos_dt_compat[] __initconst = {
samsung,exynos4412,
samsung,exynos5,
samsung,exynos5250,
+   samsung,exynos5410,
samsung,exynos5420,
samsung,exynos5440,
NULL
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..83ae5fb 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -95,8 +95,8 @@ static inline void platform_do_lowpower(unsigned int cpu, int 
*spurious)
for (;;) {
 
/* make cpu1 to be turned off at next WFI command */
-   if (cpu == 1)
-   __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+   if (cpu  0)
+   __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpu));
 
/*
 * here's the WFI
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index 7b046b5..894f431 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -29,6 +29,7 @@
 #define EXYNOS4210_PA_SYSRAM_NS0x0203F000
 #define EXYNOS4x12_PA_SYSRAM_NS0x0204F000
 #define EXYNOS5250_PA_SYSRAM_NS0x0204F000
+#define EXYNOS5410_PA_SYSRAM_NS0x02073000
 
 #define EXYNOS_PA_CHIPID   0x1000
 
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 03e5e9f..dce2841 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -37,6 +37,8 @@ static inline void __iomem *cpu_boot_reg_base(void)
 {
if (soc_is_exynos4210()  samsung_rev() == EXYNOS4210_REV_1_1)
return S5P_INFORM5;
+   if (soc_is_exynos5410())
+   return S5P_VA_SYSRAM_NS;
return S5P_VA_SYSRAM;
 }
 
@@ -47,6 +49,8 @@ static inline void __iomem *cpu_boot_reg(int cpu)
boot_reg = cpu_boot_reg_base();
if (soc_is_exynos4412())
boot_reg += 4*cpu;
+   else if (soc_is_exynos5410())
+   boot_reg += (0x1c);
else if (soc_is_exynos5420())
boot_reg += 4;
return boot_reg;
@@ -107,14 +111,14 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 */
write_pen_release(phys_cpu);
 
-   if (!(__raw_readl(S5P_ARM_CORE1_STATUS)  S5P_CORE_LOCAL_PWR_EN)) {
+   if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpu))  S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
+

Re: [PATCH v2 4/7] mmc: dw_mmc: exynos: incorporate ciu_div into timing property

2014-04-14 Thread Jaehoon Chung
Hi, Seungwon.

On 03/26/2014 08:31 PM, Seungwon Jeon wrote:
 ciu_div may not be common value for all speed mode.
 So, it needs to be attached to CLKSEL timing.
 
 Signed-off-by: Seungwon Jeon tgih@samsung.com
 ---
  drivers/mmc/host/dw_mmc-exynos.c |   75 
 ++
  drivers/mmc/host/dw_mmc-exynos.h |1 +
  2 files changed, 53 insertions(+), 23 deletions(-)
 
 diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
 b/drivers/mmc/host/dw_mmc-exynos.c
 index bab97e9..39f9114 100644
 --- a/drivers/mmc/host/dw_mmc-exynos.c
 +++ b/drivers/mmc/host/dw_mmc-exynos.c
 @@ -39,6 +39,7 @@ struct dw_mci_exynos_priv_data {
   u8  ciu_div;
   u32 sdr_timing;
   u32 ddr_timing;
 + u32 hs200_timing;
   u32 cur_speed;
  };
  
 @@ -64,6 +65,18 @@ static struct dw_mci_exynos_compatible {
   },
  };
  
 +static inline u8 dw_mci_exynos_get_ciu_div(struct dw_mci *host)
 +{
 + struct dw_mci_exynos_priv_data *priv = host-priv;
 +
 + if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4412)
 + return EXYNOS4412_FIXED_CIU_CLK_DIV;
 + else if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4210)
 + return EXYNOS4210_FIXED_CIU_CLK_DIV;
 + else
 + return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL)) + 1;
 +}
 +
  static int dw_mci_exynos_priv_init(struct dw_mci *host)
  {
   struct dw_mci_exynos_priv_data *priv = host-priv;
 @@ -77,6 +90,8 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
  SDMMC_MPSCTRL_NON_SECURE_WRITE_BIT);
   }
  
 + priv-ciu_div = dw_mci_exynos_get_ciu_div(host);
 +
   return 0;
  }
  
 @@ -84,7 +99,7 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
  {
   struct dw_mci_exynos_priv_data *priv = host-priv;
  
 - host-bus_hz /= (priv-ciu_div + 1);
 + host-bus_hz /= priv-ciu_div;
  
   return 0;
  }
 @@ -151,9 +166,10 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, 
 struct mmc_ios *ios)
   struct dw_mci_exynos_priv_data *priv = host-priv;
   unsigned int wanted = ios-clock;
   unsigned long actual;
 - u8 div = priv-ciu_div + 1;
  
 - if (ios-timing == MMC_TIMING_MMC_DDR52) {
 + if (ios-timing == MMC_TIMING_MMC_HS200) {
 + mci_writel(host, CLKSEL, priv-hs200_timing);
 + } else if (ios-timing == MMC_TIMING_MMC_DDR52) {
   mci_writel(host, CLKSEL, priv-ddr_timing);
   /* Should be double rate for DDR mode */
   if (ios-bus_width == MMC_BUS_WIDTH_8)
 @@ -174,6 +190,7 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, 
 struct mmc_ios *ios)
   wanted = EXYNOS_CCLKIN_MIN;
  
   if (wanted != priv-cur_speed) {
 + u8 div = dw_mci_exynos_get_ciu_div(host);
   int ret = clk_set_rate(host-ciu_clk, wanted * div);
   if (ret)
   dev_warn(host-dev,
 @@ -186,14 +203,34 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, 
 struct mmc_ios *ios)
   }
  }
  
 +static int dw_mci_exynos_dt_populate_timing(struct dw_mci *host,
 + unsigned int ctrl_type,
 + const char *propname,
 + u32 *out_values)
 +{
 + struct device_node *np = host-dev-of_node;
 + u32 timing[3];
 + int ret;
 +
 + ret = of_property_read_u32_array(np, propname, timing, 3);
 + if (ret)
 + return ret;
 +
 + if (ctrl_type == DW_MCI_TYPE_EXYNOS4412 ||
 + ctrl_type == DW_MCI_TYPE_EXYNOS4210)
 + timing[2] = 0;
 +
 + *out_values = SDMMC_CLKSEL_TIMING(timing[0], timing[1], timing[2]);
 +
 + return 0;
 +}
 +
 +
  static int dw_mci_exynos_parse_dt(struct dw_mci *host)
  {
   struct dw_mci_exynos_priv_data *priv;
   struct device_node *np = host-dev-of_node;
 - u32 timing[2];
 - u32 div = 0;
 - int idx;
 - int ret;
 + int idx, ret;
  
   priv = devm_kzalloc(host-dev, sizeof(*priv), GFP_KERNEL);
   if (!priv) {
 @@ -206,29 +243,21 @@ static int dw_mci_exynos_parse_dt(struct dw_mci *host)
   priv-ctrl_type = exynos_compat[idx].ctrl_type;
   }
  
 - if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4412)
 - priv-ciu_div = EXYNOS4412_FIXED_CIU_CLK_DIV - 1;
 - else if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS4210)
 - priv-ciu_div = EXYNOS4210_FIXED_CIU_CLK_DIV - 1;
 - else {
 - of_property_read_u32(np, samsung,dw-mshc-ciu-div, div);
 - priv-ciu_div = div;
 - }
Did you remove the property of ciu-div?
I didn't find anywhere it's used, when this is removed.
Then it needs to remove the properties into device-tree.
And i want to maintain the property of ciu-div.

Best Regards,
Jaehoon Chung

 -
 - ret = 

Re: [PATCH v2 2/7] mmc: dw_mmc: exynos: don't use if clock isn't available

2014-04-14 Thread Jaehoon Chung
Acked-by: Jaehoon Chung jh80.ch...@samsung.com

On 03/26/2014 08:31 PM, Seungwon Jeon wrote:
 Add checking whether the clock is valid.
 
 Signed-off-by: Seungwon Jeon tgih@samsung.com
 ---
  drivers/mmc/host/dw_mmc-exynos.c |   11 +++
  1 files changed, 7 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
 b/drivers/mmc/host/dw_mmc-exynos.c
 index a67e784..a2d06c5 100644
 --- a/drivers/mmc/host/dw_mmc-exynos.c
 +++ b/drivers/mmc/host/dw_mmc-exynos.c
 @@ -117,9 +117,9 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
  static int dw_mci_exynos_setup_clock(struct dw_mci *host)
  {
   struct dw_mci_exynos_priv_data *priv = host-priv;
 - unsigned long rate = clk_get_rate(host-ciu_clk);
  
 - host-bus_hz = rate / (priv-ciu_div + 1);
 + host-bus_hz /= (priv-ciu_div + 1);
 +
   return 0;
  }
  
 @@ -196,8 +196,11 @@ static void dw_mci_exynos_set_ios(struct dw_mci *host, 
 struct mmc_ios *ios)
   mci_writel(host, CLKSEL, priv-sdr_timing);
   }
  
 - /* Don't care if wanted clock is zero */
 - if (!wanted)
 + /*
 +  * Don't care if wanted clock is zero or
 +  * ciu clock is unavailable
 +  */
 + if (!wanted || IS_ERR(host-ciu_clk))
   return;
  
   /* Guaranteed minimum frequency for cclkin */
 

--
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 v2 1/7] mmc: dw_mmc: fix the max_blk_count in IDMAC

2014-04-14 Thread Jaehoon Chung
Acked-by: Jaehoon Chung jh80.ch...@samsung.com

On 03/26/2014 08:30 PM, Seungwon Jeon wrote:
 Even though 1MB is reserved for descriptor table in IDMAC,
 the dw_mmc host driver is allowed to receive only maximum
 128KB block length in one request. This is caused by setting
 improper max_blk_count. It needs to be e adjusted so that
 descriptor table is used fully. It is found that the performance
 is improved with the increased the max_blk_count.
 
 Signed-off-by: Seungwon Jeon tgih@samsung.com
 ---
  drivers/mmc/host/dw_mmc.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 3a6721e..aeb38f9 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -2101,9 +2101,9 @@ static int dw_mci_init_slot(struct dw_mci *host, 
 unsigned int id)
  #ifdef CONFIG_MMC_DW_IDMAC
   mmc-max_segs = host-ring_size;
   mmc-max_blk_size = 65536;
 - mmc-max_blk_count = host-ring_size;
   mmc-max_seg_size = 0x1000;
 - mmc-max_req_size = mmc-max_seg_size * mmc-max_blk_count;
 + mmc-max_req_size = mmc-max_seg_size * host-ring_size;
 + mmc-max_blk_count = mmc-max_req_size / 512;
  #else
   mmc-max_segs = 64;
   mmc-max_blk_size = 65536; /* BLKSIZ is 16 bits */
 

--
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 v2 3/7] mmc: dw_mmc: exynos: move definitions to header file

2014-04-14 Thread Jaehoon Chung
Acked-by: Jaehoon Chung jh80.ch...@samsung.com

On 03/26/2014 08:31 PM, Seungwon Jeon wrote:
 Move some parts related to definition to header file.
 
 Signed-off-by: Seungwon Jeon tgih@samsung.com
 ---
  drivers/mmc/host/dw_mmc-exynos.c |   46 ---
  drivers/mmc/host/dw_mmc-exynos.h |   55 
 ++
  2 files changed, 61 insertions(+), 40 deletions(-)
  create mode 100644 drivers/mmc/host/dw_mmc-exynos.h
 
 diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
 b/drivers/mmc/host/dw_mmc-exynos.c
 index a2d06c5..bab97e9 100644
 --- a/drivers/mmc/host/dw_mmc-exynos.c
 +++ b/drivers/mmc/host/dw_mmc-exynos.c
 @@ -21,42 +21,8 @@
  
  #include dw_mmc.h
  #include dw_mmc-pltfm.h
 +#include dw_mmc-exynos.h
  
 -#define NUM_PINS(x)  (x + 2)
 -
 -#define SDMMC_CLKSEL 0x09C
 -#define SDMMC_CLKSEL_CCLK_SAMPLE(x)  (((x)  7)  0)
 -#define SDMMC_CLKSEL_CCLK_DRIVE(x)   (((x)  7)  16)
 -#define SDMMC_CLKSEL_CCLK_DIVIDER(x) (((x)  7)  24)
 -#define SDMMC_CLKSEL_GET_DRV_WD3(x)  (((x)  16)  0x7)
 -#define SDMMC_CLKSEL_TIMING(x, y, z) (SDMMC_CLKSEL_CCLK_SAMPLE(x) |  \
 - SDMMC_CLKSEL_CCLK_DRIVE(y) |\
 - SDMMC_CLKSEL_CCLK_DIVIDER(z))
 -#define SDMMC_CLKSEL_WAKEUP_INT  BIT(11)
 -
 -#define EXYNOS4210_FIXED_CIU_CLK_DIV 2
 -#define EXYNOS4412_FIXED_CIU_CLK_DIV 4
 -
 -/* Block number in eMMC */
 -#define DWMCI_BLOCK_NUM  0x
 -
 -#define SDMMC_EMMCP_BASE 0x1000
 -#define SDMMC_MPSECURITY (SDMMC_EMMCP_BASE + 0x0010)
 -#define SDMMC_MPSBEGIN0  (SDMMC_EMMCP_BASE + 0x0200)
 -#define SDMMC_MPSEND0(SDMMC_EMMCP_BASE + 0x0204)
 -#define SDMMC_MPSCTRL0   (SDMMC_EMMCP_BASE + 0x020C)
 -
 -/* SMU control bits */
 -#define DWMCI_MPSCTRL_SECURE_READ_BITBIT(7)
 -#define DWMCI_MPSCTRL_SECURE_WRITE_BIT   BIT(6)
 -#define DWMCI_MPSCTRL_NON_SECURE_READ_BITBIT(5)
 -#define DWMCI_MPSCTRL_NON_SECURE_WRITE_BIT   BIT(4)
 -#define DWMCI_MPSCTRL_USE_FUSE_KEY   BIT(3)
 -#define DWMCI_MPSCTRL_ECB_MODE   BIT(2)
 -#define DWMCI_MPSCTRL_ENCRYPTION BIT(1)
 -#define DWMCI_MPSCTRL_VALID  BIT(0)
 -
 -#define EXYNOS_CCLKIN_MIN5000/* unit: HZ */
  
  /* Variations in Exynos specific dw-mshc controller */
  enum dw_mci_exynos_type {
 @@ -104,11 +70,11 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
  
   if (priv-ctrl_type == DW_MCI_TYPE_EXYNOS5420_SMU) {
   mci_writel(host, MPSBEGIN0, 0);
 - mci_writel(host, MPSEND0, DWMCI_BLOCK_NUM);
 - mci_writel(host, MPSCTRL0, DWMCI_MPSCTRL_SECURE_WRITE_BIT |
 -DWMCI_MPSCTRL_NON_SECURE_READ_BIT |
 -DWMCI_MPSCTRL_VALID |
 -DWMCI_MPSCTRL_NON_SECURE_WRITE_BIT);
 + mci_writel(host, MPSEND0, SDMMC_ENDING_SEC_NR_MAX);
 + mci_writel(host, MPSCTRL0, SDMMC_MPSCTRL_SECURE_WRITE_BIT |
 +SDMMC_MPSCTRL_NON_SECURE_READ_BIT |
 +SDMMC_MPSCTRL_VALID |
 +SDMMC_MPSCTRL_NON_SECURE_WRITE_BIT);
   }
  
   return 0;
 diff --git a/drivers/mmc/host/dw_mmc-exynos.h 
 b/drivers/mmc/host/dw_mmc-exynos.h
 new file mode 100644
 index 000..2554e2f
 --- /dev/null
 +++ b/drivers/mmc/host/dw_mmc-exynos.h
 @@ -0,0 +1,55 @@
 +/*
 + * Exynos Specific Extensions for Synopsys DW Multimedia Card Interface 
 driver
 + *
 + * Copyright (C) 2012-2014 Samsung Electronics Co., Ltd.
 + *
 + * 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.
 + */
 +
 +#ifndef _DW_MMC_EXYNOS_H_
 +#define _DW_MMC_EXYNOS_H_
 +
 +/* Extended Register's Offset */
 +#define SDMMC_CLKSEL 0x09C
 +
 +/* CLKSEL register defines */
 +#define SDMMC_CLKSEL_CCLK_SAMPLE(x)  (((x)  7)  0)
 +#define SDMMC_CLKSEL_CCLK_DRIVE(x)   (((x)  7)  16)
 +#define SDMMC_CLKSEL_CCLK_DIVIDER(x) (((x)  7)  24)
 +#define SDMMC_CLKSEL_GET_DRV_WD3(x)  (((x)  16)  0x7)
 +#define SDMMC_CLKSEL_TIMING(x, y, z) (SDMMC_CLKSEL_CCLK_SAMPLE(x) |  \
 +  SDMMC_CLKSEL_CCLK_DRIVE(y) |   \
 +  SDMMC_CLKSEL_CCLK_DIVIDER(z))
 +#define SDMMC_CLKSEL_WAKEUP_INT  BIT(11)
 +
 +/* Protector Register */
 +#define SDMMC_EMMCP_BASE 0x1000
 +#define SDMMC_MPSECURITY (SDMMC_EMMCP_BASE + 0x0010)
 +#define SDMMC_MPSBEGIN0  (SDMMC_EMMCP_BASE + 0x0200)
 +#define SDMMC_MPSEND0(SDMMC_EMMCP_BASE + 0x0204)
 +#define SDMMC_MPSCTRL0   (SDMMC_EMMCP_BASE + 0x020C)
 +
 +/* SMU control defines */
 +#define SDMMC_MPSCTRL_SECURE_READ_BIT

[PATCH 0/8] Support 4 levels of translation tables for ARM64

2014-04-14 Thread Jungseok Lee
Hi All,

This patchset supports 4 levels of tranlsation tables for ARM64.

Firstly, the patchset decouples page size from level of translation tables
as taking account into the comment from Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html

Then, it implements 4 levels of translation tables for both native, HYP
and stage2 sides.

This series is validated with Fast Models and kvmtool as platform and guest
launcher, respectively.

Jungseok Lee (8):
  arm64: Use pr_* instead of printk
  arm/arm64: KVM: Fix line length exceeding 80 characters
  arm64: Decouple page size from level of translation tables
  arm64: Introduce a kernel configuration option for VA_BITS
  arm64: Add a description on 48-bit address space with 4KB pages
  arm64: Add 4 levels of page tables definition with 4KB pages
  arm64: mm: Implement 4 levels of translation tables
  arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

Documentation/arm64/memory.txt|   59 ++--
 arch/arm/kvm/mmu.c|  100 ++---
 arch/arm64/Kconfig|   51 ++-
 arch/arm64/include/asm/kvm_arm.h  |   20 +
 arch/arm64/include/asm/kvm_mmu.h  |1 +
 arch/arm64/include/asm/memory.h   |6 +-
 arch/arm64/include/asm/page.h |6 +-
 arch/arm64/include/asm/pgalloc.h  |   24 -
 arch/arm64/include/asm/pgtable-4level-hwdef.h |   50 +++
 arch/arm64/include/asm/pgtable-4level-types.h |   71 +++
 arch/arm64/include/asm/pgtable-hwdef.h|   10 ++-
 arch/arm64/include/asm/pgtable.h  |   52 +--
 arch/arm64/include/asm/tlb.h  |   10 ++-
 arch/arm64/kernel/head.S  |   45 +-
 arch/arm64/kernel/traps.c |   19 ++--
 arch/arm64/mm/fault.c |1 +
 arch/arm64/mm/mmu.c   |   14 ++-
 17 files changed, 488 insertions(+), 51 deletions(-)


--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/8] arm64: Use pr_* instead of printk

2014-04-14 Thread Jungseok Lee
This patch fixed the following checkpatch complaint as using pr_*
instead of printk.

WARNING: printk() should include KERN_ facility level

Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
 arch/arm64/kernel/traps.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 7ffaddd..0484e81 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -65,7 +65,7 @@ static void dump_mem(const char *lvl, const char *str, 
unsigned long bottom,
fs = get_fs();
set_fs(KERNEL_DS);
 
-   printk(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
+   pr_emerg(%s%s(0x%016lx to 0x%016lx)\n, lvl, str, bottom, top);
 
for (first = bottom  ~31; first  top; first += 32) {
unsigned long p;
@@ -83,7 +83,7 @@ static void dump_mem(const char *lvl, const char *str, 
unsigned long bottom,
sprintf(str + i * 9,  );
}
}
-   printk(%s%04lx:%s\n, lvl, first  0x, str);
+   pr_emerg(%s%04lx:%s\n, lvl, first  0x, str);
}
 
set_fs(fs);
@@ -124,7 +124,7 @@ static void dump_instr(const char *lvl, struct pt_regs 
*regs)
break;
}
}
-   printk(%sCode: %s\n, lvl, str);
+   pr_emerg(%sCode: %s\n, lvl, str);
 
set_fs(fs);
 }
@@ -156,7 +156,7 @@ static void dump_backtrace(struct pt_regs *regs, struct 
task_struct *tsk)
frame.pc = thread_saved_pc(tsk);
}
 
-   printk(Call trace:\n);
+   pr_emerg(Call trace:\n);
while (1) {
unsigned long where = frame.pc;
int ret;
@@ -328,17 +328,17 @@ asmlinkage void bad_mode(struct pt_regs *regs, int 
reason, unsigned int esr)
 
 void __pte_error(const char *file, int line, unsigned long val)
 {
-   printk(%s:%d: bad pte %016lx.\n, file, line, val);
+   pr_crit(%s:%d: bad pte %016lx.\n, file, line, val);
 }
 
 void __pmd_error(const char *file, int line, unsigned long val)
 {
-   printk(%s:%d: bad pmd %016lx.\n, file, line, val);
+   pr_crit(%s:%d: bad pmd %016lx.\n, file, line, val);
 }
 
 void __pgd_error(const char *file, int line, unsigned long val)
 {
-   printk(%s:%d: bad pgd %016lx.\n, file, line, val);
+   pr_crit(%s:%d: bad pgd %016lx.\n, file, line, val);
 }
 
 void __init trap_init(void)
-- 
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 5/8] arm64: Add a description on 48-bit address space with 4KB pages

2014-04-14 Thread Jungseok Lee
This patch adds memory layout and translation lookup information
about 48-bit address space with 4K pages. The description is based
on 4 levels of translation tables.

Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
 Documentation/arm64/memory.txt |   59 ++--
 1 file changed, 51 insertions(+), 8 deletions(-)

diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index d50fa61..8142709 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -8,10 +8,11 @@ This document describes the virtual memory layout used by the 
AArch64
 Linux kernel. The architecture allows up to 4 levels of translation
 tables with a 4KB page size and up to 3 levels with a 64KB page size.
 
-AArch64 Linux uses 3 levels of translation tables with the 4KB page
-configuration, allowing 39-bit (512GB) virtual addresses for both user
-and kernel. With 64KB pages, only 2 levels of translation tables are
-used but the memory layout is the same.
+AArch64 Linux uses 3 levels and 4 levels of translation tables with
+the 4KB page configuration, allowing 39-bit (512GB) and 48-bit (256TB)
+virtual addresses, respectively, for both user and kernel. With 64KB
+pages, only 2 levels of translation tables are used but the memory layout
+is the same.
 
 User addresses have bits 63:39 set to 0 while the kernel addresses have
 the same bits set to 1. TTBRx selection is given by bit 63 of the
@@ -21,7 +22,7 @@ The swapper_pgd_dir address is written to TTBR1 and never 
written to
 TTBR0.
 
 
-AArch64 Linux memory layout with 4KB pages:
+AArch64 Linux memory layout with 4KB pages + 3 levels:
 
 Start  End SizeUse
 ---
@@ -48,7 +49,34 @@ ffbffc00 ffbf  64MB  
modules
 ffc0    256GB  kernel logical 
memory map
 
 
-AArch64 Linux memory layout with 64KB pages:
+AArch64 Linux memory layout with 4KB pages + 4 levels:
+
+Start  End SizeUse
+---
+    256TB  user
+
+   7bfe~124TB  vmalloc
+
+7bff   7bff  64KB  [guard page]
+
+7c00   7dff   2TB  vmemmap
+
+7e00   7bbf  ~2TB  [guard, future 
vmmemap]
+
+7a00   7aff  16MB  PCI I/O space
+
+7b00   7bbf  12MB  [guard]
+
+7bc0   7bdf   2MB  earlyprintk 
device
+
+7be0   7bff   2MB  [guard]
+
+7c00   7fff  64MB  modules
+
+8000    128TB  kernel logical 
memory map
+
+
+AArch64 Linux memory layout with 64KB pages + 2 levels:
 
 Start  End SizeUse
 ---
@@ -75,7 +103,7 @@ fdfffc00 fdff  64MB  
modules
 fe00      2TB  kernel logical 
memory map
 
 
-Translation table lookup with 4KB pages:
+Translation table lookup with 4KB pages + 3 levels:
 
 +++++++++
 |6356|5548|4740|3932|3124|2316|15 8|7  0|
@@ -90,7 +118,22 @@ Translation table lookup with 4KB pages:
  +- [63] TTBR0/1
 
 
-Translation table lookup with 64KB pages:
+Translation table lookup with 4KB pages + 4 levels:
+
++++++++++
+|6356|5548|4740|3932|3124|2316|15 8|7  0|
++++++++++
+ | | | | | |
+ | | | | | v
+ | | | | |   [11:0]  in-page offset
+ | | | | +- [20:12] L3 index
+ | | | +--- [29:21] L2 index
+ | | +- [38:30] L1 index
+ | +--- [47:39] L0 index
+ +- [63] TTBR0/1
+
+
+Translation table lookup with 64KB pages + 2 levels:
 
 +++++++++
 |6356|5548|4740|3932|3124|2316|15 8|7  

[PATCH 3/8] arm64: Decouple page size from level of translation

2014-04-14 Thread Jungseok Lee
This patch separates page size from level of translation tables in
configuration. It facilitates introduction of different options,
such as 4KB + 4 levels, 16KB + 4 levels and 64KB + 3 levels, easily.

Signed-off-by: Jungseok Lee jays@samsung.com
Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
---
 arch/arm64/Kconfig |   36 +++-
 arch/arm64/include/asm/page.h  |2 +-
 arch/arm64/include/asm/pgalloc.h   |4 ++--
 arch/arm64/include/asm/pgtable-hwdef.h |2 +-
 arch/arm64/include/asm/pgtable.h   |8 +++
 arch/arm64/include/asm/tlb.h   |2 +-
 6 files changed, 44 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e6e4d37..1a2faf9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -144,14 +144,48 @@ endmenu
 
 menu Kernel Features
 
+choice
+   prompt Page size
+   default ARM64_4K_PAGES
+   help
+ Allows page size.
+
+config ARM64_4K_PAGES
+   bool 4KB
+   help
+ This feature enables 4KB pages support.
+
 config ARM64_64K_PAGES
-   bool Enable 64KB pages support
+   bool 64KB
help
  This feature enables 64KB pages support (4KB by default)
  allowing only two levels of page tables and faster TLB
  look-up. AArch32 emulation is not available when this feature
  is enabled.
 
+endchoice
+
+choice
+   prompt Level of translation tables
+   default ARM64_3_LEVELS if ARM64_4K_PAGES
+   default ARM64_2_LEVELS if ARM64_64K_PAGES
+   help
+ Allows level of translation tables.
+
+config ARM64_2_LEVELS
+   bool 2 level
+   depends on ARM64_64K_PAGES
+   help
+ This feature enables 2 levels of translation tables.
+
+config ARM64_3_LEVELS
+   bool 3 level
+   depends on ARM64_4K_PAGES
+   help
+ This feature enables 3 levels of translation tables.
+
+endchoice
+
 config CPU_BIG_ENDIAN
bool Build big-endian kernel
help
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index 46bf666..268e53d 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@
 
 #ifndef __ASSEMBLY__
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include asm/pgtable-2level-types.h
 #else
 #include asm/pgtable-3level-types.h
diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 9bea6e7..4829837 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -26,7 +26,7 @@
 
 #define check_pgt_cache()  do { } while (0)
 
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
 {
@@ -44,7 +44,7 @@ static inline void pud_populate(struct mm_struct *mm, pud_t 
*pud, pmd_t *pmd)
set_pud(pud, __pud(__pa(pmd) | PMD_TYPE_TABLE));
 }
 
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
 
 extern pgd_t *pgd_alloc(struct mm_struct *mm);
 extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
b/arch/arm64/include/asm/pgtable-hwdef.h
index 5fc8a66..9cd86c6 100644
--- a/arch/arm64/include/asm/pgtable-hwdef.h
+++ b/arch/arm64/include/asm/pgtable-hwdef.h
@@ -16,7 +16,7 @@
 #ifndef __ASM_PGTABLE_HWDEF_H
 #define __ASM_PGTABLE_HWDEF_H
 
-#ifdef CONFIG_ARM64_64K_PAGES
+#ifdef CONFIG_ARM64_2_LEVELS
 #include asm/pgtable-2level-hwdef.h
 #else
 #include asm/pgtable-3level-hwdef.h
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 90c811f..a64ce5e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -47,7 +47,7 @@ extern void __pmd_error(const char *file, int line, unsigned 
long val);
 extern void __pgd_error(const char *file, int line, unsigned long val);
 
 #define pte_ERROR(pte) __pte_error(__FILE__, __LINE__, pte_val(pte))
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 #define pmd_ERROR(pmd) __pmd_error(__FILE__, __LINE__, pmd_val(pmd))
 #endif
 #define pgd_ERROR(pgd) __pgd_error(__FILE__, __LINE__, pgd_val(pgd))
@@ -320,7 +320,7 @@ static inline pte_t *pmd_page_vaddr(pmd_t pmd)
  */
 #define mk_pte(page,prot)  pfn_pte(page_to_pfn(page),prot)
 
-#ifndef CONFIG_ARM64_64K_PAGES
+#ifndef CONFIG_ARM64_2_LEVELS
 
 #define pud_none(pud)  (!pud_val(pud))
 #define pud_bad(pud)   (!(pud_val(pud)  2))
@@ -342,7 +342,7 @@ static inline pmd_t *pud_page_vaddr(pud_t pud)
return __va(pud_val(pud)  PHYS_MASK  (s32)PAGE_MASK);
 }
 
-#endif /* CONFIG_ARM64_64K_PAGES */
+#endif /* CONFIG_ARM64_2_LEVELS */
 
 /* to find an entry in a page-table-directory */
 #define pgd_index(addr)(((addr)  PGDIR_SHIFT)  
(PTRS_PER_PGD - 1))
@@ -353,7 +353,7 @@ static inline pmd_t *pud_page_vaddr(pud_t pud)
 #define 

[PATCH v3 resend] clk: s2mps11: Add support for S2MPS14 clocks

2014-04-14 Thread Krzysztof Kozlowski
This patch adds support for S2MPS14 PMIC clocks (BT and AP) to the
s2mps11 clock driver.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Yadwinder Singh Brar yadi.b...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
---
 drivers/clk/Kconfig   |  8 +++
 drivers/clk/clk-s2mps11.c | 61 +++
 2 files changed, 50 insertions(+), 19 deletions(-)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..8f9ce8ba036d 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -65,12 +65,12 @@ config COMMON_CLK_SI570
  clock generators.
 
 config COMMON_CLK_S2MPS11
-   tristate Clock driver for S2MPS11/S5M8767 MFD
+   tristate Clock driver for S2MPS1X/S5M8767 MFD
depends on MFD_SEC_CORE
---help---
- This driver supports S2MPS11/S5M8767 crystal oscillator clock. These
- multi-function devices have 3 fixed-rate oscillators, clocked at
- 32KHz each.
+ This driver supports S2MPS11/S2MPS14/S5M8767 crystal oscillator
+ clock. These multi-function devices have two (S2MPS14) or three
+ (S2MPS11, S5M8767) fixed-rate oscillators, clocked at 32KHz each.
 
 config CLK_TWL6040
tristate External McPDM functional clock from twl6040
diff --git a/drivers/clk/clk-s2mps11.c b/drivers/clk/clk-s2mps11.c
index f2f62a1bf61a..b78eafeab038 100644
--- a/drivers/clk/clk-s2mps11.c
+++ b/drivers/clk/clk-s2mps11.c
@@ -1,7 +1,7 @@
 /*
  * clk-s2mps11.c - Clock driver for S2MPS11.
  *
- * Copyright (C) 2013 Samsung Electornics
+ * Copyright (C) 2013,2014 Samsung Electornics
  *
  * 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
@@ -13,10 +13,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
  */
 
 #include linux/module.h
@@ -27,6 +23,7 @@
 #include linux/clk-provider.h
 #include linux/platform_device.h
 #include linux/mfd/samsung/s2mps11.h
+#include linux/mfd/samsung/s2mps14.h
 #include linux/mfd/samsung/s5m8767.h
 #include linux/mfd/samsung/core.h
 
@@ -125,7 +122,21 @@ static struct clk_init_data 
s2mps11_clks_init[S2MPS11_CLKS_NUM] = {
},
 };
 
-static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev)
+static struct clk_init_data s2mps14_clks_init[S2MPS11_CLKS_NUM] = {
+   [S2MPS11_CLK_AP] = {
+   .name = s2mps14_ap,
+   .ops = s2mps11_clk_ops,
+   .flags = CLK_IS_ROOT,
+   },
+   [S2MPS11_CLK_BT] = {
+   .name = s2mps14_bt,
+   .ops = s2mps11_clk_ops,
+   .flags = CLK_IS_ROOT,
+   },
+};
+
+static struct device_node *s2mps11_clk_parse_dt(struct platform_device *pdev,
+   struct clk_init_data *clks_init)
 {
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
struct device_node *clk_np;
@@ -145,9 +156,12 @@ static struct device_node *s2mps11_clk_parse_dt(struct 
platform_device *pdev)
if (!clk_table)
return ERR_PTR(-ENOMEM);
 
-   for (i = 0; i  S2MPS11_CLKS_NUM; i++)
+   for (i = 0; i  S2MPS11_CLKS_NUM; i++) {
+   if (!clks_init[i].name)
+   continue; /* Skip clocks not present in some devices */
of_property_read_string_index(clk_np, clock-output-names, i,
-   s2mps11_clks_init[i].name);
+   clks_init[i].name);
+   }
 
return clk_np;
 }
@@ -158,6 +172,7 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
struct s2mps11_clk *s2mps11_clks, *s2mps11_clk;
struct device_node *clk_np = NULL;
unsigned int s2mps11_reg;
+   struct clk_init_data *clks_init;
int i, ret = 0;
u32 val;
 
@@ -168,25 +183,33 @@ static int s2mps11_clk_probe(struct platform_device *pdev)
 
s2mps11_clk = s2mps11_clks;
 
-   clk_np = s2mps11_clk_parse_dt(pdev);
-   if (IS_ERR(clk_np))
-   return PTR_ERR(clk_np);
-
switch(platform_get_device_id(pdev)-driver_data) {
case S2MPS11X:
s2mps11_reg = S2MPS11_REG_RTC_CTRL;
+   clks_init = s2mps11_clks_init;
+   break;
+   case S2MPS14X:
+   s2mps11_reg = S2MPS14_REG_RTCCTRL;
+   clks_init = s2mps14_clks_init;
break;
case S5M8767X:
s2mps11_reg = S5M8767_REG_CTRL1;
+   clks_init = s2mps11_clks_init;
break;
default:
dev_err(pdev-dev, Invalid device type\n);

[PATCH v3 resend] clk: s2mps11: Add support for S2MPS14 clocks

2014-04-14 Thread Krzysztof Kozlowski
Hi,

This is a resend of third version of patchset adding support for
the S2MPS14 device to the s2mps11 clock driver.

Previous discusson can be found here:
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/28039

Changes since v2:
=
1. Patch 2/3: Remove MFD cells of_compatible which aren't used by child
   drivers and are not documented.
2. Added Tomasz's Review-by.

Changes since v1:
=
1. Patch 1/3: Update driver description in Kconfig.
2. Patch 2/3: Add of_compatible to all MFD cells.
3. Add Yadwinder's Review-by.

Best regards,
Krzysztof

Krzysztof Kozlowski (1):
  clk: s2mps11: Add support for S2MPS14 clocks

 drivers/clk/Kconfig   |  8 +++
 drivers/clk/clk-s2mps11.c | 61 +++
 2 files changed, 50 insertions(+), 19 deletions(-)

-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11

2014-04-14 Thread Krzysztof Kozlowski
Change the binding for regulators external control to the same used in
s2mps11 driver to be consistent.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: devicet...@vger.kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
---
 Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt | 4 ++--
 drivers/regulator/s5m8767.c   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt 
b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
index d290988ed975..558c80345ef0 100644
--- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -76,7 +76,7 @@ except these properties:
1 - on in normal mode
2 - low power mode
3 - suspend mode
-   - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one
+   - samsung,ext-control-gpios: (optional) GPIO specifier for one
GPIO controlling this regulator (enable/disable); This is
valid only for buck9.
 
@@ -157,7 +157,7 @@ Example:
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
op_mode = 3; /* Standby Mode */
-   s5m8767,pmic-ext-control-gpios = gpk0 2 0;
+   samsung,ext-control-gpios = gpk0 2 0;
};
};
};
diff --git a/drivers/regulator/s5m8767.c b/drivers/regulator/s5m8767.c
index 92f19a005dc3..dbfd98b04a77 100644
--- a/drivers/regulator/s5m8767.c
+++ b/drivers/regulator/s5m8767.c
@@ -534,7 +534,7 @@ static void s5m8767_pmic_dt_parse_ext_control_gpio(struct 
sec_pmic_dev *iodev,
struct device_node *reg_np)
 {
rdata-ext_control_gpio = of_get_named_gpio(reg_np,
-   s5m8767,pmic-ext-control-gpios, 0);
+   samsung,ext-control-gpios, 0);
if (!gpio_is_valid(rdata-ext_control_gpio))
rdata-ext_control_gpio = 0;
 }
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] regulator: s2mps11: Add external GPIO control for S2MPS14

2014-04-14 Thread Krzysztof Kozlowski
Add support for external control over GPIO for LDO10, LDO11 and LDO12
S2MPS14 regulators. External control can be turned on by writing 0x0 to
control register which in case of other regulators is used for disabling
them. These LDO10-LDO12 regulators can be disabled only by I2C GPIO or
PWREN pin so the patch actually allows proper way of disabling them.

Additionally the GPIO control has two benefits:
 - It is faster than toggling it over I2C bus.
 - It allows disabling the regulator during suspend to RAM; The AP will
   enable it during resume.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 drivers/regulator/s2mps11.c | 67 +++--
 include/linux/mfd/samsung/s2mps14.h |  2 ++
 2 files changed, 67 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 3aba0331fb5d..6dad0aa74a47 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -27,6 +27,7 @@
 #include linux/regulator/driver.h
 #include linux/regulator/machine.h
 #include linux/regulator/of_regulator.h
+#include linux/of_gpio.h
 #include linux/mfd/samsung/core.h
 #include linux/mfd/samsung/s2mps11.h
 #include linux/mfd/samsung/s2mps14.h
@@ -44,6 +45,8 @@ struct s2mps11_info {
 * was enabled.
 */
unsigned int s2mps14_suspend_state:30;
+   /* Array of size rdev_num with GPIO-s for external sleep control */
+   int *ext_control_gpio;
 };
 
 static int get_ramp_delay(int ramp_delay)
@@ -409,6 +412,8 @@ static int s2mps14_regulator_enable(struct regulator_dev 
*rdev)
 
if (s2mps11-s2mps14_suspend_state  (1  rdev_get_id(rdev)))
val = S2MPS14_ENABLE_SUSPEND;
+   else if (s2mps11-ext_control_gpio[rdev_get_id(rdev)])
+   val = S2MPS14_ENABLE_EXT_CONTROL;
else
val = rdev-desc-enable_mask;
 
@@ -565,9 +570,41 @@ static const struct regulator_desc s2mps14_regulators[] = {
regulator_desc_s2mps14_buck1235(5),
 };
 
-static int s2mps11_pmic_dt_parse(struct platform_device *pdev,
+static int s2mps14_pmic_enable_ext_control(struct s2mps11_info *s2mps11,
+   struct regulator_dev *rdev)
+{
+   return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+   rdev-desc-enable_mask, S2MPS14_ENABLE_EXT_CONTROL);
+}
+
+static void s2mps14_pmic_dt_parse_ext_control_gpio(struct platform_device 
*pdev,
struct of_regulator_match *rdata, struct s2mps11_info *s2mps11)
 {
+   int *gpio = s2mps11-ext_control_gpio;
+   unsigned int i;
+   unsigned int valid_regulators[3] = { S2MPS14_LDO10, S2MPS14_LDO11,
+   S2MPS14_LDO12 };
+
+   for (i = 0; i  ARRAY_SIZE(valid_regulators); i++) {
+   unsigned int reg = valid_regulators[i];
+
+   if (!rdata[reg].init_data || !rdata[reg].of_node)
+   continue;
+
+   gpio[reg] = of_get_named_gpio(rdata[reg].of_node,
+   samsung,ext-control-gpios, 0);
+   if (!gpio_is_valid(gpio[reg]))
+   gpio[reg] = 0;
+   else
+   dev_dbg(pdev-dev, Using GPIO %d for ext-control over 
%d/%s\n,
+   gpio[reg], reg, rdata[reg].name);
+   }
+}
+
+static int s2mps11_pmic_dt_parse(struct platform_device *pdev,
+   struct of_regulator_match *rdata, struct s2mps11_info *s2mps11,
+   enum sec_device_type dev_type)
+{
struct device_node *reg_np;
 
reg_np = of_get_child_by_name(pdev-dev.parent-of_node, regulators);
@@ -577,6 +614,9 @@ static int s2mps11_pmic_dt_parse(struct platform_device 
*pdev,
}
 
of_regulator_match(pdev-dev, reg_np, rdata, s2mps11-rdev_num);
+   if (dev_type == S2MPS14X)
+   s2mps14_pmic_dt_parse_ext_control_gpio(pdev, rdata, s2mps11);
+
of_node_put(reg_np);
 
return 0;
@@ -613,6 +653,12 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
return -EINVAL;
};
 
+   s2mps11-ext_control_gpio = devm_kzalloc(pdev-dev,
+   sizeof(*s2mps11-ext_control_gpio) * s2mps11-rdev_num,
+   GFP_KERNEL);
+   if (!s2mps11-ext_control_gpio)
+   return -ENOMEM;
+
if (!iodev-dev-of_node) {
if (iodev-pdata) {
pdata = iodev-pdata;
@@ -631,7 +677,7 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
for (i = 0; i  s2mps11-rdev_num; i++)
rdata[i].name = regulators[i].name;
 
-   ret = s2mps11_pmic_dt_parse(pdev, rdata, s2mps11);
+   ret = s2mps11_pmic_dt_parse(pdev, rdata, s2mps11, dev_type);
if (ret)
goto out;
 
@@ -652,6 +698,12 @@ common_reg:
config.of_node = rdata[i].of_node;
}
 
+   if (s2mps11-ext_control_gpio[i]) {
+   

[PATCH 0/4] regulator: s2mps11: Add external GPIO control for S2MPS14

2014-04-14 Thread Krzysztof Kozlowski
Hi,

This patchset adds external GPIO control to s2mps11 regulator driver
for some of the S2MPS14 regulators.

Additionally (patch 4/4) it changes the bindings in s5m8767 regulator driver
for external control to match these used here:
samsung,ext-control-gpios

Best regards,
Krzysztof

Krzysztof Kozlowski (4):
  regulator: s2mps11: Move DTS parsing code to separate function
  regulator: s2mps11: Add external GPIO control for S2MPS14
  Documentation: regulator: s2mps11: Document external GPIO control
  regulator: s5m8767: Use same binding for external control as in
s2mps11

 Documentation/devicetree/bindings/mfd/s2mps11.txt  | 14 
 .../bindings/regulator/s5m8767-regulator.txt   |  4 +-
 drivers/regulator/s2mps11.c| 98 +++---
 drivers/regulator/s5m8767.c|  2 +-
 include/linux/mfd/samsung/s2mps14.h|  2 +
 5 files changed, 105 insertions(+), 15 deletions(-)

-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] phy: exynos5-usbdrd: Add facility to toggle vbus gpio on/off

2014-04-14 Thread Vivek Gautam
Hi Felipe,


On Sat, Apr 12, 2014 at 9:07 AM, Felipe Balbi ba...@ti.com wrote:
 On Wed, Apr 09, 2014 at 05:24:45PM +0530, Vivek Gautam wrote:
 Adding support to enable/disable VBUS hooked to a gpio
 to enable vbus supply on the port.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---

 Based on 'phy-exynos5-usbdrd' patches:
 [PATCH V4 0/5] Add Exynos5 USB 3.0 phy driver based on generic PHY framework
 http://www.spinics.net/lists/linux-usb/msg105507.html

  drivers/phy/phy-exynos5-usbdrd.c |   18 ++
  1 file changed, 18 insertions(+)

 diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
 b/drivers/phy/phy-exynos5-usbdrd.c
 index ff54a7c..5ca7485 100644
 --- a/drivers/phy/phy-exynos5-usbdrd.c
 +++ b/drivers/phy/phy-exynos5-usbdrd.c
 @@ -18,6 +18,7 @@
  #include linux/module.h
  #include linux/of.h
  #include linux/of_address.h
 +#include linux/of_gpio.h
  #include linux/phy/phy.h
  #include linux/platform_device.h
  #include linux/mutex.h
 @@ -176,6 +177,7 @@ struct exynos5_usbdrd_phy {
   struct clk *ref_clk;
   unsigned long ref_rate;
   unsigned int refclk_reg;
 + int gpio;
  };

  #define to_usbdrd_phy(inst) \
 @@ -460,6 +462,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
   if (!IS_ERR(phy_drd-usb30_sclk))
   clk_prepare_enable(phy_drd-usb30_sclk);

 + /* Toggle VBUS gpio - on */
 + gpio_set_value(phy_drd-gpio, 1);

 It seems like you'd be better off using a regulator_enable() call for
 this.

Sure, i will use a regulator for this vbus settings.


-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/4] regulator: s2mps11: Move DTS parsing code to separate function

2014-04-14 Thread Krzysztof Kozlowski
Refactor code for parsing DTS to increase a little code readability. The
behaviour should not change.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 drivers/regulator/s2mps11.c | 35 +++
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index e713c162fbd4..3aba0331fb5d 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -565,12 +565,28 @@ static const struct regulator_desc s2mps14_regulators[] = 
{
regulator_desc_s2mps14_buck1235(5),
 };
 
+static int s2mps11_pmic_dt_parse(struct platform_device *pdev,
+   struct of_regulator_match *rdata, struct s2mps11_info *s2mps11)
+{
+   struct device_node *reg_np;
+
+   reg_np = of_get_child_by_name(pdev-dev.parent-of_node, regulators);
+   if (!reg_np) {
+   dev_err(pdev-dev, could not find regulators sub-node\n);
+   return -EINVAL;
+   }
+
+   of_regulator_match(pdev-dev, reg_np, rdata, s2mps11-rdev_num);
+   of_node_put(reg_np);
+
+   return 0;
+}
+
 static int s2mps11_pmic_probe(struct platform_device *pdev)
 {
struct sec_pmic_dev *iodev = dev_get_drvdata(pdev-dev.parent);
-   struct sec_platform_data *pdata = iodev-pdata;
+   struct sec_platform_data *pdata = NULL;
struct of_regulator_match *rdata = NULL;
-   struct device_node *reg_np = NULL;
struct regulator_config config = { };
struct s2mps11_info *s2mps11;
int i, ret = 0;
@@ -598,7 +614,8 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
};
 
if (!iodev-dev-of_node) {
-   if (pdata) {
+   if (iodev-pdata) {
+   pdata = iodev-pdata;
goto common_reg;
} else {
dev_err(pdev-dev.parent,
@@ -614,15 +631,9 @@ static int s2mps11_pmic_probe(struct platform_device *pdev)
for (i = 0; i  s2mps11-rdev_num; i++)
rdata[i].name = regulators[i].name;
 
-   reg_np = of_get_child_by_name(iodev-dev-of_node, regulators);
-   if (!reg_np) {
-   dev_err(pdev-dev, could not find regulators sub-node\n);
-   ret = -EINVAL;
+   ret = s2mps11_pmic_dt_parse(pdev, rdata, s2mps11);
+   if (ret)
goto out;
-   }
-
-   of_regulator_match(pdev-dev, reg_np, rdata, s2mps11-rdev_num);
-   of_node_put(reg_np);
 
 common_reg:
platform_set_drvdata(pdev, s2mps11);
@@ -633,7 +644,7 @@ common_reg:
for (i = 0; i  s2mps11-rdev_num; i++) {
struct regulator_dev *regulator;
 
-   if (!reg_np) {
+   if (pdata) {
config.init_data = pdata-regulators[i].initdata;
config.of_node = pdata-regulators[i].reg_node;
} else {
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/4] Documentation: regulator: s2mps11: Document external GPIO control

2014-04-14 Thread Krzysztof Kozlowski
Add documentation for new property for controlling (enable/disable) some
of the S2MPS14 regulators by GPIO.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: devicet...@vger.kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 802e839b0829..d81ba30c0d8b 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -56,6 +56,20 @@ for a particular group of BUCKs. So provide same 
regulator-ramp-delayvalue.
 Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
 BUCK[3, 4], and BUCK[7, 8, 10]
 
+On S2MPS14 the LDO10, LDO11 and LDO12 can be configured to external control
+over GPIO. To turn this feature on this property must be added to the regulator
+sub-node:
+   - samsung,ext-control-gpios: GPIO specifier for one GPIO
+   controlling this regulator (enable/disable);
+Example:
+   LDO12 {
+   regulator-name = V_EMMC_2.8V;
+   regulator-min-microvolt = 280;
+   regulator-max-microvolt = 280;
+   samsung,ext-control-gpios = gpk0 2 0;
+   };
+
+
 The regulator constraints inside the regulator nodes use the standard regulator
 bindings which are documented elsewhere.
 
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit

2014-04-14 Thread Andrzej Hajda
On 04/12/2014 04:18 PM, Inki Dae wrote:
 Hi Andrzej,

 Thanks for your contributions.

 2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
 Hi Inki,

 This patchset refactors drm device initialization. Details are described
 in respective patches. It is an alternative to DT supernode concept.

 The first patch uses linker sections to get rid of ifdef macros, it is not
 That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this way.

 essential for 2nd patch but it makes code more readable. Similar approach
 is used by irqchip, clks and clk_sources.
 But 2nd patch doesn't seem reasnoable to me. Your approach is same as
 existing one conceptually. I think we need to handle drm driver in a
 different way from irqchip, clks and clk_sources.

 DRM driver means one integrated graphics card but in most embedded
 systems, graphics and display relevant devices have separated hardware
 resources. So we would need abstractional integrated hardware,
 display-subsystem, super device. That is why I are trying to use super
 device approach, and conceptually it would be right solution. It
 wouldn't be not good to combine those separated hardware somehow using
 specific codes.

Conceptually both approaches are the same: we have number of devices
which should be ready before we can start super-device and if any device
is to be removed super-device should be removed before.
The difference is in 'details':
- super-node approach have list of components provided explicitly in DT
special node,
- in this approach list of components is constructed from devices
present in the
system.

Creating special DT node with information which is available anyway seems
to be redundant and against DT rules.

Regarding the old approach, I would not compare it with the current ones
as it has two main flaws:
- it is not aware of deferred probing, or more precisely it assumes that
driver registration
instantly triggers device probing (it happens to be true) and no probe
of drm component
will happen later (and this is false assumption, eg. deferred probe),
- it do not remove super-device in case of removal of any of components.

Regards
Andrzej


 I have updated and tested super device approach with existing dt
 support so there wouldn't be any dt broken issue. I will post next
 version of this patch series soon, maybe tomorrow or the day after
 tomorrow.

 Thanks,
 Inki Dae

 The patchset is based on exynos-drm-next branch.

 Regards
 Andrzej


 Andrzej Hajda (2):
   drm/exynos: refactor drm drivers registration code
   drm/exynos: initialize drm master only when all exynos drm devices are
 ready

  drivers/gpu/drm/exynos/Makefile |   2 +
  drivers/gpu/drm/exynos/exynos_dp_core.c |  37 ++--
  drivers/gpu/drm/exynos/exynos_drm.lds.S |   9 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 279 
 +---
  drivers/gpu/drm/exynos/exynos_drm_drv.h |  20 +-
  drivers/gpu/drm/exynos/exynos_drm_dsi.c |  42 +++--
  drivers/gpu/drm/exynos/exynos_drm_fimc.c|  35 ++--
  drivers/gpu/drm/exynos/exynos_drm_fimd.c|  38 ++--
  drivers/gpu/drm/exynos/exynos_drm_g2d.c |  17 +-
  drivers/gpu/drm/exynos/exynos_drm_gsc.c |  30 +--
  drivers/gpu/drm/exynos/exynos_drm_ipp.c |  18 +-
  drivers/gpu/drm/exynos/exynos_drm_rotator.c |  27 ++-
  drivers/gpu/drm/exynos/exynos_drm_vidi.c|  18 +-
  drivers/gpu/drm/exynos/exynos_hdmi.c|  53 --
  drivers/gpu/drm/exynos/exynos_mixer.c   |  14 +-
  15 files changed, 360 insertions(+), 279 deletions(-)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm.lds.S

 --
 1.8.3.2

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V5 00/20] ARM: exynos: cpuidle: Move the driver to drivers/cpuidle

2014-04-14 Thread Daniel Lezcano


Hi Kukjin,

I believe I addressed all the comments. Is it possible to take this 
patchset for next ?


Regards

  -- Daniel



On 04/11/2014 12:39 PM, Daniel Lezcano wrote:

Changelog:

V5:
* Removed patch : Move clock setup to pm.c
* Added patch   : Move arm core power down clock to exynos5250 common 
code
V4:
* Took into account Tomasz's comments
* Fixed missing call in for central suspend
* Passed parameter to the wakeup mask function
* Moved wakeup mask, boot vector and aftr state into a single
function
* Used this function as callback for platform data
* Moved S5P_CHECK_AFTR/S5P_CHECK_SLEEP into pm.c
* Set boot vector only one time
* Splitted some patches to make them more readable
V3:
* Added patch   : ARM: exynos: cpuidle: Disable cpuidle for 5440
* Removed patch : ARM: exynos: config: Enable cpuidle
* Removed default ARM_EXYNOS4210_CPUIDLE=y
* Added comment about bug fix side effect 'for_each_possible_cpu'
V2:
* Added comment in changelog for calls order (5/17)
* Call the powerdown only for cpu0 in the pm notifier
* Set the pm notifier for all boards

V1: initial post

This patchset relies on the cpm_pm notifier to initiate the powerdown sequence
operations from pm.c instead cpuidle.c. Thus the cpuidle driver is no longer
dependent from arch specific code as everything is called from the pm.c file.

The patchset applies on top of linux-samsung/for-next.

Tested on exynos4: 4210
Tested on exynos5: 5250 (without AFTR)

Amit Daniel Kachhap (1):
   ARM: EXYNOS: Move arm core power down clock to exynos5250 common
 clock

Daniel Lezcano (19):
   ARM: exynos: cpuidle: Prevent forward declaration
   ARM: exynos: cpuidle: Use cpuidle_register
   ARM: exynos: cpuidle: Change function name prefix
   ARM: exynos: cpuidle: Encapsulate register access inside a function
   ARM: exynos: cpuidle: Move some code inside the idle_finisher
   ARM: exynos: cpuidle: Fix S5P_WAKEUP_STAT call
   ARM: exynos: cpuidle: Use the cpu_pm notifier
   ARM: exynos: cpuidle: Move scu_enable in the cpu_pm notifier
   ARM: exynos: cpuidle: Remove ifdef for scu_enable
   ARM: exynos: cpuidle: Pass wakeup mask parameter to function
   ARM: exynos: cpuidle: Encapsulate boot vector code into a function
   ARM: exynos: cpuidle: Disable cpuidle for 5440
   ARM: exynos: cpuidle: Encapsulate the AFTR code into a function
   ARM: exynos: cpuidle: Move the AFTR state function into pm.c
   ARM: exynos: cpuidle: Move the power sequence call in the cpu_pm
 notifier
   ARM: exynos: cpuidle: Move S5P_CHECK_SLEEP into pm.c
   ARM: exynos: cpuidle: Pass the AFTR callback to the platform_data
   ARM: exynos: cpuidle: Cleanup all unneeded headers from cpuidle.c
   ARM: exynos: cpuidle: Move the driver to drivers/cpuidle directory

  arch/arm/mach-exynos/Makefile|1 -
  arch/arm/mach-exynos/common.h|1 +
  arch/arm/mach-exynos/cpuidle.c   |  255 --
  arch/arm/mach-exynos/exynos.c|8 +-
  arch/arm/mach-exynos/pm.c|  152 
  arch/arm/mach-exynos/regs-pmu.h  |2 -
  drivers/clk/samsung/clk-exynos5250.c |   42 ++
  drivers/cpuidle/Kconfig.arm  |6 +
  drivers/cpuidle/Makefile |1 +
  drivers/cpuidle/cpuidle-exynos.c |   98 +
  10 files changed, 277 insertions(+), 289 deletions(-)
  delete mode 100644 arch/arm/mach-exynos/cpuidle.c
  create mode 100644 drivers/cpuidle/cpuidle-exynos.c




--
 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

--
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


[PATCHv2 0/2] iio: adc: exynos_adc: Support Exynos3250 ADC

2014-04-14 Thread Chanwoo Choi
This patchset support Exynos3250 ADC (Analog Digital Converter) because
Exynos3250 has additional special clock for ADC IP.

Changes from v1:
- Add new samsung,exynos-adc-v3 compatible to support Exynos3250 ADC
- Add a patch about DT binding documentation

Chanwoo Choi (2):
  iio: adc: exynos_adc: Control special clock of ADC to support Exynos3250 ADC
  iio: devicetree: Add DT binding documentation for Exynos3250 ADC

 .../devicetree/bindings/arm/samsung/exynos-adc.txt | 20 
 drivers/iio/adc/exynos_adc.c   | 54 --
 2 files changed, 61 insertions(+), 13 deletions(-)

-- 
1.8.0

--
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


[PATCHv2 2/2] iio: devicetree: Add DT binding documentation for Exynos3250 ADC

2014-04-14 Thread Chanwoo Choi
This patch add DT binding documentation for Exynos3250 ADC IP. Exynos3250 has
special clock ('sclk_tsadc') for ADC which provide clock to internal ADC.

Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Randy Dunlap rdun...@infradead.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 .../devicetree/bindings/arm/samsung/exynos-adc.txt   | 20 
 1 file changed, 20 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..7532ec3 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -14,6 +14,8 @@ Required properties:
for exynos4412/5250 controllers.
Must be samsung,exynos-adc-v2 for
future controllers.
+   Must be samsung,exynos-adc-v3 for
+   for exynos3250 controllers.
 - reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
 - interrupts:  Contains the interrupt information for the timer. The
@@ -21,7 +23,11 @@ Required properties:
the Samsung device uses.
 - #io-channel-cells = 1; As ADC has multiple outputs
 - clocks   From common clock binding: handle to adc clock.
+   From common clock binding: handle to sclk_tsadc clock
+   if using Exynos3250.
 - clock-names  From common clock binding: Shall be adc.
+   From common clock binding: Shall be sclk_tsadc
+   if using Exynos3250.
 - vdd-supply   VDD input supply.
 
 Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +47,20 @@ adc: adc@12D1 {
vdd-supply = buck5_reg;
 };
 
+If Exynos3250 uses ADC,
+adc: adc@126C {
+   compatible = samsung,exynos-adc-v3;
+   reg = 0x126C 0x100, 0x10020718 0x4;
+   interrupts = 0 137 0;
+   #io-channel-cells = 1;
+   io-channel-ranges;
+
+   clock-names = adc, sclk_tsadc;
+   clocks = cmu CLK_TSADC, cmu CLK_SCLK_TSADC;
+
+   vdd-supply = buck5_reg;
+};
+
 
 Example: Adding child nodes in dts file
 
-- 
1.8.0

--
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 7/8] arm64: mm: Implement 4 levels of translation tables

2014-04-14 Thread Steve Capper
On Mon, Apr 13, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
 This patch implements 4 levels of translation tables since 3 levels
 of page tables with 4KB pages cannot support 40-bit physical address
 space described in [1] due to the following issue.
 
 It is a restriction that kernel logical memory map with 4KB + 3 levels
 (0xffc0-0x) cannot cover RAM region from
 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
 mapping for this region in map_mem function since __phys_to_virt for
 this region reaches to address overflow.
 
 If SoC design follows the document, [1], over 32GB RAM would be placed
 from 544GB. Even 64GB system is supposed to use the region from 544GB
 to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
 of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
 
 However, it is recommended 4 levels of page table should be only enabled
 if memory map is too sparse or there is about 512GB RAM.

Hi,
So I thought I'd apply this series and have a play, this patch doesn't apply
cleanly for me, please see below why...

[ ... ]

 diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
 index 0fd5650..0b0b16a 100644
 --- a/arch/arm64/kernel/head.S
 +++ b/arch/arm64/kernel/head.S
 @@ -46,8 +46,8 @@
  #error KERNEL_RAM_VADDR must start at 0xXXX8
  #endif
  
 -#define SWAPPER_DIR_SIZE (3 * PAGE_SIZE)
 -#define IDMAP_DIR_SIZE   (2 * PAGE_SIZE)
 +#define SWAPPER_DIR_SIZE (4 * PAGE_SIZE)
 +#define IDMAP_DIR_SIZE   (3 * PAGE_SIZE)
  
   .globl  swapper_pg_dir
   .equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE
 @@ -384,6 +384,20 @@ ENDPROC(__calc_phys_offset)
   .endm
  
  /*
 + * Macro to populate the PUD for the corresponding block entry in the next
 + * level (tbl) for the given virtual address.
 + *
 + * Preserves:pud, tbl, virt
 + * Corrupts: tmp1, tmp2
 + */
 + .macro create_pud_entry, pud, tbl, virt, tmp1, tmp2
 + lsr \tmp1, \virt, #PUD_SHIFT
 + and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index
 + orr \tmp2, \tbl, #3 // PUD entry table type
 + str \tmp2, [\pud, \tmp1, lsl #3]
 + .endm
 +
 +/*
   * Macro to populate block entries in the page table for the start..end
   * virtual range (inclusive).
   *
 @@ -445,10 +459,18 @@ __create_page_tables:
   ldr x3, =KERNEL_START
   add x3, x3, x28 // __pa(KERNEL_START)

I don't think we have C++ style comments in the kernel. Also, I can't see
any references to =KERNEL_START in arch/arm64/kernel/head.S (from 3.14 down).

   create_pgd_entry x25, x0, x3, x5, x6
 +#ifdef CONFIG_ARM64_4_LEVELS
 + add x1, x0, #PAGE_SIZE
 + create_pud_entry x0, x1, x3, x5, x6
 +#endif
   ldr x6, =KERNEL_END
   mov x5, x3  // __pa(KERNEL_START)
   add x6, x6, x28 // __pa(KERNEL_END)
 +#ifndef CONFIG_ARM64_4_LEVELS
   create_block_map x0, x7, x3, x5, x6
 +#else
 + create_block_map x1, x7, x3, x5, x6
 +#endif
  
   /*
* Map the kernel image (starting with PHYS_OFFSET).
 @@ -456,9 +478,17 @@ __create_page_tables:
   add x0, x26, #PAGE_SIZE // section table address
   mov x5, #PAGE_OFFSET
   create_pgd_entry x26, x0, x5, x3, x6
 +#ifdef CONFIG_ARM64_4_LEVELS
 + add x1, x0, #PAGE_SIZE
 + create_pud_entry x0, x1, x3, x5, x6
 +#endif
   ldr x6, =KERNEL_END
   mov x3, x24 // phys offset
 +#ifndef CONFIG_ARM64_4_LEVELS
   create_block_map x0, x7, x3, x5, x6
 +#else
 + create_block_map x1, x7, x3, x5, x6
 +#endif
  
   /*
* Map the FDT blob (maximum 2MB; must be within 512MB of
 @@ -474,14 +504,25 @@ __create_page_tables:
   add x5, x5, x6  // __va(FDT blob)
   add x6, x5, #1  21// 2MB for the FDT blob
   sub x6, x6, #1  // inclusive range
 +#ifndef CONFIG_ARM64_4_LEVELS
   create_block_map x0, x7, x3, x5, x6
 +#else
 + create_block_map x1, x7, x3, x5, x6
 +#endif
  1:
   /*
* Create the pgd entry for the fixed mappings.
*/
   ldr x5, =FIXADDR_TOP// Fixed mapping virtual address
 +#ifndef CONFIG_ARM64_4_LEVELS
   add x0, x26, #2 * PAGE_SIZE // section table address
   create_pgd_entry x26, x0, x5, x6, x7
 +#else
 + add x0, x26, #PAGE_SIZE
 + create_pgd_entry x26, x0, x5, x6, x7
 + add x1, x0, #2 * PAGE_SIZE
 + create_pud_entry x0, x1, x5, x6, x7
 +#endif
  
   /*
* Since the page tables have been populated with non-cacheable

What tree is this series based on?

Thanks,
-- 
Steve
--
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  

Re: [PATCH 7/8] arm64: mm: Implement 4 levels of translation tables

2014-04-14 Thread Jungseok Lee
On Monday, April 14, 2014 6:34 PM, Steve Capper wrote:
 On Mon, Apr 14, 2014 at 06:24:55PM +0900, Jungseok Lee wrote:
  On Monday, April 14, 2014 6:14 PM, Steve Capper wrote:
   On Mon, Apr 13, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
This patch implements 4 levels of translation tables since 3
levels of page tables with 4KB pages cannot support 40-bit
physical address space described in [1] due to the following issue.
   
It is a restriction that kernel logical memory map with 4KB + 3
levels
(0xffc0-0x) cannot cover RAM region
from 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to
create mapping for this region in map_mem function since
__phys_to_virt for this region reaches to address overflow.
   
If SoC design follows the document, [1], over 32GB RAM would be
placed from 544GB. Even 64GB system is supposed to use the region
from 544GB to 576GB for only 32GB RAM. Naturally, it would reach
to enable 4 levels of page tables to avoid hacking __virt_to_phys and 
__phys_to_virt.
   
However, it is recommended 4 levels of page table should be only
enabled if memory map is too sparse or there is about 512GB RAM.
  
   Hi,
   So I thought I'd apply this series and have a play, this patch
   doesn't apply cleanly for me, please see below why...
 
  This pathset is based on 3.15-rc1.
 
 Thanks, yes that applies cleanly for me now.

Okay, it sounds good.

 
   [ ... ]
  
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 0fd5650..0b0b16a 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -46,8 +46,8 @@
 #error KERNEL_RAM_VADDR must start at 0xXXX8  #endif
   
-#define SWAPPER_DIR_SIZE   (3 * PAGE_SIZE)
-#define IDMAP_DIR_SIZE (2 * PAGE_SIZE)
+#define SWAPPER_DIR_SIZE   (4 * PAGE_SIZE)
+#define IDMAP_DIR_SIZE (3 * PAGE_SIZE)
   
.globl  swapper_pg_dir
.equswapper_pg_dir, KERNEL_RAM_VADDR - SWAPPER_DIR_SIZE
@@ -384,6 +384,20 @@ ENDPROC(__calc_phys_offset)
.endm
   
 /*
+ * Macro to populate the PUD for the corresponding block entry in
+the next
+ * level (tbl) for the given virtual address.
+ *
+ * Preserves:  pud, tbl, virt
+ * Corrupts:   tmp1, tmp2
+ */
+   .macro create_pud_entry, pud, tbl, virt, tmp1, tmp2
+   lsr \tmp1, \virt, #PUD_SHIFT
+   and \tmp1, \tmp1, #PTRS_PER_PUD - 1 // PUD index
+   orr \tmp2, \tbl, #3 // PUD entry table type
+   str \tmp2, [\pud, \tmp1, lsl #3]
+   .endm
+
+/*
  * Macro to populate block entries in the page table for the start..end
  * virtual range (inclusive).
  *
@@ -445,10 +459,18 @@ __create_page_tables:
ldr x3, =KERNEL_START
add x3, x3, x28 // __pa(KERNEL_START)
  
   I don't think we have C++ style comments in the kernel. Also, I
   can't see any references to =KERNEL_START in arch/arm64/kernel/head.S 
   (from 3.14 down).
 
  C++ style comments are prevalent in arch/arm64/kernel/head.S. I've
  C++ followed the
  code style written previously.
 
 Apologies, my mistake, I've been staring at arch/arm too long where @ is used.

It's okay.

Best Regards
Jungseok Lee

--
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] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

2014-04-14 Thread Tomasz Stanislawski
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e1a2e88..300c2af 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2011,23 +2011,18 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 {
struct device_node *np = dev-of_node;
struct s5p_hdmi_platform_data *pd;
-   u32 value;

pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
-   goto err_data;
+   return NULL;

-   if (!of_find_property(np, hpd-gpio, value)) {
+   pd-hpd_gpio = of_get_named_gpio_flags(np, hpd-gpio, 0, NULL);
+   if (pd-hpd_gpio  0) {
DRM_ERROR(no hpd gpio property found\n);
-   goto err_data;
+   return NULL;
}

-   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
return pd;
-
-err_data:
-   return NULL;
 }

 static struct of_device_id hdmi_match_types[] = {

--
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 v2 2/6] PCI: tegra: use new OF interrupt mapping when possible

2014-04-14 Thread Srikanth Thokala
On Sat, Apr 12, 2014 at 2:11 AM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
 On Fri, Apr 11, 2014 at 11:10:59PM +0530, Srikanth Thokala wrote:

 I see this error too on my setup (Xilinx PCIe Root Complex Driver),
 https://lkml.org/lkml/2014/3/3/183

 After digging into it, I see I need to override the API
 pcibios_get_phb_of_node()

 No, as I pointed out before, the DT node comes in through
 pci_scan_root_bus:

Thanks Jason for the advice, it is working.

Srikanth


 +static struct pci_bus __init *xilinx_pcie_scan_bus(int nr,
 +   struct pci_sys_data *sys)
 +{
 +   struct xilinx_pcie_port *port = sys_to_pcie(sys);
 +   struct pci_bus *bus;
 +
 +   if (port) {
 +   port-root_busno = sys-busnr;
 +   bus = pci_scan_root_bus(NULL, sys-busnr, xilinx_pcie_ops,
^^

 You can't pass NULL here and have DT work properly.

 See http://www.spinics.net/lists/arm-kernel/msg312392.html

 Jason
--
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 RFC 0/2] drm/exynos: refactoring drm device init/deinit

2014-04-14 Thread Inki Dae


 -Original Message-
 From: Andrzej Hajda [mailto:a.ha...@samsung.com]
 Sent: Monday, April 14, 2014 5:55 PM
 To: Inki Dae
 Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...;
 Kyungmin Park; Marek Szyprowski
 Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
 init/deinit
 
 On 04/12/2014 04:18 PM, Inki Dae wrote:
  Hi Andrzej,
 
  Thanks for your contributions.
 
  2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
  Hi Inki,
 
  This patchset refactors drm device initialization. Details are
  described in respective patches. It is an alternative to DT supernode
 concept.
 
  The first patch uses linker sections to get rid of ifdef macros, it
  is not
  That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this
way.
 
  essential for 2nd patch but it makes code more readable. Similar
  approach is used by irqchip, clks and clk_sources.
  But 2nd patch doesn't seem reasnoable to me. Your approach is same as
  existing one conceptually. I think we need to handle drm driver in a
  different way from irqchip, clks and clk_sources.
 
  DRM driver means one integrated graphics card but in most embedded
  systems, graphics and display relevant devices have separated hardware
  resources. So we would need abstractional integrated hardware,
  display-subsystem, super device. That is why I are trying to use super
  device approach, and conceptually it would be right solution. It
  wouldn't be not good to combine those separated hardware somehow using
  specific codes.
 
 Conceptually both approaches are the same: we have number of devices which
 should be ready before we can start super-device and if any device is to
 be removed super-device should be removed before.
 The difference is in 'details':
 - super-node approach have list of components provided explicitly in DT
 special node,
 - in this approach list of components is constructed from devices present
 in the system.
 
 Creating special DT node with information which is available anyway seems
 to be redundant and against DT rules.
 

CCing Russell King,

What is the special DT node? You mean device node from ports property?

It is supposed  to use super device and its properties in mainline so I
don't see what it is against DT rules. If they are really against DT rules,
why component framework is in mainline?

As you said above, conceptually both approaches may be the same but your
approach has no any abstract hardware meaning one integrated hardware. And
if conceptually both approaches are the same, it would be good to use
existing infrastructure, component framework so there is no any reason to
add and use specific codes.

And component framework says,
Subsystems such as ALSA, DRM and others require a single card-level device
structure to represent a subsystem. However, firmware tends to describe the
individual devices and the connections between them. Therefore, we need a
way to gather up the individual component devices together, and indicate
when we have all the component devices.

Thanks,
Inki Dae

 Regarding the old approach, I would not compare it with the current ones
 as it has two main flaws:
 - it is not aware of deferred probing, or more precisely it assumes that
 driver registration instantly triggers device probing (it happens to be
 true) and no probe of drm component will happen later (and this is false
 assumption, eg. deferred probe),
 - it do not remove super-device in case of removal of any of components.
 
 Regards
 Andrzej
 
 
  I have updated and tested super device approach with existing dt
  support so there wouldn't be any dt broken issue. I will post next
  version of this patch series soon, maybe tomorrow or the day after
  tomorrow.
 
  Thanks,
  Inki Dae
 
  The patchset is based on exynos-drm-next branch.
 
  Regards
  Andrzej
 
 
  Andrzej Hajda (2):
drm/exynos: refactor drm drivers registration code
drm/exynos: initialize drm master only when all exynos drm devices
 are
  ready
 
   drivers/gpu/drm/exynos/Makefile |   2 +
   drivers/gpu/drm/exynos/exynos_dp_core.c |  37 ++--
   drivers/gpu/drm/exynos/exynos_drm.lds.S |   9 +
   drivers/gpu/drm/exynos/exynos_drm_drv.c | 279
+
 ---
   drivers/gpu/drm/exynos/exynos_drm_drv.h |  20 +-
   drivers/gpu/drm/exynos/exynos_drm_dsi.c |  42 +++--
   drivers/gpu/drm/exynos/exynos_drm_fimc.c|  35 ++--
   drivers/gpu/drm/exynos/exynos_drm_fimd.c|  38 ++--
   drivers/gpu/drm/exynos/exynos_drm_g2d.c |  17 +-
   drivers/gpu/drm/exynos/exynos_drm_gsc.c |  30 +--
   drivers/gpu/drm/exynos/exynos_drm_ipp.c |  18 +-
   drivers/gpu/drm/exynos/exynos_drm_rotator.c |  27 ++-
   drivers/gpu/drm/exynos/exynos_drm_vidi.c|  18 +-
   drivers/gpu/drm/exynos/exynos_hdmi.c|  53 --
   drivers/gpu/drm/exynos/exynos_mixer.c   |  14 +-
   15 files changed, 360 insertions(+), 279 deletions(-)  create mode
  100644 

Re: [PATCH v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC

2014-04-14 Thread Arnd Bergmann
On Monday 14 April 2014 11:17:38 Tarek Dakhran wrote:
 --- a/arch/arm/mach-exynos/exynos.c
 +++ b/arch/arm/mach-exynos/exynos.c
 @@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[] __initdata = {
 },
  };
  
 +static struct map_desc exynos5410_iodesc[] __initdata = {
 +   {
 +   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
 +   .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
 +   .length = SZ_4K,
 +   .type   = MT_DEVICE,
 +   },
 +};
 +
  static struct map_desc exynos5_iodesc[] __initdata = {

NAK

Why does this keep coming up?

Arnd
--
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 RFC 0/2] drm/exynos: refactoring drm device init/deinit

2014-04-14 Thread Tomasz Figa

Hi Inki,

On 14.04.2014 13:04, Inki Dae wrote:




-Original Message-
From: Andrzej Hajda [mailto:a.ha...@samsung.com]
Sent: Monday, April 14, 2014 5:55 PM
To: Inki Dae
Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS AR...;
Kyungmin Park; Marek Szyprowski
Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
init/deinit

On 04/12/2014 04:18 PM, Inki Dae wrote:

Hi Andrzej,

Thanks for your contributions.

2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:

Hi Inki,

This patchset refactors drm device initialization. Details are
described in respective patches. It is an alternative to DT supernode

concept.


The first patch uses linker sections to get rid of ifdef macros, it
is not

That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this

way.



essential for 2nd patch but it makes code more readable. Similar
approach is used by irqchip, clks and clk_sources.

But 2nd patch doesn't seem reasnoable to me. Your approach is same as
existing one conceptually. I think we need to handle drm driver in a
different way from irqchip, clks and clk_sources.

DRM driver means one integrated graphics card but in most embedded
systems, graphics and display relevant devices have separated hardware
resources. So we would need abstractional integrated hardware,
display-subsystem, super device. That is why I are trying to use super
device approach, and conceptually it would be right solution. It
wouldn't be not good to combine those separated hardware somehow using
specific codes.


Conceptually both approaches are the same: we have number of devices which
should be ready before we can start super-device and if any device is to
be removed super-device should be removed before.
The difference is in 'details':
- super-node approach have list of components provided explicitly in DT
special node,
- in this approach list of components is constructed from devices present
in the system.

Creating special DT node with information which is available anyway seems
to be redundant and against DT rules.



CCing Russell King,

What is the special DT node? You mean device node from ports property?

It is supposed  to use super device and its properties in mainline so I
don't see what it is against DT rules. If they are really against DT rules,
why component framework is in mainline?


Component framework in mainline doesn't have anything in common with DT. 
All it does is providing tools for handling cases where a subsystem can 
be initialized only after all components are available. It doesn't 
define any means of getting the list of components, it's a task for the 
user of this framework to provide it.




As you said above, conceptually both approaches may be the same but your
approach has no any abstract hardware meaning one integrated hardware. And
if conceptually both approaches are the same, it would be good to use
existing infrastructure, component framework so there is no any reason to
add and use specific codes.


What do you mean by abstract hardware? Physically, in the SoC, there 
is no single integrated hardware block, but multiple IPs and they need 
to be described this way in DT. There is nothing that prevents using 
them separately if a user doesn't want to use Exynos DRM. Exynos DRM is 
a Linux-specific thing and its details should not be leaked into DT, 
which is a _hardware_ description method.




And component framework says,
Subsystems such as ALSA, DRM and others require a single card-level device
structure to represent a subsystem. However, firmware tends to describe the
individual devices and the connections between them. Therefore, we need a
way to gather up the individual component devices together, and indicate
when we have all the component devices.


Note following things:

- Nothing in the quote above says that an additional DT node must be 
added. The framework works on generic driver model level, above the 
description level (such as DT).


- Andrzej's method implements the same concept as component framework, 
except that:


  a) it does so in a much more simple way (compare amount of code 
needed for Andrzej's approach and inside component framework),


  b) doesn't require component initialization to be undone on every 
master bring-up failure,


  c) uses the list of drivers known at compilation time to the Exynos 
DRM subsystem to build the list of devices to wait for


  d) doesn't introduce any new DT bindings, for virtual, Linux-specific 
things,


  e) doesn't duplicate compatible strings in an array used only to 
support systems that didn't have nodes required by those new DT bindings 
(as done in your exynos_drm_bind_lagacy_dt()),


  f) doesn't require two-step initialization (probe() and bind()), as 
opposed to component subsystem.


As you can see, it's a pure list of benefits, without any obvious 
drawbacks, except that some generic code (more or less applicable here) 
is not used.


However, I wonder whether some of Andrzej's 

Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Kishon Vijay Abraham I
Hi,

On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
 Hi Vivek,
 
 Please see my comments inline.
 
 On 08.04.2014 16:36, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
   .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
   drivers/phy/Kconfig|   11 +
   drivers/phy/Makefile   |1 +
   drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
   4 files changed, 722 insertions(+)
   create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
 
 [snip]
 
 +Additional clock required for Exynos5420:
 +- usb30_sclk_100m: Additional special clock used for PHY operation
 +   depicted as 'sclk_usbphy30' in CMU of Exynos5420.
 
 Are you sure this isn't simply a gate for the ref clock, as it can be found on
 another SoC that is not upstream yet? I don't have documentation for Exynos
 5420 so I can't tell, but I'd like to ask you to recheck this.
 
 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +  control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to
 pmu-system-controller
 +  base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 +usb3_phy: usbphy@1210 {
 +compatible = samsung,exynos5250-usbdrd-phy;
 +reg = 0x1210 0x100;
 +clocks = clock 286, clock 1;
 +clock-names = phy, usb3phy_refclk;
 
 Binding description above doesn't mention usb3phy_refclk entry.
 
 +samsung,syscon-phandle = pmu_syscon;
 +samsung,pmu-offset = 0x704;
 +#phy-cells = 1;
 +};
 
 [snip]
 
 diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
 b/drivers/phy/phy-exynos5-usbdrd.c
 new file mode 100644
 index 000..ff54a7c
 --- /dev/null
 +++ b/drivers/phy/phy-exynos5-usbdrd.c
 
 [snip]
 
 +static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
 +{
 +struct device *dev = pdev-dev;
 +struct device_node *node = dev-of_node;
 +struct exynos5_usbdrd_phy *phy_drd;
 +struct phy_provider *phy_provider;
 +struct resource *res;
 +const struct of_device_id *match;
 +const struct exynos5_usbdrd_phy_drvdata *drv_data;
 +struct regmap *reg_pmu;
 +u32 pmu_offset;
 +int i;
 +
 +/*
 + * Exynos systems are completely DT enabled,
 + * so lets not have any platform data support for this driver.
 + */
 +if (!node) {
 +dev_err(dev, no device node found\n);
 
 This error message is not very meaningful. I'd rather use something like This
 driver can be only instantiated using Device Tree.

how about just adding depend_on OF in Kconfig?

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 v8 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC

2014-04-14 Thread Tarek Dakhran

On 04/14/2014 03:03 PM, Arnd Bergmann wrote:

On Monday 14 April 2014 11:17:38 Tarek Dakhran wrote:

--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -159,6 +159,15 @@ static struct map_desc exynos5250_iodesc[] __initdata = {
 },
  };
  
+static struct map_desc exynos5410_iodesc[] __initdata = {

+   {
+   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+   .pfn= __phys_to_pfn(EXYNOS5410_PA_SYSRAM_NS),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   },
+};
+
  static struct map_desc exynos5_iodesc[] __initdata = {

NAK

Why does this keep coming up?

Arnd

We need this memory region because boot address for exynos5410 located 
here, same as for 5250.


--
Best regards,
Tarek Dakhran

--
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] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

2014-04-14 Thread Joonyoung Shim

Hi Tomasz,

On 04/14/2014 07:07 PM, Tomasz Stanislawski wrote:

This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
  drivers/gpu/drm/exynos/exynos_hdmi.c |   13 -
  1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e1a2e88..300c2af 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2011,23 +2011,18 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
  {
struct device_node *np = dev-of_node;
struct s5p_hdmi_platform_data *pd;
-   u32 value;

pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
-   goto err_data;
+   return NULL;

-   if (!of_find_property(np, hpd-gpio, value)) {
+   pd-hpd_gpio = of_get_named_gpio_flags(np, hpd-gpio, 0, NULL);


This is same with
pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);


+   if (pd-hpd_gpio  0) {


How about use gpio_is_valid()?


DRM_ERROR(no hpd gpio property found\n);
-   goto err_data;
+   return NULL;
}

-   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
return pd;
-
-err_data:
-   return NULL;
  }

  static struct of_device_id hdmi_match_types[] = {




Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Vivek Gautam
Hi Kishon,


On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi,

 On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
 Hi Vivek,

 Please see my comments inline.

 On 08.04.2014 16:36, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
   .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
   drivers/phy/Kconfig|   11 +
   drivers/phy/Makefile   |1 +
   drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
   4 files changed, 722 insertions(+)
   create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

 [snip]

 +Additional clock required for Exynos5420:
 +- usb30_sclk_100m: Additional special clock used for PHY operation
 +   depicted as 'sclk_usbphy30' in CMU of Exynos5420.

 Are you sure this isn't simply a gate for the ref clock, as it can be found 
 on
 another SoC that is not upstream yet? I don't have documentation for Exynos
 5420 so I can't tell, but I'd like to ask you to recheck this.

 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +  control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to
 pmu-system-controller
 +  base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 +usb3_phy: usbphy@1210 {
 +compatible = samsung,exynos5250-usbdrd-phy;
 +reg = 0x1210 0x100;
 +clocks = clock 286, clock 1;
 +clock-names = phy, usb3phy_refclk;

 Binding description above doesn't mention usb3phy_refclk entry.

 +samsung,syscon-phandle = pmu_syscon;
 +samsung,pmu-offset = 0x704;
 +#phy-cells = 1;
 +};

 [snip]

 diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
 b/drivers/phy/phy-exynos5-usbdrd.c
 new file mode 100644
 index 000..ff54a7c
 --- /dev/null
 +++ b/drivers/phy/phy-exynos5-usbdrd.c

 [snip]

 +static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
 +{
 +struct device *dev = pdev-dev;
 +struct device_node *node = dev-of_node;
 +struct exynos5_usbdrd_phy *phy_drd;
 +struct phy_provider *phy_provider;
 +struct resource *res;
 +const struct of_device_id *match;
 +const struct exynos5_usbdrd_phy_drvdata *drv_data;
 +struct regmap *reg_pmu;
 +u32 pmu_offset;
 +int i;
 +
 +/*
 + * Exynos systems are completely DT enabled,
 + * so lets not have any platform data support for this driver.
 + */
 +if (!node) {
 +dev_err(dev, no device node found\n);

 This error message is not very meaningful. I'd rather use something like 
 This
 driver can be only instantiated using Device Tree.

 how about just adding depend_on OF in Kconfig?

Already added a depend on 'OF'. Copying below the part of Kconfig in this patch.

  config PHY_EXYNOS5_USBDRD
 tristate Exynos5 SoC series USB DRD PHY driver
 depends on ARCH_EXYNOS5  OF
 depends on HAS_IOMEM
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Kishon Vijay Abraham I
Hi,

On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.
 
 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
  drivers/phy/Kconfig|   11 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
  4 files changed, 722 insertions(+)
  create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
 
 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 28f9edb..6d99ba9 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -74,3 +74,45 @@ phy-consumer@1234 {
  
  Refer to DT bindings documentation of particular PHY consumer devices for 
 more
  information about required PHYs and the way of specification.
 +
 +Samsung Exynos5 SoC series USB DRD PHY controller
 +--
 +
 +Required properties:
 +- compatible : Should be set to one of the following supported values:
 + - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
 + - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
 +- reg : Register offset and length of USB DRD PHY register set;
 +- clocks: Clock IDs array as required by the controller
 +- clock-names: names of clocks correseponding to IDs in the clock property;
 +Required clocks:
 + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
 +used for register access.
 + - ref: PHY's reference clock (usually crystal clock), associated by
 +phy name, used to determine bit values for clock settings
 +register.
 + Additional clock required for Exynos5420:
 + - usb30_sclk_100m: Additional special clock used for PHY operation
 +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +   control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to 
 pmu-system-controller
 +   base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 + usb3_phy: usbphy@1210 {
 + compatible = samsung,exynos5250-usbdrd-phy;
 + reg = 0x1210 0x100;
 + clocks = clock 286, clock 1;
 + clock-names = phy, usb3phy_refclk;
 + samsung,syscon-phandle = pmu_syscon;
 + samsung,pmu-offset = 0x704;
 + #phy-cells = 1;
 + };
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 8d3c49c..d955a05 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -166,4 +166,15 @@ config PHY_XGENE
   help
 This option enables support for APM X-Gene SoC multi-purpose PHY.
  
 +config PHY_EXYNOS5_USBDRD
 + tristate Exynos5 SoC series USB DRD PHY driver
 + depends on ARCH_EXYNOS5  OF
 + depends on HAS_IOMEM
 + select GENERIC_PHY
 + select MFD_SYSCON

Lets try to avoid select in Kconfig. We've got enough problems with that.
 + help
 +   Enable USB DRD PHY support for Exynos 5 SoC series.
 +   This driver provides PHY interface for USB 3.0 DRD controller
 +   present on Exynos5 SoC series.
 +
  endmenu
 diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
 index 2faf78e..31baa0c 100644
 --- a/drivers/phy/Makefile
 +++ b/drivers/phy/Makefile
 @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2)   += phy-exynos4210-usb2.o
  obj-$(CONFIG_PHY_EXYNOS4X12_USB2)+= phy-exynos4x12-usb2.o
  obj-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o
  obj-$(CONFIG_PHY_XGENE)  += phy-xgene.o
 +obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
 diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
 b/drivers/phy/phy-exynos5-usbdrd.c
 new file mode 100644
 index 000..ff54a7c
 --- /dev/null
 +++ b/drivers/phy/phy-exynos5-usbdrd.c
 @@ -0,0 +1,668 @@
 +/*
 + * Samsung EXYNOS5 SoC series USB DRD PHY driver
 + *
 + * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
 + *
 + * Copyright (C) 2013 Samsung Electronics Co., Ltd.

2014 already ;-)
 + * Author: Vivek Gautam gautam.vi...@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * 

Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Vivek Gautam
Hi,


On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi,

 On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
  drivers/phy/Kconfig|   11 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
  4 files changed, 722 insertions(+)
  create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 28f9edb..6d99ba9 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -74,3 +74,45 @@ phy-consumer@1234 {

  Refer to DT bindings documentation of particular PHY consumer devices for 
 more
  information about required PHYs and the way of specification.
 +
 +Samsung Exynos5 SoC series USB DRD PHY controller
 +--
 +
 +Required properties:
 +- compatible : Should be set to one of the following supported values:
 + - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
 + - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
 +- reg : Register offset and length of USB DRD PHY register set;
 +- clocks: Clock IDs array as required by the controller
 +- clock-names: names of clocks correseponding to IDs in the clock property;
 +Required clocks:
 + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
 +used for register access.
 + - ref: PHY's reference clock (usually crystal clock), associated by
 +phy name, used to determine bit values for clock settings
 +register.
 + Additional clock required for Exynos5420:
 + - usb30_sclk_100m: Additional special clock used for PHY operation
 +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +   control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to 
 pmu-system-controller
 +   base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 + usb3_phy: usbphy@1210 {
 + compatible = samsung,exynos5250-usbdrd-phy;
 + reg = 0x1210 0x100;
 + clocks = clock 286, clock 1;
 + clock-names = phy, usb3phy_refclk;
 + samsung,syscon-phandle = pmu_syscon;
 + samsung,pmu-offset = 0x704;
 + #phy-cells = 1;
 + };
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 8d3c49c..d955a05 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -166,4 +166,15 @@ config PHY_XGENE
   help
 This option enables support for APM X-Gene SoC multi-purpose PHY.

 +config PHY_EXYNOS5_USBDRD
 + tristate Exynos5 SoC series USB DRD PHY driver
 + depends on ARCH_EXYNOS5  OF
 + depends on HAS_IOMEM
 + select GENERIC_PHY
 + select MFD_SYSCON

 Lets try to avoid select in Kconfig. We've got enough problems with that.

I hope you meant with select MFD_SYSCON.
We are referencing the syscon for accessing pmu reg, for which we need
this config to be selected.
Other Exynos phy drivers also need this config and for that they have
selected this.

Do you want me to do it any other way ?

 + help
 +   Enable USB DRD PHY support for Exynos 5 SoC series.
 +   This driver provides PHY interface for USB 3.0 DRD controller
 +   present on Exynos5 SoC series.
 +
  endmenu
 diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
 index 2faf78e..31baa0c 100644
 --- a/drivers/phy/Makefile
 +++ b/drivers/phy/Makefile
 @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2)   += 
 phy-exynos4210-usb2.o
  obj-$(CONFIG_PHY_EXYNOS4X12_USB2)+= phy-exynos4x12-usb2.o
  obj-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o
  obj-$(CONFIG_PHY_XGENE)  += phy-xgene.o
 +obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
 diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
 b/drivers/phy/phy-exynos5-usbdrd.c
 new file mode 100644
 index 000..ff54a7c
 --- /dev/null
 +++ b/drivers/phy/phy-exynos5-usbdrd.c
 @@ -0,0 

[PATCH 2/4] ARM: dts: exynos4: add exynos_usbphy node

2014-04-14 Thread Chanho Park
This patch enables a exynos_usbphy node for exynos4 SoCs.
A exynos4x12 usb phy node is almost same with 4210's one
except compatible string and pmu syscon.

Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
 arch/arm/boot/dts/exynos4.dtsi| 10 ++
 arch/arm/boot/dts/exynos4x12.dtsi |  5 +
 2 files changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e565b86..0e32d7f 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -278,6 +278,16 @@
status = disabled;
};
 
+   exynos_usbphy: exynos-usbphy@125B {
+   compatible = samsung,exynos4210-usb2-phy;
+   reg = 0x125B 0x100;
+   samsung,pmureg-phandle = pmu_reg;
+   clocks = clock 305, clock 2;
+   clock-names = phy, ref;
+   status = disabled;
+   #phy-cells = 1;
+   };
+
ehci@1258 {
compatible = samsung,exynos4210-ehci;
reg = 0x1258 0x100;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi 
b/arch/arm/boot/dts/exynos4x12.dtsi
index c4a9306..3d77a40 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -243,4 +243,9 @@
clock-names = biu, ciu;
status = disabled;
};
+
+   exynos-usbphy@125B {
+   compatible = samsung,exynos4x12-usb2-phy;
+   samsung,sysreg-phandle = sys_reg;
+   };
 };
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 4/4] ARM: dts: exynos4412-trats2: enable usb nodes

2014-04-14 Thread Chanho Park
This patch enables exynos_usbphy and hsotg device nodes.

Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 9583563..a16db6c 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -665,6 +665,16 @@
};
};
 
+   exynos-usbphy@125B {
+   status = okay;
+   };
+
+   hsotg@1248 {
+   vusb_d-supply = ldo15_reg;
+   vusb_a-supply = ldo12_reg;
+   status = okay;
+   };
+
thermistor-ap@0 {
compatible = ntc,ncp15wb473;
pullup-uv = 180;   /* VCC_1.8V_AP */
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 3/4] ARM: dts: exynos4: add hsotg device node

2014-04-14 Thread Chanho Park
This patch adds a hsotg node for exynos4 USB2.0 device controller.

Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
 arch/arm/boot/dts/exynos4.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 0e32d7f..e541ecb 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -288,6 +288,17 @@
#phy-cells = 1;
};
 
+   hsotg@1248 {
+   compatible = samsung,s3c6400-hsotg;
+   reg = 0x1248 0x2;
+   interrupts = 0 71 0;
+   clocks = clock 305;
+   clock-names = otg;
+   phys = exynos_usbphy 0;
+   phy-names = device;
+   status = disabled;
+   };
+
ehci@1258 {
compatible = samsung,exynos4210-ehci;
reg = 0x1258 0x100;
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/4] ARM: dts: exynos4: add PMU syscon node

2014-04-14 Thread Chanho Park
This patch adds a PMU(Power Management Unit) syscon node. This
should be required for USB Phy syscon regmap I/F.

Cc: Tomasz Figa t.f...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
Signed-off-by: Chanho Park chanho61.p...@samsung.com
---
 arch/arm/boot/dts/exynos4.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 2f8bcd0..e565b86 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -110,6 +110,11 @@
reg = 0x1001 0x400;
};
 
+   pmu_reg: syscon@1002 {
+   compatible = samsung,exynos4-pmureg, syscon;
+   reg = 0x1002 0x4000;
+   };
+
dsi_0: dsi@11C8 {
compatible = samsung,exynos4210-mipi-dsi;
reg = 0x11C8 0x1;
-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/4] Enable usbphy and hsotg for exynos4

2014-04-14 Thread Chanho Park
This patchset enables a exynos4 usbphy and hsotg DT node for exynos4. The usb
phy node uses generic exynos phy driver. The driver uses PMU syscon and SYSREG
syscon phandles.

Chanho Park (4):
  ARM: dts: exynos4: add PMU syscon node
  ARM: dts: exynos4: add exynos_usbphy node
  ARM: dts: exynos4: add hsotg device node
  ARM: dts: exynos4412-trats2: enable usb nodes

 arch/arm/boot/dts/exynos4.dtsi  | 26 ++
 arch/arm/boot/dts/exynos4412-trats2.dts | 10 ++
 arch/arm/boot/dts/exynos4x12.dtsi   |  5 +
 3 files changed, 41 insertions(+)

-- 
1.8.3.2

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Kishon Vijay Abraham I


On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
 Hi,
 
 
 On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi,

 On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
  drivers/phy/Kconfig|   11 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
  4 files changed, 722 insertions(+)
  create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 28f9edb..6d99ba9 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -74,3 +74,45 @@ phy-consumer@1234 {

  Refer to DT bindings documentation of particular PHY consumer devices for 
 more
  information about required PHYs and the way of specification.
 +
 +Samsung Exynos5 SoC series USB DRD PHY controller
 +--
 +
 +Required properties:
 +- compatible : Should be set to one of the following supported values:
 + - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
 + - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
 +- reg : Register offset and length of USB DRD PHY register set;
 +- clocks: Clock IDs array as required by the controller
 +- clock-names: names of clocks correseponding to IDs in the clock property;
 +Required clocks:
 + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
 +used for register access.
 + - ref: PHY's reference clock (usually crystal clock), associated by
 +phy name, used to determine bit values for clock settings
 +register.
 + Additional clock required for Exynos5420:
 + - usb30_sclk_100m: Additional special clock used for PHY operation
 +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +   control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to 
 pmu-system-controller
 +   base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 + usb3_phy: usbphy@1210 {
 + compatible = samsung,exynos5250-usbdrd-phy;
 + reg = 0x1210 0x100;
 + clocks = clock 286, clock 1;
 + clock-names = phy, usb3phy_refclk;
 + samsung,syscon-phandle = pmu_syscon;
 + samsung,pmu-offset = 0x704;
 + #phy-cells = 1;
 + };
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 8d3c49c..d955a05 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -166,4 +166,15 @@ config PHY_XGENE
   help
 This option enables support for APM X-Gene SoC multi-purpose PHY.

 +config PHY_EXYNOS5_USBDRD
 + tristate Exynos5 SoC series USB DRD PHY driver
 + depends on ARCH_EXYNOS5  OF
 + depends on HAS_IOMEM
 + select GENERIC_PHY
 + select MFD_SYSCON

 Lets try to avoid select in Kconfig. We've got enough problems with that.
 
 I hope you meant with select MFD_SYSCON.
 We are referencing the syscon for accessing pmu reg, for which we need
 this config to be selected.
 Other Exynos phy drivers also need this config and for that they have
 selected this.
 
 Do you want me to do it any other way ?

depends on is one option.

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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Kishon Vijay Abraham I


On Monday 14 April 2014 05:35 PM, Vivek Gautam wrote:
 Hi Kishon,
 
 
 On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I kis...@ti.com wrote:
 Hi,

 On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:
 Hi Vivek,

 Please see my comments inline.

 On 08.04.2014 16:36, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
   .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
   drivers/phy/Kconfig|   11 +
   drivers/phy/Makefile   |1 +
   drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
   4 files changed, 722 insertions(+)
   create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

 [snip]

 +Additional clock required for Exynos5420:
 +- usb30_sclk_100m: Additional special clock used for PHY operation
 +   depicted as 'sclk_usbphy30' in CMU of Exynos5420.

 Are you sure this isn't simply a gate for the ref clock, as it can be found 
 on
 another SoC that is not upstream yet? I don't have documentation for Exynos
 5420 so I can't tell, but I'd like to ask you to recheck this.

 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +  control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to
 pmu-system-controller
 +  base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 +usb3_phy: usbphy@1210 {
 +compatible = samsung,exynos5250-usbdrd-phy;
 +reg = 0x1210 0x100;
 +clocks = clock 286, clock 1;
 +clock-names = phy, usb3phy_refclk;

 Binding description above doesn't mention usb3phy_refclk entry.

 +samsung,syscon-phandle = pmu_syscon;
 +samsung,pmu-offset = 0x704;
 +#phy-cells = 1;
 +};

 [snip]

 diff --git a/drivers/phy/phy-exynos5-usbdrd.c 
 b/drivers/phy/phy-exynos5-usbdrd.c
 new file mode 100644
 index 000..ff54a7c
 --- /dev/null
 +++ b/drivers/phy/phy-exynos5-usbdrd.c

 [snip]

 +static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
 +{
 +struct device *dev = pdev-dev;
 +struct device_node *node = dev-of_node;
 +struct exynos5_usbdrd_phy *phy_drd;
 +struct phy_provider *phy_provider;
 +struct resource *res;
 +const struct of_device_id *match;
 +const struct exynos5_usbdrd_phy_drvdata *drv_data;
 +struct regmap *reg_pmu;
 +u32 pmu_offset;
 +int i;
 +
 +/*
 + * Exynos systems are completely DT enabled,
 + * so lets not have any platform data support for this driver.
 + */
 +if (!node) {
 +dev_err(dev, no device node found\n);

 This error message is not very meaningful. I'd rather use something like 
 This
 driver can be only instantiated using Device Tree.

 how about just adding depend_on OF in Kconfig?
 
 Already added a depend on 'OF'. Copying below the part of Kconfig in this 
 patch.

Alright.. Do we need the check then? If config_OF is enabled devices will be
created using device tree no?

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


[PATCH 1/4] ARM: dts: exynos5250-snow: add pinctrl for i2c-arbitrator

2014-04-14 Thread Sachin Kamat
From: Doug Anderson diand...@chromium.org

Added i2c-arbitrator pinctrl node to Snow board.

Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 arch/arm/boot/dts/exynos5250-snow.dts |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1ce1088..32715b3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -39,6 +39,22 @@
};
};
 
+   pinctrl@1340 {
+   arb_their_claim: arb-their-claim {
+   samsung,pins = gpe0-4;
+   samsung,pin-function = 0;
+   samsung,pin-pud = 3;
+   samsung,pin-drv = 0;
+   };
+
+   arb_our_claim: arb-our-claim {
+   samsung,pins = gpf0-3;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+   };
+
gpio-keys {
compatible = gpio-keys;
 
@@ -65,6 +81,9 @@
wait-retry-us = 3000;
wait-free-us = 5;
 
+   pinctrl-names = default;
+   pinctrl-0 = arb_our_claim arb_their_claim;
+
/* Use ID 104 as a hint that we're on physical bus 4 */
i2c_104: i2c@0 {
reg = 0;
-- 
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


[PATCH 2/4] ARM: dts: exynos5250-snow: add pinctrl for EC irq

2014-04-14 Thread Sachin Kamat
From: Doug Anderson diand...@chromium.org

Added pinctrl node for embedded controller (EC) IRQ
on Snow board.

Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 arch/arm/boot/dts/exynos5250-snow.dts |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index 32715b3..469c85d 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -25,6 +25,13 @@
};
 
pinctrl@1140 {
+   ec_irq: ec-irq {
+   samsung,pins = gpx1-6;
+   samsung,pin-function = 0;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
sd3_clk: sd3-clk {
samsung,pin-drv = 0;
};
@@ -101,6 +108,8 @@
reg = 0x1e;
interrupts = 6 0;
interrupt-parent = gpx1;
+   pinctrl-names = default;
+   pinctrl-0 = ec_irq;
wakeup-source;
 
keyboard-controller {
-- 
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


[PATCH 4/4] ARM: dts: exynos5250-snow: add ptn3460 node

2014-04-14 Thread Sachin Kamat
From: Doug Anderson diand...@chromium.org

Added nodes for ptn3460 driver to Snow board.

Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
 arch/arm/boot/dts/exynos5250-snow.dts |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index a38fd18..52ae335 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -32,6 +32,13 @@
samsung,pin-drv = 0;
};
 
+   ptn3460_gpios: ptn3460-gpios {
+   samsung,pins = gpy2-5, gpx1-5;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
sd3_clk: sd3-clk {
samsung,pin-drv = 0;
};
@@ -324,4 +331,16 @@
clock-frequency = 2400;
};
};
+
+   i2c_7: i2c@12CD {
+   ptn3460-bridge@20 {
+   compatible = nxp,ptn3460;
+   reg = 0x20;
+   powerdown-gpio = gpy2 5 0;
+   reset-gpio = gpx1 5 0;
+   edid-emulation = 5;
+   pinctrl-names = default;
+   pinctrl-0 = ptn3460_gpios;
+   };
+   };
 };
-- 
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: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Vivek Gautam
On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I kis...@ti.com wrote:


 On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
 On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I kis...@ti.com 
 wrote:


 On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
 Hi,


 On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I kis...@ti.com 
 wrote:
 Hi,

 On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
  drivers/phy/Kconfig|   11 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
  4 files changed, 722 insertions(+)
  create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 28f9edb..6d99ba9 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -74,3 +74,45 @@ phy-consumer@1234 {

  Refer to DT bindings documentation of particular PHY consumer devices 
 for more
  information about required PHYs and the way of specification.
 +
 +Samsung Exynos5 SoC series USB DRD PHY controller
 +--
 +
 +Required properties:
 +- compatible : Should be set to one of the following supported values:
 + - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
 + - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
 +- reg : Register offset and length of USB DRD PHY register set;
 +- clocks: Clock IDs array as required by the controller
 +- clock-names: names of clocks correseponding to IDs in the clock 
 property;
 +Required clocks:
 + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP 
 clock),
 +used for register access.
 + - ref: PHY's reference clock (usually crystal clock), associated by
 +phy name, used to determine bit values for clock settings
 +register.
 + Additional clock required for Exynos5420:
 + - usb30_sclk_100m: Additional special clock used for PHY operation
 +depicted as 'sclk_usbphy30' in CMU of 
 Exynos5420.
 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +   control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to 
 pmu-system-controller
 +   base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 + usb3_phy: usbphy@1210 {
 + compatible = samsung,exynos5250-usbdrd-phy;
 + reg = 0x1210 0x100;
 + clocks = clock 286, clock 1;
 + clock-names = phy, usb3phy_refclk;
 + samsung,syscon-phandle = pmu_syscon;
 + samsung,pmu-offset = 0x704;
 + #phy-cells = 1;
 + };
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 8d3c49c..d955a05 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -166,4 +166,15 @@ config PHY_XGENE
   help
 This option enables support for APM X-Gene SoC multi-purpose PHY.

 +config PHY_EXYNOS5_USBDRD
 + tristate Exynos5 SoC series USB DRD PHY driver
 + depends on ARCH_EXYNOS5  OF
 + depends on HAS_IOMEM
 + select GENERIC_PHY
 + select MFD_SYSCON

 Lets try to avoid select in Kconfig. We've got enough problems with that.

 I hope you meant with select MFD_SYSCON.
 We are referencing the syscon for accessing pmu reg, for which we need
 this config to be selected.
 Other Exynos phy drivers also need this config and for that they have
 selected this.

 Do you want me to do it any other way ?

 depends on is one option.

 Ok, i can see there are places where depends_on MFD_SYSCON is used.
 drivers/gpu/drm/exynos/Kconfig:60

 so, do you want me to fix at other places too ?

 But i also have a question here.
 MFD_SYSCON is a subsystem that's facilitating us in getting our work
 done here by giving an access to pmu_system_controller.
 So unless MFD_SYSCON is exposed, the phy driver will not be exposed to us.
 So is that valid enough really ?

 maybe in the Kconfig for MFD_SYSCON, we can select it if PHY_EXYNOS5_USBDRD is
 enabled?

 config MFD_SYSCON
 default y if 

Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Tomasz Figa

On 14.04.2014 15:05, Kishon Vijay Abraham I wrote:



On Monday 14 April 2014 05:35 PM, Vivek Gautam wrote:

Hi Kishon,


On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I kis...@ti.com wrote:

Hi,

On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:

Hi Vivek,

Please see my comments inline.

On 08.04.2014 16:36, Vivek Gautam wrote:

Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
   .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
   drivers/phy/Kconfig|   11 +
   drivers/phy/Makefile   |1 +
   drivers/phy/phy-exynos5-usbdrd.c   |  668 

   4 files changed, 722 insertions(+)
   create mode 100644 drivers/phy/phy-exynos5-usbdrd.c


[snip]


+Additional clock required for Exynos5420:
+- usb30_sclk_100m: Additional special clock used for PHY operation
+   depicted as 'sclk_usbphy30' in CMU of Exynos5420.


Are you sure this isn't simply a gate for the ref clock, as it can be found on
another SoC that is not upstream yet? I don't have documentation for Exynos
5420 so I can't tell, but I'd like to ask you to recheck this.


+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+  control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+  base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+  0 - UTMI+ type phy,
+  1 - PIPE3 type phy,
+
+Example:
+usb3_phy: usbphy@1210 {
+compatible = samsung,exynos5250-usbdrd-phy;
+reg = 0x1210 0x100;
+clocks = clock 286, clock 1;
+clock-names = phy, usb3phy_refclk;


Binding description above doesn't mention usb3phy_refclk entry.


+samsung,syscon-phandle = pmu_syscon;
+samsung,pmu-offset = 0x704;
+#phy-cells = 1;
+};


[snip]


diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..ff54a7c
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usbdrd.c


[snip]


+static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
+{
+struct device *dev = pdev-dev;
+struct device_node *node = dev-of_node;
+struct exynos5_usbdrd_phy *phy_drd;
+struct phy_provider *phy_provider;
+struct resource *res;
+const struct of_device_id *match;
+const struct exynos5_usbdrd_phy_drvdata *drv_data;
+struct regmap *reg_pmu;
+u32 pmu_offset;
+int i;
+
+/*
+ * Exynos systems are completely DT enabled,
+ * so lets not have any platform data support for this driver.
+ */
+if (!node) {
+dev_err(dev, no device node found\n);


This error message is not very meaningful. I'd rather use something like This
driver can be only instantiated using Device Tree.


how about just adding depend_on OF in Kconfig?


Already added a depend on 'OF'. Copying below the part of Kconfig in this patch.


Alright.. Do we need the check then? If config_OF is enabled devices will be
created using device tree no?


Not necessarily. Enabling support for OF doesn't mean that it is the 
only boot method that can be used. Legacy board files may be still 
available. I'm not sure why someone would try to instantiate this driver 
from them, though.


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 V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Vivek Gautam
On Mon, Apr 14, 2014 at 7:10 PM, Vivek Gautam gautam.vi...@samsung.com wrote:

Just correcting mail-ids for Mark and Dong with the latest ones
(earlier ones got bounced back)

 On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I kis...@ti.com wrote:


 On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:
 On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I kis...@ti.com 
 wrote:


 On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:
 Hi,


 On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I kis...@ti.com 
 wrote:
 Hi,

 On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:
 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
  drivers/phy/Kconfig|   11 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos5-usbdrd.c   |  668 
 
  4 files changed, 722 insertions(+)
  create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 28f9edb..6d99ba9 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -74,3 +74,45 @@ phy-consumer@1234 {

  Refer to DT bindings documentation of particular PHY consumer devices 
 for more
  information about required PHYs and the way of specification.
 +
 +Samsung Exynos5 SoC series USB DRD PHY controller
 +--
 +
 +Required properties:
 +- compatible : Should be set to one of the following supported values:
 + - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
 + - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
 +- reg : Register offset and length of USB DRD PHY register set;
 +- clocks: Clock IDs array as required by the controller
 +- clock-names: names of clocks correseponding to IDs in the clock 
 property;
 +Required clocks:
 + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP 
 clock),
 +used for register access.
 + - ref: PHY's reference clock (usually crystal clock), associated 
 by
 +phy name, used to determine bit values for clock settings
 +register.
 + Additional clock required for Exynos5420:
 + - usb30_sclk_100m: Additional special clock used for PHY operation
 +depicted as 'sclk_usbphy30' in CMU of 
 Exynos5420.
 +- samsung,syscon-phandle: phandle for syscon interface, which is used 
 to
 +   control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to 
 pmu-system-controller
 +   base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 + usb3_phy: usbphy@1210 {
 + compatible = samsung,exynos5250-usbdrd-phy;
 + reg = 0x1210 0x100;
 + clocks = clock 286, clock 1;
 + clock-names = phy, usb3phy_refclk;
 + samsung,syscon-phandle = pmu_syscon;
 + samsung,pmu-offset = 0x704;
 + #phy-cells = 1;
 + };
 diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
 index 8d3c49c..d955a05 100644
 --- a/drivers/phy/Kconfig
 +++ b/drivers/phy/Kconfig
 @@ -166,4 +166,15 @@ config PHY_XGENE
   help
 This option enables support for APM X-Gene SoC multi-purpose 
 PHY.

 +config PHY_EXYNOS5_USBDRD
 + tristate Exynos5 SoC series USB DRD PHY driver
 + depends on ARCH_EXYNOS5  OF
 + depends on HAS_IOMEM
 + select GENERIC_PHY
 + select MFD_SYSCON

 Lets try to avoid select in Kconfig. We've got enough problems with that.

 I hope you meant with select MFD_SYSCON.
 We are referencing the syscon for accessing pmu reg, for which we need
 this config to be selected.
 Other Exynos phy drivers also need this config and for that they have
 selected this.

 Do you want me to do it any other way ?

 depends on is one option.

 Ok, i can see there are places where depends_on MFD_SYSCON is used.
 drivers/gpu/drm/exynos/Kconfig:60

 so, do you want me to fix at other places too ?

 But i also have a question here.
 MFD_SYSCON is a subsystem that's facilitating us in getting our work
 done here by giving an access to pmu_system_controller.
 So unless MFD_SYSCON is exposed, the phy driver will 

Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Tomasz Figa

On 14.04.2014 15:40, Vivek Gautam wrote:

On Mon, Apr 14, 2014 at 6:56 PM, Kishon Vijay Abraham I kis...@ti.com wrote:



On Monday 14 April 2014 06:50 PM, Vivek Gautam wrote:

On Mon, Apr 14, 2014 at 6:29 PM, Kishon Vijay Abraham I kis...@ti.com wrote:



On Monday 14 April 2014 06:12 PM, Vivek Gautam wrote:

Hi,


On Mon, Apr 14, 2014 at 5:57 PM, Kishon Vijay Abraham I kis...@ti.com wrote:

Hi,

On Tuesday 08 April 2014 08:06 PM, Vivek Gautam wrote:

Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.

Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
  .../devicetree/bindings/phy/samsung-phy.txt|   42 ++
  drivers/phy/Kconfig|   11 +
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos5-usbdrd.c   |  668 
  4 files changed, 722 insertions(+)
  create mode 100644 drivers/phy/phy-exynos5-usbdrd.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 28f9edb..6d99ba9 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -74,3 +74,45 @@ phy-consumer@1234 {

  Refer to DT bindings documentation of particular PHY consumer devices for more
  information about required PHYs and the way of specification.
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
+ - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+used for register access.
+ - ref: PHY's reference clock (usually crystal clock), associated by
+phy name, used to determine bit values for clock settings
+register.
+ Additional clock required for Exynos5420:
+ - usb30_sclk_100m: Additional special clock used for PHY operation
+depicted as 'sclk_usbphy30' in CMU of Exynos5420.
+- samsung,syscon-phandle: phandle for syscon interface, which is used to
+   control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to 
pmu-system-controller
+   base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+  0 - UTMI+ type phy,
+  1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = samsung,exynos5250-usbdrd-phy;
+ reg = 0x1210 0x100;
+ clocks = clock 286, clock 1;
+ clock-names = phy, usb3phy_refclk;
+ samsung,syscon-phandle = pmu_syscon;
+ samsung,pmu-offset = 0x704;
+ #phy-cells = 1;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 8d3c49c..d955a05 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,15 @@ config PHY_XGENE
   help
 This option enables support for APM X-Gene SoC multi-purpose PHY.

+config PHY_EXYNOS5_USBDRD
+ tristate Exynos5 SoC series USB DRD PHY driver
+ depends on ARCH_EXYNOS5  OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON


Lets try to avoid select in Kconfig. We've got enough problems with that.


I hope you meant with select MFD_SYSCON.
We are referencing the syscon for accessing pmu reg, for which we need
this config to be selected.
Other Exynos phy drivers also need this config and for that they have
selected this.

Do you want me to do it any other way ?


depends on is one option.


Ok, i can see there are places where depends_on MFD_SYSCON is used.
drivers/gpu/drm/exynos/Kconfig:60

so, do you want me to fix at other places too ?

But i also have a question here.
MFD_SYSCON is a subsystem that's facilitating us in getting our work
done here by giving an access to pmu_system_controller.
So unless MFD_SYSCON is exposed, the phy driver will not be exposed to us.
So is that valid enough really ?


maybe in the Kconfig for MFD_SYSCON, we can select it if PHY_EXYNOS5_USBDRD is
enabled?

config MFD_SYSCON
default y if PHY_EXYNOS5_USBDRD


Yes, that seems to be one option. But 

RE: [PATCH RFC 0/2] drm/exynos: refactoring drm device init/deinit

2014-04-14 Thread Inki Dae
Hi Tomasz,

Always thanks for your opinions.

 -Original Message-
 From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
 ow...@vger.kernel.org] On Behalf Of Tomasz Figa
 Sent: Monday, April 14, 2014 8:32 PM
 To: Inki Dae; 'Andrzej Hajda'
 Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell
King';
 dri-de...@lists.freedesktop.org; 'Marek Szyprowski'
 Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
 init/deinit
 
 Hi Inki,
 
 On 14.04.2014 13:04, Inki Dae wrote:
 
 
  -Original Message-
  From: Andrzej Hajda [mailto:a.ha...@samsung.com]
  Sent: Monday, April 14, 2014 5:55 PM
  To: Inki Dae
  Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS
  AR...; Kyungmin Park; Marek Szyprowski
  Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
  init/deinit
 
  On 04/12/2014 04:18 PM, Inki Dae wrote:
  Hi Andrzej,
 
  Thanks for your contributions.
 
  2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:
  Hi Inki,
 
  This patchset refactors drm device initialization. Details are
  described in respective patches. It is an alternative to DT
  supernode
  concept.
 
  The first patch uses linker sections to get rid of ifdef macros, it
  is not
  That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this
  way.
 
  essential for 2nd patch but it makes code more readable. Similar
  approach is used by irqchip, clks and clk_sources.
  But 2nd patch doesn't seem reasnoable to me. Your approach is same
  as existing one conceptually. I think we need to handle drm driver
  in a different way from irqchip, clks and clk_sources.
 
  DRM driver means one integrated graphics card but in most embedded
  systems, graphics and display relevant devices have separated
  hardware resources. So we would need abstractional integrated
  hardware, display-subsystem, super device. That is why I are trying
  to use super device approach, and conceptually it would be right
  solution. It wouldn't be not good to combine those separated
  hardware somehow using specific codes.
 
  Conceptually both approaches are the same: we have number of devices
  which should be ready before we can start super-device and if any
  device is to be removed super-device should be removed before.
  The difference is in 'details':
  - super-node approach have list of components provided explicitly in
  DT special node,
  - in this approach list of components is constructed from devices
  present in the system.
 
  Creating special DT node with information which is available anyway
  seems to be redundant and against DT rules.
 
 
  CCing Russell King,
 
  What is the special DT node? You mean device node from ports property?
 
  It is supposed  to use super device and its properties in mainline so
  I don't see what it is against DT rules. If they are really against DT
  rules, why component framework is in mainline?
 
 Component framework in mainline doesn't have anything in common with DT.
 All it does is providing tools for handling cases where a subsystem can be
 initialized only after all components are available. It doesn't define any
 means of getting the list of components, it's a task for the user of this
 framework to provide it.
 
 
  As you said above, conceptually both approaches may be the same but
  your approach has no any abstract hardware meaning one integrated
  hardware. And if conceptually both approaches are the same, it would
  be good to use existing infrastructure, component framework so there
  is no any reason to add and use specific codes.
 
 What do you mean by abstract hardware? Physically, in the SoC, there is
 no single integrated hardware block, but multiple IPs and they need to be
 described this way in DT. There is nothing that prevents using them
 separately if a user doesn't want to use Exynos DRM. Exynos DRM is a

I don't think that super device approach prevents using existing device
nodes separately. If a user doesn't want to use Exynos DRM, he cannot
declare the super node and each IP would work well in existing way. There
would be nothing to change existing device nodes.

 Linux-specific thing and its details should not be leaked into DT, which
 is a _hardware_ description method.
 
 
  And component framework says,
  Subsystems such as ALSA, DRM and others require a single card-level
  device structure to represent a subsystem. However, firmware tends to
  describe the individual devices and the connections between them.
  Therefore, we need a way to gather up the individual component devices
  together, and indicate when we have all the component devices.
 
 Note following things:
 
 - Nothing in the quote above says that an additional DT node must be
added.
 The framework works on generic driver model level, above the description
 level (such as DT).

And also the component framework says,


  We do this in DT by providing a superdevice node which specifies the
components, eg:  
imx-drm {
 

Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Vivek Gautam
Hi,


On Mon, Apr 14, 2014 at 7:14 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 On 14.04.2014 15:05, Kishon Vijay Abraham I wrote:



 On Monday 14 April 2014 05:35 PM, Vivek Gautam wrote:

 Hi Kishon,


 On Mon, Apr 14, 2014 at 5:24 PM, Kishon Vijay Abraham I kis...@ti.com
 wrote:

 Hi,

 On Wednesday 09 April 2014 04:36 PM, Tomasz Figa wrote:

 Hi Vivek,

 Please see my comments inline.

 On 08.04.2014 16:36, Vivek Gautam wrote:

 Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
 The new driver uses the generic PHY framework and will interact
 with DWC3 controller present on Exynos5 series of SoCs.
 Thereby, removing old phy-samsung-usb3 driver and related code
 used untill now which was based on usb/phy framework.

 Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
 ---
.../devicetree/bindings/phy/samsung-phy.txt|   42 ++
drivers/phy/Kconfig|   11 +
drivers/phy/Makefile   |1 +
drivers/phy/phy-exynos5-usbdrd.c   |  668
 
4 files changed, 722 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c


 [snip]

 +Additional clock required for Exynos5420:
 +- usb30_sclk_100m: Additional special clock used for PHY
 operation
 +   depicted as 'sclk_usbphy30' in CMU of Exynos5420.


 Are you sure this isn't simply a gate for the ref clock, as it can be
 found on
 another SoC that is not upstream yet? I don't have documentation for
 Exynos
 5420 so I can't tell, but I'd like to ask you to recheck this.

 +- samsung,syscon-phandle: phandle for syscon interface, which is used
 to
 +  control pmu registers for power isolation.
 +- samsung,pmu-offset: phy power control register offset to
 pmu-system-controller
 +  base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and
 samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,
 +
 +Example:
 +usb3_phy: usbphy@1210 {
 +compatible = samsung,exynos5250-usbdrd-phy;
 +reg = 0x1210 0x100;
 +clocks = clock 286, clock 1;
 +clock-names = phy, usb3phy_refclk;


 Binding description above doesn't mention usb3phy_refclk entry.

 +samsung,syscon-phandle = pmu_syscon;
 +samsung,pmu-offset = 0x704;
 +#phy-cells = 1;
 +};


 [snip]

 diff --git a/drivers/phy/phy-exynos5-usbdrd.c
 b/drivers/phy/phy-exynos5-usbdrd.c
 new file mode 100644
 index 000..ff54a7c
 --- /dev/null
 +++ b/drivers/phy/phy-exynos5-usbdrd.c


 [snip]

 +static int exynos5_usbdrd_phy_probe(struct platform_device *pdev)
 +{
 +struct device *dev = pdev-dev;
 +struct device_node *node = dev-of_node;
 +struct exynos5_usbdrd_phy *phy_drd;
 +struct phy_provider *phy_provider;
 +struct resource *res;
 +const struct of_device_id *match;
 +const struct exynos5_usbdrd_phy_drvdata *drv_data;
 +struct regmap *reg_pmu;
 +u32 pmu_offset;
 +int i;
 +
 +/*
 + * Exynos systems are completely DT enabled,
 + * so lets not have any platform data support for this driver.
 + */
 +if (!node) {
 +dev_err(dev, no device node found\n);


 This error message is not very meaningful. I'd rather use something
 like This
 driver can be only instantiated using Device Tree.


 how about just adding depend_on OF in Kconfig?


 Already added a depend on 'OF'. Copying below the part of Kconfig in this
 patch.


 Alright.. Do we need the check then? If config_OF is enabled devices will
 be
 created using device tree no?


 Not necessarily. Enabling support for OF doesn't mean that it is the only
 boot method that can be used. Legacy board files may be still available. I'm
 not sure why someone would try to instantiate this driver from them, though.

True, we don't have a scope of instantiating this driver using old
platform device and
old legacy board files.
So we don't need this check then, right ?


-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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 RFC 0/2] drm/exynos: refactoring drm device init/deinit

2014-04-14 Thread Tomasz Figa

On 14.04.2014 15:55, Inki Dae wrote:

Hi Tomasz,

Always thanks for your opinions.


-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Tomasz Figa
Sent: Monday, April 14, 2014 8:32 PM
To: Inki Dae; 'Andrzej Hajda'
Cc: 'Kyungmin Park'; 'moderated list:ARM/S5P EXYNOS AR...'; 'Russell

King';

dri-de...@lists.freedesktop.org; 'Marek Szyprowski'
Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
init/deinit

Hi Inki,

On 14.04.2014 13:04, Inki Dae wrote:




-Original Message-
From: Andrzej Hajda [mailto:a.ha...@samsung.com]
Sent: Monday, April 14, 2014 5:55 PM
To: Inki Dae
Cc: dri-de...@lists.freedesktop.org; moderated list:ARM/S5P EXYNOS
AR...; Kyungmin Park; Marek Szyprowski
Subject: Re: [PATCH RFC 0/2] drm/exynos: refactoring drm device
init/deinit

On 04/12/2014 04:18 PM, Inki Dae wrote:

Hi Andrzej,

Thanks for your contributions.

2014-04-11 23:11 GMT+09:00 Andrzej Hajda a.ha...@samsung.com:

Hi Inki,

This patchset refactors drm device initialization. Details are
described in respective patches. It is an alternative to DT
supernode

concept.


The first patch uses linker sections to get rid of ifdef macros, it
is not

That's a good idea. :) We could avoid ugly #ifdef ~ #endif with this

way.



essential for 2nd patch but it makes code more readable. Similar
approach is used by irqchip, clks and clk_sources.

But 2nd patch doesn't seem reasnoable to me. Your approach is same
as existing one conceptually. I think we need to handle drm driver
in a different way from irqchip, clks and clk_sources.

DRM driver means one integrated graphics card but in most embedded
systems, graphics and display relevant devices have separated
hardware resources. So we would need abstractional integrated
hardware, display-subsystem, super device. That is why I are trying
to use super device approach, and conceptually it would be right
solution. It wouldn't be not good to combine those separated
hardware somehow using specific codes.


Conceptually both approaches are the same: we have number of devices
which should be ready before we can start super-device and if any
device is to be removed super-device should be removed before.
The difference is in 'details':
- super-node approach have list of components provided explicitly in
DT special node,
- in this approach list of components is constructed from devices
present in the system.

Creating special DT node with information which is available anyway
seems to be redundant and against DT rules.



CCing Russell King,

What is the special DT node? You mean device node from ports property?

It is supposed  to use super device and its properties in mainline so
I don't see what it is against DT rules. If they are really against DT
rules, why component framework is in mainline?


Component framework in mainline doesn't have anything in common with DT.
All it does is providing tools for handling cases where a subsystem can be
initialized only after all components are available. It doesn't define any
means of getting the list of components, it's a task for the user of this
framework to provide it.



As you said above, conceptually both approaches may be the same but
your approach has no any abstract hardware meaning one integrated
hardware. And if conceptually both approaches are the same, it would
be good to use existing infrastructure, component framework so there
is no any reason to add and use specific codes.


What do you mean by abstract hardware? Physically, in the SoC, there is
no single integrated hardware block, but multiple IPs and they need to be
described this way in DT. There is nothing that prevents using them
separately if a user doesn't want to use Exynos DRM. Exynos DRM is a


I don't think that super device approach prevents using existing device
nodes separately. If a user doesn't want to use Exynos DRM, he cannot
declare the super node and each IP would work well in existing way. There
would be nothing to change existing device nodes.



I agree that it wouldn't interfere with other possible use cases, but it 
is still leaking Linux- and use case- specific data to DT, which should 
be both OS and use case- agnostic. Especially when the goal to be 
achieved doesn't even require doing so (see Andrzej's enumeration using 
driver model objects directly).



Linux-specific thing and its details should not be leaked into DT, which
is a _hardware_ description method.



And component framework says,
Subsystems such as ALSA, DRM and others require a single card-level
device structure to represent a subsystem. However, firmware tends to
describe the individual devices and the connections between them.
Therefore, we need a way to gather up the individual component devices
together, and indicate when we have all the component devices.


Note following things:

- Nothing in the quote above says that an additional DT node must be

added.

The framework works on 

Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Sylwester Nawrocki
On 14/04/14 15:49, Vivek Gautam wrote:
 True, we don't have a scope of instantiating this driver using old
 platform device and
 old legacy board files.
 So we don't need this check then, right ?

I think it can be dropped.
At least IMHO there is no point to increase size of the module with
an error log that has no chance to be ever called in practice.

--
Thanks,
Sylwester



--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V4 1/5] phy: Add new Exynos5 USB 3.0 PHY driver

2014-04-14 Thread Sylwester Nawrocki
On 08/04/14 16:36, Vivek Gautam wrote:
 diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
 b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 index 28f9edb..6d99ba9 100644
 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
 +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
 @@ -74,3 +74,45 @@ phy-consumer@1234 {
  
  Refer to DT bindings documentation of particular PHY consumer devices for 
 more
  information about required PHYs and the way of specification.
 +
 +Samsung Exynos5 SoC series USB DRD PHY controller
 +--
 +
 +Required properties:
 +- compatible : Should be set to one of the following supported values:
 + - samsung,exynos5250-usbdrd-phy - for exynos5250 SoC,
 + - samsung,exynos5420-usbdrd-phy - for exynos5420 SoC.
 +- reg : Register offset and length of USB DRD PHY register set;
 +- clocks: Clock IDs array as required by the controller
 +- clock-names: names of clocks correseponding to IDs in the clock property;
 +Required clocks:
 + - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
 +used for register access.
 + - ref: PHY's reference clock (usually crystal clock), associated by
 +phy name, used to determine bit values for clock settings
 +register.
 + Additional clock required for Exynos5420:
 + - usb30_sclk_100m: Additional special clock used for PHY operation
 +depicted as 'sclk_usbphy30' in CMU of Exynos5420.
 +- samsung,syscon-phandle: phandle for syscon interface, which is used to
 +   control pmu registers for power isolation.

Why to append -phandle to the property's name ? If this is for PMU
perhaps make it more explicit and name it: samsung,pmu-syscon or
samsung,pmureg ?

 +- samsung,pmu-offset: phy power control register offset to 
 pmu-system-controller
 +   base.
 +- #phy-cells : from the generic PHY bindings, must be 1;
 +
 +For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
 +compatible PHYs, the second cell in the PHY specifier identifies the
 +PHY id, which is interpreted as follows:
 +  0 - UTMI+ type phy,
 +  1 - PIPE3 type phy,

-- 
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/4] drm: exynos: mixer: fix using usleep() in atomic context

2014-04-14 Thread Tomasz Stanislawski
This patch fixes calling usleep_range() after taking reg_slock
using spin_lock_irqsave(). The mdelay() is used instead.
Waiting in atomic context is not the best idea in general.
Hopefully, waiting occurs only when Video Processor fails
to reset correctly.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ce28881..e3306c8 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -615,7 +615,7 @@ static void vp_win_reset(struct mixer_context *ctx)
/* waiting until VP_SRESET_PROCESSING is 0 */
if (~vp_reg_read(res, VP_SRESET)  VP_SRESET_PROCESSING)
break;
-   usleep_range(1, 12000);
+   mdelay(10);
}
WARN(tries == 0, failed to reset Video Processor\n);
 }
-- 
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


[PATCH 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

2014-04-14 Thread Tomasz Stanislawski
This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |3 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d2d6e2e..6fa63ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2032,6 +2032,9 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 
 static struct of_device_id hdmi_match_types[] = {
{
+   .compatible = samsung,exynos4210-hdmi,
+   .data   = (void *)HDMI_TYPE13,
+   }, {
.compatible = samsung,exynos5-hdmi,
.data = exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
 
 static struct of_device_id mixer_match_types[] = {
{
+   .compatible = samsung,exynos4210-mixer,
+   .data   = exynos4210_mxr_drv_data,
+   }, {
.compatible = samsung,exynos5-mixer,
.data   = exynos5250_mxr_drv_data,
}, {
-- 
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


[PATCH 4/4] drm: exynos: hdmi: add support for pixel clock limitation

2014-04-14 Thread Tomasz Stanislawski
Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |4 
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
 include/media/s5p_hdmi.h   |1 +
 3 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
 - ddc: phandle to the hdmi ddc node
 - phy: phandle to the hdmi phy node
 
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has lines,
+   connectors or bridges not capable of carring higher frequencies
+
 Example:
 
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6fa63ea..ca313b3 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources   res;
 
int hpd_gpio;
+   u32 max_pixel_clock;
 
enum hdmi_type  type;
 };
@@ -883,6 +884,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
if (ret)
return MODE_BAD;
 
+   if (mode-clock * 1000  hdata-max_pixel_clock)
+   return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret  0)
return MODE_BAD;
@@ -2027,6 +2031,8 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
return NULL;
}
 
+   of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
+
return pd;
 }
 
@@ -2063,6 +2069,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
 
+   if (!pdata-max_pixel_clock) {
+   DRM_INFO(max-pixel-clock is zero, using INF\n);
+   pdata-max_pixel_clock = ULONG_MAX;
+   }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2079,6 +2090,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata-type = drv_data-type;
 
hdata-hpd_gpio = pdata-hpd_gpio;
+   hdata-max_pixel_clock = pdata-max_pixel_clock;
hdata-dev = dev;
 
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+   u32 max_pixel_clock;
 };
 
 #endif /* S5P_HDMI_H */
-- 
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


[PATCH 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

2014-04-14 Thread Tomasz Stanislawski
This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..d2d6e2e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 {
struct device_node *np = dev-of_node;
struct s5p_hdmi_platform_data *pd;
-   u32 value;
 
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
-   goto err_data;
+   return NULL;
 
-   if (!of_find_property(np, hpd-gpio, value)) {
+   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
+   if (gpio_is_valid(pd-hpd_gpio)) {
DRM_ERROR(no hpd gpio property found\n);
-   goto err_data;
+   return NULL;
}
 
-   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
return pd;
-
-err_data:
-   return NULL;
 }
 
 static struct of_device_id hdmi_match_types[] = {
-- 
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


[PATCH 0/4] drm: exynos: update/fixes to HDMI driver

2014-04-14 Thread Tomasz Stanislawski
Hi everyone,
This patchset adds 4 fixes/updates to EXYNOS DRM driver for
HDMI subsystem.

All comments are welcome.

Regards,
Tomasz Stanislawski

Tomasz Stanislawski (4):
  drm: exynos: hdmi: simplify extracting hpd-gpio from DT
  drm: exynos: mixer: fix using usleep() in atomic context
  drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210
SoC
  drm: exynos: hdmi: add support for pixel clock limitation

 .../devicetree/bindings/video/exynos_hdmi.txt  |4 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   26 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |5 +++-
 include/media/s5p_hdmi.h   |1 +
 4 files changed, 27 insertions(+), 9 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


Re: [PATCH 7/8] arm64: mm: Implement 4 levels of translation tables

2014-04-14 Thread Steve Capper
On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
 This patch implements 4 levels of translation tables since 3 levels
 of page tables with 4KB pages cannot support 40-bit physical address
 space described in [1] due to the following issue.
 
 It is a restriction that kernel logical memory map with 4KB + 3 levels
 (0xffc0-0x) cannot cover RAM region from
 544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
 mapping for this region in map_mem function since __phys_to_virt for
 this region reaches to address overflow.
 
 If SoC design follows the document, [1], over 32GB RAM would be placed
 from 544GB. Even 64GB system is supposed to use the region from 544GB
 to 576GB for only 32GB RAM. Naturally, it would reach to enable 4 levels
 of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
 
 However, it is recommended 4 levels of page table should be only enabled
 if memory map is too sparse or there is about 512GB RAM.
 
 References
 --
 [1]: Principle of ARM Memory Maps, White Paper, Issue C
 

Hi Jungseok,
I've given this a quick run on the Fast Model with huge pages, and it passed
the libhugetlbfs test suite.

Some comments/suggestions below...

 Signed-off-by: Jungseok Lee jays@samsung.com
 Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
 ---
  arch/arm64/Kconfig |7 +
  arch/arm64/include/asm/page.h  |4 ++-
  arch/arm64/include/asm/pgalloc.h   |   20 ++
  arch/arm64/include/asm/pgtable-hwdef.h |8 --
  arch/arm64/include/asm/pgtable.h   |   44 +--
  arch/arm64/include/asm/tlb.h   |8 ++
  arch/arm64/kernel/head.S   |   45 
 ++--
  arch/arm64/kernel/traps.c  |5 
  arch/arm64/mm/fault.c  |1 +
  arch/arm64/mm/mmu.c|   14 +-
  10 files changed, 148 insertions(+), 8 deletions(-)
 
 diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
 index 431acbc..7f5270b 100644
 --- a/arch/arm64/Kconfig
 +++ b/arch/arm64/Kconfig
 @@ -184,12 +184,19 @@ config ARM64_3_LEVELS
   help
 This feature enables 3 levels of translation tables.
  
 +config ARM64_4_LEVELS
 + bool 4 level
 + depends on ARM64_4K_PAGES
 + help
 +   This feature enables 4 levels of translation tables.
 +
  endchoice
  
  config ARM64_VA_BITS
   int Virtual address space size
   range 39 39 if ARM64_4K_PAGES  ARM64_3_LEVELS
   range 42 42 if ARM64_64K_PAGES  ARM64_2_LEVELS
 + range 48 48 if ARM64_4K_PAGES  ARM64_4_LEVELS
   help
 This feature is determined by a combination of page size and
 level of translation tables.
 diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
 index 268e53d..83b5289 100644
 --- a/arch/arm64/include/asm/page.h
 +++ b/arch/arm64/include/asm/page.h
 @@ -35,8 +35,10 @@
  
  #ifdef CONFIG_ARM64_2_LEVELS
  #include asm/pgtable-2level-types.h
 -#else
 +#elif defined(CONFIG_ARM64_3_LEVELS)
  #include asm/pgtable-3level-types.h
 +#else
 +#include asm/pgtable-4level-types.h
  #endif
  
  extern void __cpu_clear_user_page(void *p, unsigned long user);
 diff --git a/arch/arm64/include/asm/pgalloc.h 
 b/arch/arm64/include/asm/pgalloc.h
 index 4829837..8d745fa 100644
 --- a/arch/arm64/include/asm/pgalloc.h
 +++ b/arch/arm64/include/asm/pgalloc.h
 @@ -26,6 +26,26 @@
  
  #define check_pgt_cache()do { } while (0)
  
 +#ifdef CONFIG_ARM64_4_LEVELS
 +
 +static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned long addr)
 +{
 + return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT);
 +}
 +
 +static inline void pud_free(struct mm_struct *mm, pud_t *pud)
 +{
 + BUG_ON((unsigned long)pud  (PAGE_SIZE-1));
 + free_page((unsigned long)pud);
 +}
 +
 +static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd, pud_t *pud)
 +{
 + set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));

Perhaps instead use PGD_TYPE_TABLE?

 +}
 +
 +#endif  /* CONFIG_ARM64_4_LEVELS */
 +
  #ifndef CONFIG_ARM64_2_LEVELS
  
  static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
 diff --git a/arch/arm64/include/asm/pgtable-hwdef.h 
 b/arch/arm64/include/asm/pgtable-hwdef.h
 index 9cd86c6..03ad81b 100644
 --- a/arch/arm64/include/asm/pgtable-hwdef.h
 +++ b/arch/arm64/include/asm/pgtable-hwdef.h
 @@ -18,8 +18,10 @@
  
  #ifdef CONFIG_ARM64_2_LEVELS
  #include asm/pgtable-2level-hwdef.h
 -#else
 +#elif defined(CONFIG_ARM64_3_LEVELS)
  #include asm/pgtable-3level-hwdef.h
 +#else
 +#include asm/pgtable-4level-hwdef.h
  #endif
  
  /*
 @@ -27,7 +29,9 @@
   *
   * Level 1 descriptor (PUD).
   */
 -
 +#ifdef CONFIG_ARM64_4_LEVELS
 +#define PUD_TYPE_TABLE   (_AT(pudval_t, 3)  0)

I would be tempted to instead define:
 +#define PGD_TYPE_TABLE(_AT(pgdval_t, 3)  0)
And have that under Level 0 descriptor (PGD). 

Re: [PATCH 2/8] arm/arm64: KVM: Fix line length exceeding 80 characters

2014-04-14 Thread Marc Zyngier
On 14/04/14 08:40, Jungseok Lee wrote:
 This patch deals with checkpatch complaint as fixing line length
 exceeding 80 characters.
 
 WARNING: line over 80 characters
 
 Signed-off-by: Jungseok Lee jays@samsung.com
 Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
 ---
  arch/arm/kvm/mmu.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
 index 80bb1e6..e0d4f24 100644
 --- a/arch/arm/kvm/mmu.c
 +++ b/arch/arm/kvm/mmu.c
 @@ -563,8 +563,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
   kvm-arch.pgd = NULL;
  }
  
 -static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache 
 *cache,
 -  phys_addr_t addr)
 +static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache
 +  *cache, phys_addr_t addr)

Please don't. This makes the code unreadable (and no, I don't care about
checkpatch ;-).

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] arm: exynos: generalize power register address calculation

2014-04-14 Thread Tomasz Figa

On 14.04.2014 06:27, Chander Kashyap wrote:

Hi,

On 10 April 2014 11:18, Chander Kashyap chander.kash...@linaro.org wrote:

Hi Tomasz,

On 9 April 2014 20:15, Tomasz Figa t.f...@samsung.com wrote:

On 09.04.2014 15:49, Chander Kashyap wrote:


Hi Tomasz,

On 9 April 2014 17:19, Tomasz Figa t.f...@samsung.com wrote:


Hi Chander,


On 09.04.2014 13:09, Chander Kashyap wrote:



Currently status/configuration power register values are hard-coded for
cpu1.

Make it generic so that it is useful for SoC's with more than two cpus.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
changes in v2 : Used existing macros for clusterid and cpuid calculation

arch/arm/mach-exynos/hotplug.c  |   15 ---
arch/arm/mach-exynos/platsmp.c  |   20 +++-
arch/arm/mach-exynos/regs-pmu.h |9 +++--
3 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c
b/arch/arm/mach-exynos/hotplug.c
index 5eead53..eab6121 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -17,6 +17,7 @@

#include asm/cacheflush.h
#include asm/cp15.h
+#include asm/cputype.h
#include asm/smp_plat.h

#include plat/cpu.h
@@ -92,11 +93,19 @@ static inline void cpu_leave_lowpower(void)

static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
{
+   unsigned int mpidr, cpunr, cluster;
+
+   mpidr = cpu_logical_map(cpu);
+   cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+   cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+   /* Maximum possible cpus in a cluster can be 4 */
+   cpunr += cluster * 4;




I believe this is rather a weak assumption. First of all, the limit seems
to
be hardcoded only for the few existing SoCs. In addition, the value is
not
used as a maximum, but rather it is assumed that each cluster has always
four cores.



The MPIDR register contains 2 bits for cpu id. Hence maximum number of
cpus can be 4 only (A15/A9/A7).



This is not what I meant. Exynos5260 contains 2 big cores (not 4) and 4
little cores. Are you sure that PMU register layout on Exynos5260 matches
your equation?



Yes the equation covers that as the PMU register layout takes care for that:
Address offset are as follows:
2 Big Cores:
cpu0 : 2000
cpu1: 2080

4 Little cores:

cpu0: 2200
cpu1: 2280
cpu2: 2300
cpu3: 2380





Moreover, it is assumed here that the mapping between core ID (calculated
by
the equation below) and PMU core numbers is 1:1, which is not true. On
Exynos4210, the cluster ID is always 0x09 and on Exynos4x12 it is 0x0a,
which will lead to completely wrong register offsets.



Exynos4210 and Exynos4x12, cluster ids are not passed from DT as it
breaks the gic_init_bases. Hence the Physical CpuID for Exynos4210
will be 0,1 and Exynos4x12 will be 0,1,2,3.

So it will not break.



I already have patches ready fixing GIC driver, just waiting for 3.15-rc1 to
be released. Anyway, CPU topology in DT is mandatory and Exynos4 device tree
files need to be fixed to contain them. This needs to be accounted for in
any changes touching CPU topology related code.



That's great.








I believe the proper way to deal with this is to provide per-CPU property
in
DT called samsung,pmu-offset that could be used be code like this to
calculate register addresses properly.

For now, I would recommend doing the above ignoring cluster ID completely
to
not break (and actually fix) single cluster systems and existing multi
cluster ones on which only the first cluster is supported now.

After that, per-CPU PMU offset should be implemented to support
multi-cluster SoCs with proper support of multiple clusters.



As of now the smp-boot (cores  2) is broken. This is required to fix it.



SMP boot works fine on all four cores of Exynos 4412. Obiously hot-(un)plug
doesn't, but this is another issue.



It works as of now as at power on all the cores powered on. Hence the
powerOn in platsmp.c doent make any difference,  It breaks in hotplug
as we always poweron cpu1, not the correct cpu.


Best regards,
Tomasz




--
with warm regards,
Chander Kashyap


Any other comments on this patch. If not then can it be merged?



Please make the patch account for supported Exynos 4 SoCs, with topology 
data specified. The fact that GIC driver is buggy right now doesn't mean 
that newly added code should assume that topology is not specified.


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: exynos: generalize power register address calculation

2014-04-14 Thread Tomasz Figa

Hi Chander,

Few more comments inline.

On 09.04.2014 13:09, Chander Kashyap wrote:

Currently status/configuration power register values are hard-coded for cpu1.

Make it generic so that it is useful for SoC's with more than two cpus.

Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
changes in v2 : Used existing macros for clusterid and cpuid calculation

  arch/arm/mach-exynos/hotplug.c  |   15 ---
  arch/arm/mach-exynos/platsmp.c  |   20 +++-
  arch/arm/mach-exynos/regs-pmu.h |9 +++--
  3 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..eab6121 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -17,6 +17,7 @@

  #include asm/cacheflush.h
  #include asm/cp15.h
+#include asm/cputype.h
  #include asm/smp_plat.h

  #include plat/cpu.h
@@ -92,11 +93,19 @@ static inline void cpu_leave_lowpower(void)

  static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
  {
+   unsigned int mpidr, cpunr, cluster;
+
+   mpidr = cpu_logical_map(cpu);
+   cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+   cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+   /* Maximum possible cpus in a cluster can be 4 */
+   cpunr += cluster * 4;


This could be put in a helper, as it seems to be used both by hotplug 
and platsmp code. Also 4 could be defined as a preprocessor macro.



for (;;) {

-   /* make cpu1 to be turned off at next WFI command */
-   if (cpu == 1)
-   __raw_writel(0, S5P_ARM_CORE1_CONFIGURATION);
+   /* make cpu to be turned off at next WFI command */
+   if (cpu)


Do you need this if here at all? I don't think there would be any 
problem with this function called for CPU 0 (which shouldn't happen 
anyway, without CPU 0 hotplug support enabled).



+   __raw_writel(0, S5P_ARM_CORE_CONFIGURATION(cpunr));

/*
 * here's the WFI
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 8ea02f6..8d06b2c 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -22,6 +22,7 @@
  #include linux/io.h

  #include asm/cacheflush.h
+#include asm/cputype.h
  #include asm/smp_plat.h
  #include asm/smp_scu.h
  #include asm/firmware.h
@@ -92,6 +93,14 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
  {
unsigned long timeout;
unsigned long phys_cpu = cpu_logical_map(cpu);
+   unsigned int mpidr, cpunr, cluster;
+
+   mpidr = cpu_logical_map(cpu);
+   cpunr = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+   cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+   /* Maximum possible cpus in a cluster can be 4 */
+   cpunr += cluster * 4;


Here basically the same code is used as in hotplug.c, so a helper would 
be nice. (e.g. cpunr = exynos_pmu_cpunr(mpidr)).




/*
 * Set synchronisation state between this boot processor
@@ -109,14 +118,15 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 */
write_pen_release(phys_cpu);

-   if (!(__raw_readl(S5P_ARM_CORE1_STATUS)  S5P_CORE_LOCAL_PWR_EN)) {
+   if (!(__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
+S5P_CORE_LOCAL_PWR_EN)) {
__raw_writel(S5P_CORE_LOCAL_PWR_EN,
-S5P_ARM_CORE1_CONFIGURATION);
+S5P_ARM_CORE_CONFIGURATION(cpunr));

timeout = 10;

-   /* wait max 10 ms until cpu1 is on */
-   while ((__raw_readl(S5P_ARM_CORE1_STATUS)
+   /* wait max 10 ms until secondary cpu is on */
+   while ((__raw_readl(S5P_ARM_CORE_STATUS(cpunr))
 S5P_CORE_LOCAL_PWR_EN) != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
@@ -125,7 +135,7 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
}

if (timeout == 0) {
-   printk(KERN_ERR cpu1 power enable failed);
+   pr_err(cpu%x power enable failed, cpu);


Shouldn't %d be used instead? cpu a on a 10-core machine would sound 
weird.



spin_unlock(boot_lock);
return -ETIMEDOUT;
}
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 7c029ce..16e17e4 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -104,8 +104,13 @@
  #define S5P_GPS_LOWPWRS5P_PMUREG(0x139C)
  #define S5P_GPS_ALIVE_LOWPWR  S5P_PMUREG(0x13A0)

-#define S5P_ARM_CORE1_CONFIGURATIONS5P_PMUREG(0x2080)
-#define S5P_ARM_CORE1_STATUS   S5P_PMUREG(0x2084)
+#define 

Re: [PATCH 4/4] regulator: s5m8767: Use same binding for external control as in s2mps11

2014-04-14 Thread Mark Brown
On Mon, Apr 14, 2014 at 10:09:09AM +0200, Krzysztof Kozlowski wrote:

 - - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one
 + - samsung,ext-control-gpios: (optional) GPIO specifier for one
   GPIO controlling this regulator (enable/disable); This is
   valid only for buck9.

This is an incompatible change.  It's OK to deprecate the old property
but it's bad form to just remove it.


signature.asc
Description: Digital signature


Re: [PATCH 3/4] Documentation: regulator: s2mps11: Document external GPIO control

2014-04-14 Thread Mark Brown
On Mon, Apr 14, 2014 at 10:09:08AM +0200, Krzysztof Kozlowski wrote:
 Add documentation for new property for controlling (enable/disable) some
 of the S2MPS14 regulators by GPIO.

Applied, thanks.


signature.asc
Description: Digital signature


Re: [PATCH 1/4] regulator: s2mps11: Move DTS parsing code to separate function

2014-04-14 Thread Mark Brown
On Mon, Apr 14, 2014 at 10:09:06AM +0200, Krzysztof Kozlowski wrote:
 Refactor code for parsing DTS to increase a little code readability. The
 behaviour should not change.

Applied, thanks.


signature.asc
Description: Digital signature


Re: [PATCH 2/4] regulator: s2mps11: Add external GPIO control for S2MPS14

2014-04-14 Thread Mark Brown
On Mon, Apr 14, 2014 at 10:09:07AM +0200, Krzysztof Kozlowski wrote:
 Add support for external control over GPIO for LDO10, LDO11 and LDO12
 S2MPS14 regulators. External control can be turned on by writing 0x0 to
 control register which in case of other regulators is used for disabling
 them. These LDO10-LDO12 regulators can be disabled only by I2C GPIO or
 PWREN pin so the patch actually allows proper way of disabling them.

Applied, thanks.


signature.asc
Description: Digital signature


[PATCH 08/20] cpufreq: exynos5440: Use cpufreq_for_each_entry macro for iteration

2014-04-14 Thread Stratos Karafotis
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.

It should have no functional changes.

Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
 drivers/cpufreq/exynos5440-cpufreq.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/cpufreq/exynos5440-cpufreq.c 
b/drivers/cpufreq/exynos5440-cpufreq.c
index a6b8214..3e3dd0c 100644
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -114,25 +114,23 @@ static struct cpufreq_freqs freqs;
 
 static int init_div_table(void)
 {
-   struct cpufreq_frequency_table *freq_tbl = dvfs_info-freq_table;
+   struct cpufreq_frequency_table *pos, *freq_tbl = dvfs_info-freq_table;
unsigned int tmp, clk_div, ema_div, freq, volt_id;
-   int i = 0;
struct dev_pm_opp *opp;
 
rcu_read_lock();
-   for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
-
+   cpufreq_for_each_entry(pos, freq_tbl) {
opp = dev_pm_opp_find_freq_exact(dvfs_info-dev,
-   freq_tbl[i].frequency * 1000, true);
+   pos-frequency * 1000, true);
if (IS_ERR(opp)) {
rcu_read_unlock();
dev_err(dvfs_info-dev,
failed to find valid OPP for %u KHZ\n,
-   freq_tbl[i].frequency);
+   pos-frequency);
return PTR_ERR(opp);
}
 
-   freq = freq_tbl[i].frequency / 1000; /* In MHZ */
+   freq = pos-frequency / 1000; /* In MHZ */
clk_div = ((freq / CPU_DIV_FREQ_MAX)  P0_7_CPUCLKDEV_MASK)
 P0_7_CPUCLKDEV_SHIFT;
clk_div |= ((freq / CPU_ATB_FREQ_MAX)  P0_7_ATBCLKDEV_MASK)
@@ -157,7 +155,8 @@ static int init_div_table(void)
tmp = (clk_div | ema_div | (volt_id  P0_7_VDD_SHIFT)
| ((freq / FREQ_UNIT)  P0_7_FREQ_SHIFT));
 
-   __raw_writel(tmp, dvfs_info-base + XMU_PMU_P0_7 + 4 * i);
+   __raw_writel(tmp, dvfs_info-base + XMU_PMU_P0_7 + 4 *
+   (pos - freq_tbl));
}
 
rcu_read_unlock();
@@ -166,8 +165,9 @@ static int init_div_table(void)
 
 static void exynos_enable_dvfs(unsigned int cur_frequency)
 {
-   unsigned int tmp, i, cpu;
+   unsigned int tmp, cpu;
struct cpufreq_frequency_table *freq_table = dvfs_info-freq_table;
+   struct cpufreq_frequency_table *pos;
/* Disable DVFS */
__raw_writel(0, dvfs_info-base + XMU_DVFS_CTRL);
 
@@ -182,15 +182,15 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
 __raw_writel(tmp, dvfs_info-base + XMU_PMUIRQEN);
 
/* Set initial performance index */
-   for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
-   if (freq_table[i].frequency == cur_frequency)
+   cpufreq_for_each_entry(pos, freq_table) {
+   if (pos-frequency == cur_frequency)
break;
+   }
 
-   if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
+   if (pos-frequency == CPUFREQ_TABLE_END) {
dev_crit(dvfs_info-dev, Boot up frequency not supported\n);
/* Assign the highest frequency */
-   i = 0;
-   cur_frequency = freq_table[i].frequency;
+   cur_frequency = freq_table-frequency;
}
 
dev_info(dvfs_info-dev, Setting dvfs initial frequency = %uKHZ,
@@ -199,7 +199,7 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
for (cpu = 0; cpu  CONFIG_NR_CPUS; cpu++) {
tmp = __raw_readl(dvfs_info-base + XMU_C0_3_PSTATE + cpu * 4);
tmp = ~(P_VALUE_MASK  C0_3_PSTATE_NEW_SHIFT);
-   tmp |= (i  C0_3_PSTATE_NEW_SHIFT);
+   tmp |= ((pos - freq_table)  C0_3_PSTATE_NEW_SHIFT);
__raw_writel(tmp, dvfs_info-base + XMU_C0_3_PSTATE + cpu * 4);
}
 
-- 
1.9.0
--
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 07/20] cpufreq: exynos: Use cpufreq_for_each_entry macro for iteration

2014-04-14 Thread Stratos Karafotis
The cpufreq core supports the cpufreq_for_each_entry macro helper
for iteration over the cpufreq_frequency_table, so use it.

It should have no functional changes.

Signed-off-by: Stratos Karafotis strat...@semaphore.gr
---
 drivers/cpufreq/exynos-cpufreq.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f99cfe2..0e19bce 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -28,18 +28,18 @@ static unsigned int locking_frequency;
 
 static int exynos_cpufreq_get_index(unsigned int freq)
 {
-   struct cpufreq_frequency_table *freq_table = exynos_info-freq_table;
-   int index;
+   struct cpufreq_frequency_table *pos, *freq_table;
 
-   for (index = 0;
-   freq_table[index].frequency != CPUFREQ_TABLE_END; index++)
-   if (freq_table[index].frequency == freq)
+   freq_table = exynos_info-freq_table;
+   cpufreq_for_each_entry(pos, freq_table) {
+   if (pos-frequency == freq)
break;
+   }
 
-   if (freq_table[index].frequency == CPUFREQ_TABLE_END)
+   if (pos-frequency == CPUFREQ_TABLE_END)
return -EINVAL;
 
-   return index;
+   return pos - freq_table;
 }
 
 static int exynos_cpufreq_scale(unsigned int target_freq)
-- 
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] ARM: dts: exynos5250-snow: add tps65090 power regulator

2014-04-14 Thread Doug Anderson
Sachin,

On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
 From: Doug Anderson diand...@chromium.org

 Added TPS65090 regulator related nodes to Snow board.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/boot/dts/exynos5250-snow.dts |   90 
 +
  1 file changed, 90 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index 469c85d..a38fd18 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -44,6 +44,13 @@
 sd3_bus4: sd3-bus-width4 {
 samsung,pin-drv = 0;
 };
 +
 +   tps65090_irq: tps65090-irq {
 +   samsung,pins = gpx2-6;
 +   samsung,pin-function = 0;
 +   samsung,pin-pud = 0;
 +   samsung,pin-drv = 0;
 +   };
 };

 pinctrl@1340 {
 @@ -75,6 +82,12 @@
 };
 };

 +   vbat: vbat-fixed-regulator {
 +   compatible = regulator-fixed;
 +   regulator-name = vbat-supply;
 +   regulator-boot-on;
 +   };
 +
 i2c-arbitrator {
 compatible = i2c-arb-gpio-challenge;
 #address-cells = 1;
 @@ -201,6 +214,83 @@
 0x070c0069;/* 
 LEFT */
 };
 };
 +
 +   power-regulator {
 +   compatible = ti,tps65090;
 +   reg = 0x48;
 +
 +   /*
 +* Config irq to disable internal pulls
 +* even though we run in polling mode.

This comment refers to a feature that hasn't yet been sent upstream.
...but it's a good reminder and I can send it upstream now.  You can
see it at:

* https://chromium-review.googlesource.com/62630
* https://chromium-review.googlesource.com/175653

Since this is only a comment I guess it's OK to refer to a feature
that hasn't yet landed (?).


 +*/
 +   pinctrl-names = default;
 +   pinctrl-0 = tps65090_irq;
 +
 +   vsys1-supply = vbat;
 +   vsys2-supply = vbat;
 +   vsys3-supply = vbat;
 +   infet1-supply = vbat;
 +   infet2-supply = vbat;
 +   infet3-supply = vbat;
 +   infet4-supply = vbat;
 +   infet5-supply = vbat;
 +   infet6-supply = vbat;
 +   infet7-supply = vbat;
 +   vsys-l1-supply = vbat;
 +   vsys-l2-supply = vbat;
 +
 +   regulators {
 +   dcdc1 {
 +   ti,enable-ext-control;
 +   };
 +   dcdc2 {
 +   ti,enable-ext-control;
 +   };
 +   dcdc3 {
 +   ti,enable-ext-control;
 +   };
 +   fet1 {
 +   regulator-name = vcd_led;
 +   ti,overcurrent-wait = 3;

This is also referring to something that hasn't been sent upstream yet.  See:
* https://chromium-review.googlesource.com/184607

 +   };
 +   tps65090_fet2: fet2 {
 +   regulator-name = video_mid;
 +   regulator-always-on;
 +   ti,overcurrent-wait = 3;
 +   };
 +   fet3 {
 +   regulator-name = wwan_r;
 +   regulator-always-on;
 +   ti,overcurrent-wait = 3;
 +   };
 +   fet4 {
 +   regulator-name = sdcard;
 +   ti,overcurrent-wait = 3;
 +   };
 +   fet5 {
 +   regulator-name = camout;
 

Re: [PATCH 1/4] ARM: dts: exynos5250-snow: add pinctrl for i2c-arbitrator

2014-04-14 Thread Doug Anderson
Tomasz,

On Mon, Apr 14, 2014 at 3:38 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
 Hi Doug,


 On 15.04.2014 00:30, Doug Anderson wrote:

 Sachin,

 On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat sachin.ka...@linaro.org
 wrote:

 From: Doug Anderson diand...@chromium.org


 I probably wouldn't have bothered giving me authorship since this
 isn't exactly a clean patch from the chromium tree (you pulled the
 proper pieces yourself, did the commit message yourself, etc).  ...but
 I appreciate the thought and as far as I know setting the author in
 cases like this is a bit of a judgement call...

 The Signed-off-by is certainly correct.  ;)


 Added i2c-arbitrator pinctrl node to Snow board.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
   arch/arm/boot/dts/exynos5250-snow.dts |   19 +++
   1 file changed, 19 insertions(+)


 This matches what's in our tree and and is what people are using, so:

 Reviewed-by: Doug Anderson diand...@chromium.org


 diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
 b/arch/arm/boot/dts/exynos5250-snow.dts
 index 1ce1088..32715b3 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -39,6 +39,22 @@
  };
  };

 +   pinctrl@1340 {
 +   arb_their_claim: arb-their-claim {
 +   samsung,pins = gpe0-4;
 +   samsung,pin-function = 0;
 +   samsung,pin-pud = 3;
 +   samsung,pin-drv = 0;
 +   };
 +
 +   arb_our_claim: arb-our-claim {
 +   samsung,pins = gpf0-3;
 +   samsung,pin-function = 1;
 +   samsung,pin-pud = 0;
 +   samsung,pin-drv = 0;
 +   };


 It's odd to me that one of these has a pullup but not the other, but I
 think that's because the arbitration lines ended up using some other
 signals that were originally hooked up for other usage.  Certainly the
 pullups / pulldowns match what's in our tree and also match what we
 had in the original shipping 3.4 kernel.


 Just a wild guess, but probably the input needs a pull-up, while obviously
 the output doesn't. I don't have much idea about the arbitration thing
 happening on snow, so I can't say much about this series. (Maybe description
 of patch 1/4 should be saying a bit more about the meaning of this?)

Right, of course.  I'm not sure quite what I was thinking.  I think I
was getting confused since these go through level converters and my
brain was in open drain mode.  ...but looking at this again this looks
reasonable.

I think the whole discussion of arbitration was from a long time ago.
I think it's fairly well documented in the i2c-arb-gpio-challenge
driver.

Basically it looks like Sachin is getting pinctrl stuff matched up
properly for the device tree that's upstream.

-Doug
--
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 4/4] ARM: dts: exynos5250-snow: add ptn3460 node

2014-04-14 Thread Doug Anderson
Sachin,

On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
 From: Doug Anderson diand...@chromium.org

For this patch in particular giving me authorship is pretty tenuous.
I don't think I was even the author of the majority of the code in the
chromium tree.


 Added nodes for ptn3460 driver to Snow board.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/boot/dts/exynos5250-snow.dts |   19 +++
  1 file changed, 19 insertions(+)

I don't see any problems here but really the graphics people are the
ones that should be commenting.  Added a few folks to the CC list.

For the general GPIOs / pinctrl stuff, though:

Reviewed-by: Doug Anderson diand...@chromium.org


...and as Olof points out, please let us know how this was all tested.
--
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 4/4] ARM: dts: exynos5250-snow: add ptn3460 node

2014-04-14 Thread Olof Johansson
Hi Sachin,

On Mon, Apr 14, 2014 at 6:16 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
 From: Doug Anderson diand...@chromium.org

 Added nodes for ptn3460 driver to Snow board.

 Signed-off-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

I'm curious, how are you testing this code on the upstream kernel
before you post the patches?

Especially since Doug was referring to some of these containing parts
that is needed for drivers that are not yet upstreamed.


-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

2014-04-14 Thread Joonyoung Shim

Hi Tomasz,

On 04/15/2014 12:00 AM, Tomasz Stanislawski wrote:

This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
  drivers/gpu/drm/exynos/exynos_hdmi.c  |3 +++
  drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
  2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d2d6e2e..6fa63ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2032,6 +2032,9 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
  
  static struct of_device_id hdmi_match_types[] = {

{
+   .compatible = samsung,exynos4210-hdmi,
+   .data   = (void *)HDMI_TYPE13,


It's consistent with others to use struct hdmi_driver_data like
exynos5_hdmi_driver_data.


+   }, {
.compatible = samsung,exynos5-hdmi,
.data = exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
  
  static struct of_device_id mixer_match_types[] = {

{
+   .compatible = samsung,exynos4210-mixer,
+   .data   = exynos4210_mxr_drv_data,
+   }, {
.compatible = samsung,exynos5-mixer,
.data   = exynos5250_mxr_drv_data,
}, {


--
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 7/8] arm64: mm: Implement 4 levels of translation tables

2014-04-14 Thread Jungseok Lee
On Tuesday, April 15, 2014 12:14 AM, Steve Capper wrote:
 On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
  This patch implements 4 levels of translation tables since 3 levels of
  page tables with 4KB pages cannot support 40-bit physical address
  space described in [1] due to the following issue.
 
  It is a restriction that kernel logical memory map with 4KB + 3 levels
  (0xffc0-0x) cannot cover RAM region from
  544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
  mapping for this region in map_mem function since __phys_to_virt for
  this region reaches to address overflow.
 
  If SoC design follows the document, [1], over 32GB RAM would be placed
  from 544GB. Even 64GB system is supposed to use the region from 544GB
  to 576GB for only 32GB RAM. Naturally, it would reach to enable 4
  levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
 
  However, it is recommended 4 levels of page table should be only
  enabled if memory map is too sparse or there is about 512GB RAM.
 
  References
  --
  [1]: Principle of ARM Memory Maps, White Paper, Issue C
 
 
 Hi Jungseok,
 I've given this a quick run on the Fast Model with huge pages, and it passed 
 the libhugetlbfs test
 suite.

It sounds good.

 Some comments/suggestions below...

I really thank you.

  Signed-off-by: Jungseok Lee jays@samsung.com
  Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
  ---
   arch/arm64/Kconfig |7 +
   arch/arm64/include/asm/page.h  |4 ++-
   arch/arm64/include/asm/pgalloc.h   |   20 ++
   arch/arm64/include/asm/pgtable-hwdef.h |8 --
   arch/arm64/include/asm/pgtable.h   |   44 
  +--
   arch/arm64/include/asm/tlb.h   |8 ++
   arch/arm64/kernel/head.S   |   45 
  ++--
   arch/arm64/kernel/traps.c  |5 
   arch/arm64/mm/fault.c  |1 +
   arch/arm64/mm/mmu.c|   14 +-
   10 files changed, 148 insertions(+), 8 deletions(-)
 
  diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index
  431acbc..7f5270b 100644
  --- a/arch/arm64/Kconfig
  +++ b/arch/arm64/Kconfig
  @@ -184,12 +184,19 @@ config ARM64_3_LEVELS
  help
This feature enables 3 levels of translation tables.
 
  +config ARM64_4_LEVELS
  +   bool 4 level
  +   depends on ARM64_4K_PAGES
  +   help
  + This feature enables 4 levels of translation tables.
  +
   endchoice
 
   config ARM64_VA_BITS
  int Virtual address space size
  range 39 39 if ARM64_4K_PAGES  ARM64_3_LEVELS
  range 42 42 if ARM64_64K_PAGES  ARM64_2_LEVELS
  +   range 48 48 if ARM64_4K_PAGES  ARM64_4_LEVELS
  help
This feature is determined by a combination of page size and
level of translation tables.
  diff --git a/arch/arm64/include/asm/page.h
  b/arch/arm64/include/asm/page.h index 268e53d..83b5289 100644
  --- a/arch/arm64/include/asm/page.h
  +++ b/arch/arm64/include/asm/page.h
  @@ -35,8 +35,10 @@
 
   #ifdef CONFIG_ARM64_2_LEVELS
   #include asm/pgtable-2level-types.h -#else
  +#elif defined(CONFIG_ARM64_3_LEVELS)
   #include asm/pgtable-3level-types.h
  +#else
  +#include asm/pgtable-4level-types.h
   #endif
 
   extern void __cpu_clear_user_page(void *p, unsigned long user); diff
  --git a/arch/arm64/include/asm/pgalloc.h
  b/arch/arm64/include/asm/pgalloc.h
  index 4829837..8d745fa 100644
  --- a/arch/arm64/include/asm/pgalloc.h
  +++ b/arch/arm64/include/asm/pgalloc.h
  @@ -26,6 +26,26 @@
 
   #define check_pgt_cache()  do { } while (0)
 
  +#ifdef CONFIG_ARM64_4_LEVELS
  +
  +static inline pud_t *pud_alloc_one(struct mm_struct *mm, unsigned
  +long addr) {
  +   return (pud_t *)get_zeroed_page(GFP_KERNEL | __GFP_REPEAT); }
  +
  +static inline void pud_free(struct mm_struct *mm, pud_t *pud) {
  +   BUG_ON((unsigned long)pud  (PAGE_SIZE-1));
  +   free_page((unsigned long)pud);
  +}
  +
  +static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgd,
  +pud_t *pud) {
  +   set_pgd(pgd, __pgd(__pa(pud) | PUD_TYPE_TABLE));
 
 Perhaps instead use PGD_TYPE_TABLE?

pud_populate uses PMD_TYPE_TABLE. That is why I choose PUD_TYPE_TABLE
instead of PGD_TYPE_TABLE.

  +}
  +
  +#endif  /* CONFIG_ARM64_4_LEVELS */
  +
   #ifndef CONFIG_ARM64_2_LEVELS
 
   static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned
  long addr) diff --git a/arch/arm64/include/asm/pgtable-hwdef.h
  b/arch/arm64/include/asm/pgtable-hwdef.h
  index 9cd86c6..03ad81b 100644
  --- a/arch/arm64/include/asm/pgtable-hwdef.h
  +++ b/arch/arm64/include/asm/pgtable-hwdef.h
  @@ -18,8 +18,10 @@
 
   #ifdef CONFIG_ARM64_2_LEVELS
   #include asm/pgtable-2level-hwdef.h -#else
  +#elif defined(CONFIG_ARM64_3_LEVELS)
   #include asm/pgtable-3level-hwdef.h
  +#else
  +#include asm/pgtable-4level-hwdef.h
   #endif
 
   /*
  @@ -27,7 +29,9 @@
*
* Level 1 

Re: [PATCH 2/8] arm/arm64: KVM: Fix line length exceeding 80 characters

2014-04-14 Thread Jungseok Lee
On Tuesday, April 15, 2014 1:19 AM, Marc Zyngier wrote:
 On 14/04/14 08:40, Jungseok Lee wrote:
  This patch deals with checkpatch complaint as fixing line length
  exceeding 80 characters.
 
  WARNING: line over 80 characters
 
  Signed-off-by: Jungseok Lee jays@samsung.com
  Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
  ---
   arch/arm/kvm/mmu.c |4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)
 
  diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index
  80bb1e6..e0d4f24 100644
  --- a/arch/arm/kvm/mmu.c
  +++ b/arch/arm/kvm/mmu.c
  @@ -563,8 +563,8 @@ void kvm_free_stage2_pgd(struct kvm *kvm)
  kvm-arch.pgd = NULL;
   }
 
  -static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache 
  *cache,
  -phys_addr_t addr)
  +static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache
  +*cache, phys_addr_t addr)
 
 Please don't. This makes the code unreadable (and no, I don't care about 
 checkpatch ;-).

Okay. I will drop this patch from the next version.

It would be good to change stage2_set_pmd_huge function for readability
if you don't care about checkpatch.

Best Regards
Jungseok Lee

--
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 8/8] arm64: KVM: Implement 4 levels of translation tables for HYP and stage2

2014-04-14 Thread Jungseok Lee
On Tuesday, April 15, 2014 1:12 AM, Marc Zyngier wrote:
 On 14/04/14 08:41, Jungseok Lee wrote:
  This patch adds 4 levels of translation tables implementation for both
  HYP and stage2. A combination of 4KB + 4 levels host and 4KB + 4
  levels guest can run on ARMv8 architecture as introducing this feature.
 
  Signed-off-by: Jungseok Lee jays@samsung.com
  Reviewed-by: Sungjinn Chung sungjinn.ch...@samsung.com
  ---
   arch/arm/kvm/mmu.c   |   96 
  +-
   arch/arm64/include/asm/kvm_arm.h |   20 
   arch/arm64/include/asm/kvm_mmu.h |1 +
   3 files changed, 106 insertions(+), 11 deletions(-)
 
  diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index
  e0d4f24..6cf89ad 100644
  --- a/arch/arm/kvm/mmu.c
  +++ b/arch/arm/kvm/mmu.c
  @@ -388,13 +388,46 @@ static int create_hyp_pmd_mappings(pud_t *pud, 
  unsigned long start,
  return 0;
   }
 
  +static int create_hyp_pud_mappings(pgd_t *pgd, unsigned long start,
  +  unsigned long end, unsigned long pfn,
  +  pgprot_t prot)
  +{
  +   pud_t *pud;
  +   pmd_t *pmd;
  +   unsigned long addr, next;
  +
  +   addr = start;
  +   do {
  +   pud = pud_offset(pgd, addr);
  +
  +   if (pud_none_or_clear_bad(pud)) {
  +   pmd = pmd_alloc_one(NULL, addr);
  +   if (!pmd) {
  +   kvm_err(Cannot allocate Hyp pmd\n);
  +   return -ENOMEM;
  +   }
  +   pud_populate(NULL, pud, pmd);
  +   get_page(virt_to_page(pud));
  +   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
  +   }
  +
  +   next = pud_addr_end(addr, end);
  +
  +   create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
  +   pfn += (next - addr)  PAGE_SHIFT;
  +   } while (addr = next, addr != end);
  +
  +   return 0;
  +}
  +
   static int __create_hyp_mappings(pgd_t *pgdp,
   unsigned long start, unsigned long end,
   unsigned long pfn, pgprot_t prot)  {
  pgd_t *pgd;
  +#ifdef CONFIG_ARM64_4_LEVELS
  pud_t *pud;
  -   pmd_t *pmd;
  +#endif
  unsigned long addr, next;
  int err = 0;
 
  @@ -403,22 +436,25 @@ static int __create_hyp_mappings(pgd_t *pgdp,
  end = PAGE_ALIGN(end);
  do {
  pgd = pgdp + pgd_index(addr);
  -   pud = pud_offset(pgd, addr);
 
  -   if (pud_none_or_clear_bad(pud)) {
  -   pmd = pmd_alloc_one(NULL, addr);
  -   if (!pmd) {
  -   kvm_err(Cannot allocate Hyp pmd\n);
  +#ifdef CONFIG_ARM64_4_LEVELS
  +   if (pgd_none(*pgd)) {
  +   pud = pud_alloc_one(NULL, addr);
  +   if (!pud) {
  +   kvm_err(Cannot allocate Hyp pud\n);
  err = -ENOMEM;
  goto out;
  }
  -   pud_populate(NULL, pud, pmd);
  -   get_page(virt_to_page(pud));
  -   kvm_flush_dcache_to_poc(pud, sizeof(*pud));
  +   pgd_populate(NULL, pgd, pud);
  +   get_page(virt_to_page(pgd));
  +   kvm_flush_dcache_to_poc(pgd, sizeof(*pgd));
  }
  +#endif
 
 Why do you need all these #ifdefs? The page table code should be able to cope 
 with all the variations
 of presence/absence of pud/pmd (see how there is no code difference between 
 4kB (3 levels) and 64kB (2
 levels)).

Okay, I will remove it.

  next = pgd_addr_end(addr, end);
  -   err = create_hyp_pmd_mappings(pud, addr, next, pfn, prot);
  +
  +   err = create_hyp_pud_mappings(pgd, addr, next, pfn, prot);
  +
  if (err)
  goto out;
  pfn += (next - addr)  PAGE_SHIFT; @@ -563,6 +599,26 @@ void
  kvm_free_stage2_pgd(struct kvm *kvm)
  kvm-arch.pgd = NULL;
   }
 
  +#ifdef CONFIG_ARM64_4_LEVELS
  +static pud_t *stage2_get_pud(struct kvm *kvm, struct kvm_mmu_memory_cache
  +*cache, phys_addr_t addr)
  +{
  +   pgd_t *pgd;
  +   pud_t *pud;
  +
  +   pgd = kvm-arch.pgd + pgd_index(addr);
  +   if (pgd_none(*pgd)) {
  +   if (!cache)
  +   return NULL;
  +   pud = mmu_memory_cache_alloc(cache);
  +   pgd_populate(NULL, pgd, pud);
  +   get_page(virt_to_page(pgd));
  +   }
  +
  +   return pud_offset(pgd, addr);
  +}
  +#endif
 
 Same here.

Okay.

   static pmd_t *stage2_get_pmd(struct kvm *kvm, struct kvm_mmu_memory_cache
   *cache, phys_addr_t addr)
   {
  @@ -617,6 +673,24 @@ static int stage2_set_pte(struct kvm *kvm, struct 
  kvm_mmu_memory_cache *cache,
  pmd_t *pmd;
  pte_t *pte, old_pte;
 
  +#ifdef CONFIG_ARM64_4_LEVELS
  +   pud_t *pud;
  +
  +   /* Create stage-2 page table 

Re: [PATCH 7/8] arm64: mm: Implement 4 levels of translation tables

2014-04-14 Thread Jungseok Lee
On Tuesday, April 15, 2014 12:14 AM, Steve Capper wrote:
 On Mon, Apr 14, 2014 at 04:41:07PM +0900, Jungseok Lee wrote:
  This patch implements 4 levels of translation tables since 3 levels of
  page tables with 4KB pages cannot support 40-bit physical address
  space described in [1] due to the following issue.
 
  It is a restriction that kernel logical memory map with 4KB + 3 levels
  (0xffc0-0x) cannot cover RAM region from
  544GB to 1024GB in [1]. Specifically, ARM64 kernel fails to create
  mapping for this region in map_mem function since __phys_to_virt for
  this region reaches to address overflow.
 
  If SoC design follows the document, [1], over 32GB RAM would be placed
  from 544GB. Even 64GB system is supposed to use the region from 544GB
  to 576GB for only 32GB RAM. Naturally, it would reach to enable 4
  levels of page tables to avoid hacking __virt_to_phys and __phys_to_virt.
 
  However, it is recommended 4 levels of page table should be only
  enabled if memory map is too sparse or there is about 512GB RAM.
 
  References
  --
  [1]: Principle of ARM Memory Maps, White Paper, Issue C
 

[ ... ]

  diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index
  6b7e895..321f569 100644
  --- a/arch/arm64/mm/mmu.c
  +++ b/arch/arm64/mm/mmu.c
  @@ -222,9 +222,17 @@ static void __init alloc_init_pmd(pud_t *pud,
  unsigned long addr,  static void __init alloc_init_pud(pgd_t *pgd, unsigned 
  long addr,
unsigned long end, unsigned long phys)  {
  -   pud_t *pud = pud_offset(pgd, addr);
  +   pud_t *pud;
  unsigned long next;
 
  +#ifdef CONFIG_ARM64_4_LEVELS
  +   if (pgd_none(*pgd) || pgd_bad(*pgd)) {
  +   pud = early_alloc(PTRS_PER_PUD * sizeof(pud_t));
  +   pgd_populate(init_mm, pgd, pud);
  +   }
  +#endif
 
 We don't need this #ifdef block, as pgd_none and pgd_bad should be zero when 
 we have fewer than 4
 levels.

This block is needed to cover the third RAM region from 544GB to 1024GB
described in the document [1].

A single PGD can cover only up to 512GB with 4KB+4Level. In other words,
kernel would reach to panic if a system has RAM over 512GB memory map space.
That is why pgd_none should be handled.

Best Regards
Jungseok Lee

--
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


[PATCHv2 0/8] Support new Exynos3250 SoC based on Cortex-A7 dual core

2014-04-14 Thread Chanwoo Choi
This patchset support new Exynos3250 Samsung SoC based on Cortex-A7 dual core.
Exynos3250 is a System-On-Chip (SoC) that is based on 32-bit RISC processor
for Smartphone. It is desigend with the 28nm low-power high-K metal gate process
and provides the best performance features.

This patchset include some patches such as:
- Support secondary CPU of Exynos3250 (cpu up/down)
- Supoort uart/mct/adc/gic/i2c/spi/power-domain/pmu/mshc/pwm/amba
- Support the clock control for Exynos3250 using common clk framework

This patchset is completely tested and is based on following git repo/branch.
- git repo : git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
- branch   : for-next (Linux 3.15-rc1)

Additional patch description about static memory mapping:
Arnd Bergmann suggested that need proper driver instead of static memory 
mapping.
As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1]
for memory mapping for SYSRAM.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html
[2] https://lkml.org/lkml/2014/4/10/161

So, I'm going to re-implement following patches related to static memory mapping
after merged Sachin Kamat patch[1].
  ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
  ARM: EXYNOS: Add IO mapping for PMU of Exynos3250

Changes from v1:
- Add new samsung,exynos3 compatible name
- Add comment about exynos_cpu_boot in Exynos4212
- Remove unnecessary 'goto' statement in firmware.c
- Use read_cpuid_part_number() function instead of assembler directly
- Post separated pinctrl patch from this patchset
  : https://lkml.org/lkml/2014/4/13/156
- Remove unused pmu interrupts due to Exynos3250 dual-core
- Cosolidate all the patches related to exynos3250.dtsi into one patch
- Fix gic compatible name to cortex-a15-gic because Cortex-A7 GIC is same
- Add sign-off of sender to all this patches
- Fix minor typo

Chanwoo Choi (5):
  ARM: EXYNOS: Add Exynos3250 SoC ID
  ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250
  ARM: EXYNOS: Add IO mapping for PMU of Exynos3250
  ARM: EXYNOS: Support secondary CPU boot of Exynos3250
  ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7

Kyungmin Park (1):
  ARM: EXYNOS: Support secondary CPU boot of Exynos4212

Tomasz Figa (2):
  clk: samsung: exynos3250: Add clocks using common clock framework
  ARM: dts: Add device tree sources for Exynos3250

 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++
 arch/arm/boot/dts/exynos3250.dtsi | 410 
 arch/arm/mach-exynos/Kconfig  |  22 +
 arch/arm/mach-exynos/exynos.c |  19 +
 arch/arm/mach-exynos/firmware.c   |  18 +-
 arch/arm/mach-exynos/hotplug.c|  16 +-
 arch/arm/mach-exynos/include/mach/map.h   |   2 +
 arch/arm/plat-samsung/include/plat/cpu.h  |  10 +
 drivers/clk/samsung/Makefile  |   1 +
 drivers/clk/samsung/clk-exynos3250.c  | 785 ++
 include/dt-bindings/clock/exynos3250.h| 256 ++
 11 files changed, 2010 insertions(+), 6 deletions(-)
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

-- 
1.8.0

--
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


[PATCHv2 8/8] ARM: dts: Add device tree sources for Exynos3250

2014-04-14 Thread Chanwoo Choi
From: Tomasz Figa t.f...@samsung.com

This patch add new exynos3250.dtsi to support Exynos3250 SoC based on Cortex-A7
dual core and includes following dt nodes:

- GIC interrupt controller
- Pinctrl to control GPIOs
- Clock controller
- CPU information (Cortex-A7 dual core)
- UART to support serial port
- MCT (Multi Core Timer)
- ADC (Analog Digital Converter)
- I2C/SPI bus
- Power domain
- PMU (Performance Monitoring Unit)
- MSHC (Mobile Storage Host Controller)
- PWM (Pluse Width Modulation)
- AMBA bus

Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: Russell King li...@arm.linux.org.uk
Cc: devicet...@vger.kernel.org
---
 arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 477 ++
 arch/arm/boot/dts/exynos3250.dtsi | 410 +
 2 files changed, 887 insertions(+)
 create mode 100644 arch/arm/boot/dts/exynos3250-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/exynos3250.dtsi

diff --git a/arch/arm/boot/dts/exynos3250-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
new file mode 100644
index 000..976490b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos3250-pinctrl.dtsi
@@ -0,0 +1,477 @@
+/*
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos3250 SoCs pin-mux and pin-config optiosn are listed as 
device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+/ {
+   pinctrl@1140 {
+   gpa0: gpa0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpa1: gpa1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpb: gpb {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc0: gpc0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpc1: gpc1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd0: gpd0 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   gpd1: gpd1 {
+   gpio-controller;
+   #gpio-cells = 2;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+
+   uart0_data: uart0-data {
+   samsung,pins = gpa0-0, gpa0-1;
+   samsung,pin-function = 0x2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   uart0_fctl: uart0-fctl {
+   samsung,pins = gpa0-2, gpa0-3;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   uart1_data: uart1-data {
+   samsung,pins = gpa0-4, gpa0-5;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   uart1_fctl: uart1-fctl {
+   samsung,pins = gpa0-6, gpa0-7;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   i2c2_bus: i2c2-bus {
+   samsung,pins = gpa0-6, gpa0-7;
+ 

[PATCHv2 7/8] clk: samsung: exynos3250: Add clocks using common clock framework

2014-04-14 Thread Chanwoo Choi
From: Tomasz Figa t.f...@samsung.com

This patch add new the clock drvier of Exynos3250 SoC based on Cortex-A7
using common clock framework. The CMU (Clock Management Unit) of Exynos3250
control PLLs(Phase Locked Loops) and generate system clocks for CPU, buses,
and function clocks for individual IPs.

The CMU of Exynos3250 includes following clock doamins:
- CPU block for Cortex-A7 MPCore processor
- LEFTBUS/RIGHTBUS block
- TOP block for G3D/MFC/LCD0/ISP/CAM/FSYS/MFC/PERIL/PERIR

Changes from v1:
- None

Cc: Mike Turquette mturque...@linaro.org
Cc: Kukjin Kim kgene@samsung.com
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Signed-off-by: Tomasz Figa t.f...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Seung-Woo Kim sw0312@samsung.com
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Karol Wrona k.wr...@samsung.com
Signed-off-by: YoungJun Cho yj44@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/clk/samsung/Makefile   |   1 +
 drivers/clk/samsung/clk-exynos3250.c   | 785 +
 include/dt-bindings/clock/exynos3250.h | 256 +++
 3 files changed, 1042 insertions(+)
 create mode 100644 drivers/clk/samsung/clk-exynos3250.c
 create mode 100644 include/dt-bindings/clock/exynos3250.h

diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 8eb4799..d120797 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_COMMON_CLK)   += clk.o clk-pll.o
+obj-$(CONFIG_SOC_EXYNOS3250)   += clk-exynos3250.o
 obj-$(CONFIG_ARCH_EXYNOS4) += clk-exynos4.o
 obj-$(CONFIG_SOC_EXYNOS5250)   += clk-exynos5250.o
 obj-$(CONFIG_SOC_EXYNOS5420)   += clk-exynos5420.o
diff --git a/drivers/clk/samsung/clk-exynos3250.c 
b/drivers/clk/samsung/clk-exynos3250.c
new file mode 100644
index 000..0574a76
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -0,0 +1,785 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Common Clock Framework support for Exynos3250 SoC.
+ */
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/syscore_ops.h
+
+#include dt-bindings/clock/exynos3250.h
+
+#include clk.h
+#include clk-pll.h
+
+#define SRC_LEFTBUS0x4200
+#define DIV_LEFTBUS0x4500
+#define GATE_IP_LEFTBUS0x4800
+#define SRC_RIGHTBUS   0x8200
+#define DIV_RIGHTBUS   0x8500
+#define GATE_IP_RIGHTBUS   0x8800
+#define GATE_IP_PERIR  0x8960
+#define MPLL_LOCK  0xc010
+#define MPLL_CON0  0xc110
+#define VPLL_LOCK  0xc020
+#define VPLL_CON0  0xc120
+#define UPLL_LOCK  0xc030
+#define UPLL_CON0  0xc130
+#define SRC_TOP0   0xc210
+#define SRC_TOP1   0xc214
+#define SRC_CAM0xc220
+#define SRC_MFC0xc228
+#define SRC_G3D0xc22c
+#define SRC_LCD0xc234
+#define SRC_ISP0xc238
+#define SRC_FSYS   0xc240
+#define SRC_PERIL0 0xc250
+#define SRC_PERIL1 0xc254
+#define SRC_MASK_TOP   0xc310
+#define SRC_MASK_CAM   0xc320
+#define SRC_MASK_LCD   0xc334
+#define SRC_MASK_ISP   0xc338
+#define SRC_MASK_FSYS  0xc340
+#define SRC_MASK_PERIL00xc350
+#define SRC_MASK_PERIL10xc354
+#define DIV_TOP0xc510
+#define DIV_CAM0xc520
+#define DIV_MFC0xc528
+#define DIV_G3D0xc52c
+#define DIV_LCD0xc534
+#define DIV_ISP0xc538
+#define DIV_FSYS0  0xc540
+#define DIV_FSYS1  0xc544
+#define DIV_FSYS2  0xc548
+#define DIV_PERIL0 0xc550
+#define DIV_PERIL1 0xc554
+#define DIV_PERIL3 0xc55c
+#define DIV_PERIL4 0xc560
+#define DIV_PERIL5 0xc564
+#define DIV_CAM1   0xc568
+#define CLKDIV2_RATIO  0xc580
+#define GATE_SCLK_CAM  0xc820
+#define GATE_SCLK_MFC  0xc828
+#define GATE_SCLK_G3D  0xc82c
+#define GATE_SCLK_LCD  0xc834
+#define GATE_SCLK_ISP_TOP  0xc838
+#define 

[PATCHv2 5/8] ARM: EXYNOS: Support secondary CPU boot of Exynos3250

2014-04-14 Thread Chanwoo Choi
This patch fix the offset of CPU boot address and don't operate smc call
of SMC_CMD_CPU1BOOT command for Exynos3250.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/firmware.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index aa01c42..6205d4f 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -30,13 +30,16 @@ static int exynos_do_idle(void)
 
 static int exynos_cpu_boot(int cpu)
 {
+   if (soc_is_exynos3250()) {
+   return 0;
/*
 * The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
 * But, Exynos4212 has only one secondary CPU so second parameter
 * isn't used for informing secure firmware about CPU id.
 */
-   if (soc_is_exynos4212())
+   } else if (soc_is_exynos4212()) {
cpu = 0;
+   }
 
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
@@ -46,7 +49,7 @@ static int exynos_set_cpu_boot_addr(int cpu, unsigned long 
boot_addr)
 {
void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
 
-   if (!soc_is_exynos4212())
+   if (!soc_is_exynos4212()  !soc_is_exynos3250())
boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
-- 
1.8.0

--
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


[PATCHv2 4/8] ARM: EXYNOS: Support secondary CPU boot of Exynos4212

2014-04-14 Thread Chanwoo Choi
From: Kyungmin Park kyungmin.p...@samsung.com

This patch fix the offset of CPU boot address and change parameter of smc call
of SMC_CMD_CPU1BOOT command for Exynos4212.

Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
 arch/arm/mach-exynos/firmware.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 932129e..aa01c42 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -18,6 +18,8 @@
 
 #include mach/map.h
 
+#include plat/cpu.h
+
 #include smc.h
 
 static int exynos_do_idle(void)
@@ -28,13 +30,24 @@ static int exynos_do_idle(void)
 
 static int exynos_cpu_boot(int cpu)
 {
+   /*
+* The second parameter of SMC_CMD_CPU1BOOT command means CPU id.
+* But, Exynos4212 has only one secondary CPU so second parameter
+* isn't used for informing secure firmware about CPU id.
+*/
+   if (soc_is_exynos4212())
+   cpu = 0;
+
exynos_smc(SMC_CMD_CPU1BOOT, cpu, 0, 0);
return 0;
 }
 
 static int exynos_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
 {
-   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c + 4*cpu;
+   void __iomem *boot_reg = S5P_VA_SYSRAM_NS + 0x1c;
+
+   if (!soc_is_exynos4212())
+   boot_reg += 4*cpu;
 
__raw_writel(boot_addr, boot_reg);
return 0;
-- 
1.8.0

--
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


[PATCHv2 2/8] ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250

2014-04-14 Thread Chanwoo Choi
The non-secure SYSRAM is used for secondary CPU bring-up. This patch add
IO mapping for non-scure SYSRAM.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
Arnd Bergmann suggested that need proper driver instead of static memory 
mapping.
As Chanho Park reply[2], Sachin Kamat already posted the DT support patch[1]
for memory mapping for SYSRAM.
[1] http://www.spinics.net/lists/linux-samsung-soc/msg27647.html
[2] https://lkml.org/lkml/2014/4/10/161

So, I'm going to re-implement following patch related to static memory mapping
after merged Sachin Kamat patch[1].
  ARM: EXYNOS: Add IO mapping for non-secure SYSRAM of Exynos3250

 arch/arm/mach-exynos/exynos.c   | 12 
 arch/arm/mach-exynos/include/mach/map.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a603dfa..c7c9472 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -35,6 +35,15 @@
 #define L2_AUX_VAL 0x7C470001
 #define L2_AUX_MASK 0xC200
 
+static struct map_desc exynos3250_iodesc[] __initdata = {
+   {
+   .virtual= (unsigned long)S5P_VA_SYSRAM_NS,
+   .pfn= __phys_to_pfn(EXYNOS3_PA_SYSRAM_NS),
+   .length = SZ_4K,
+   .type   = MT_DEVICE,
+   },
+};
+
 static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -275,6 +284,9 @@ static int __init exynos_fdt_map_chipid(unsigned long node, 
const char *uname,
  */
 static void __init exynos_map_io(void)
 {
+   if (soc_is_exynos3250())
+   iotable_init(exynos3250_iodesc, ARRAY_SIZE(exynos3250_iodesc));
+
if (soc_is_exynos4())
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
 
diff --git a/arch/arm/mach-exynos/include/mach/map.h 
b/arch/arm/mach-exynos/include/mach/map.h
index 7b046b5..a53981b 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -26,6 +26,7 @@
 #define EXYNOS4_PA_SYSRAM0 0x02025000
 #define EXYNOS4_PA_SYSRAM1 0x0202
 #define EXYNOS5_PA_SYSRAM  0x0202
+#define EXYNOS3_PA_SYSRAM_NS   0x0205F000
 #define EXYNOS4210_PA_SYSRAM_NS0x0203F000
 #define EXYNOS4x12_PA_SYSRAM_NS0x0204F000
 #define EXYNOS5250_PA_SYSRAM_NS0x0204F000
-- 
1.8.0

--
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


[PATCHv2 6/8] ARM: EXYNOS: Enter a15 lowpower mode for Exynos3250 based on Cortex-a7

2014-04-14 Thread Chanwoo Choi
This patch decide proper lowpower mode of either a15 or a9 according to own ID
from Main ID register.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/hotplug.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 5eead53..99e54e0 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -135,16 +135,22 @@ void __ref exynos_cpu_die(unsigned int cpu)
int primary_part = 0;
 
/*
-* we're ready for shutdown now, so do it.
-* Exynos4 is A9 based while Exynos5 is A15; check the CPU part
+* we're ready for shutdown now, so do it. Exynos4 is A9 based
+* while Exynos5 is A15/Exynos3 is A7; check the CPU part
 * number by reading the Main ID register and then perform the
 * appropriate sequence for entering low power.
 */
-   asm(mrc p15, 0, %0, c0, c0, 0 : =r(primary_part) : : cc);
-   if ((primary_part  0xfff0) == 0xc0f0)
+   primary_part = read_cpuid_part_number();
+
+   switch (primary_part) {
+   case ARM_CPU_PART_CORTEX_A7:
+   case ARM_CPU_PART_CORTEX_A15:
cpu_enter_lowpower_a15();
-   else
+   break;
+   default:
cpu_enter_lowpower_a9();
+   break;
+   }
 
platform_do_lowpower(cpu, spurious);
 
-- 
1.8.0

--
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


  1   2   >