Re: [PATCH 05/11] spi/pl022: Convert to core runtime PM
On Sun, Jul 28, 2013 at 10:52:38PM +0200, Linus Walleij wrote: Someone moaned about oneline commit messages in the last LWN... I saw that (and even followed up). To be honest for this sort of patch I'm not that concerned about it - it's fairly clear what's going on and why it might be a good idea. signature.asc Description: Digital signature
Re: [PATCH v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs
Hi KyongHo, On 26 July 2013 16:58, Cho KyongHo pullip@samsung.com wrote: Signed-off-by: Cho KyongHo pullip@samsung.com --- .../bindings/iommu/samsung,exynos4210-sysmmu.txt | 103 +++ arch/arm/boot/dts/exynos4.dtsi | 122 arch/arm/boot/dts/exynos4210.dtsi | 25 ++ arch/arm/boot/dts/exynos4x12.dtsi | 76 + arch/arm/boot/dts/exynos5250.dtsi | 291 5 files changed, 617 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase. -- With warm regards, Sachin -- 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 06/12] ARM: dts: Add description of System MMU of Exynos SoCs
-Original Message- From: Sachin Kamat [mailto:sachin.ka...@linaro.org] Sent: Monday, July 29, 2013 3:38 PM Hi KyongHo, On 26 July 2013 16:58, Cho KyongHo pullip@samsung.com wrote: Signed-off-by: Cho KyongHo pullip@samsung.com --- .../bindings/iommu/samsung,exynos4210-sysmmu.txt | 103 +++ arch/arm/boot/dts/exynos4.dtsi | 122 arch/arm/boot/dts/exynos4210.dtsi | 25 ++ arch/arm/boot/dts/exynos4x12.dtsi | 76 + arch/arm/boot/dts/exynos5250.dtsi | 291 5 files changed, 617 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase. OK. I will rebase the next patches on that. Thank you. Cho KyongHo. -- With warm regards, Sachin -- 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 08/12] iommu/exynos: remove prefetch buffer setting when enabling System MMU
-Original Message-
From: grund...@google.com [mailto:grund...@google.com] On Behalf Of Grant
Grundler
Sent: Saturday, July 27, 2013 2:36 AM
On Fri, Jul 26, 2013 at 4:28 AM, Cho KyongHo pullip@samsung.com wrote:
Prefetch buffer must be handled accurately, exact range of a buffer,
frame by frame manually. Otherwise, it may causes page fault or
deadlock in System MMU.
Thus this patch removes prefetch buffer setting when System MMU is
initialized(enabled).
Signed-off-by: Cho KyongHo pullip@samsung.com
Reviewed-by: Grant Grundler grund...@chromium.org
BTW, cscope doesn't find any callers of exynos_sysmmu_enable().
Want to submit another patch to remove it?
(Note I'm talking about exynos_sysmmu_enable() without __ prefix).
Oh, I missed removing that function.
Thank you.
cheers,
grant
---
drivers/iommu/exynos-iommu.c | 32 +++-
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index cfc02ed..87f6bb7 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -80,6 +80,8 @@
#define CTRL_BLOCK 0x7
#define CTRL_DISABLE 0x0
+#define CFG_FLPDCACHE (1 20) /* System MMU 3.2+ only */
+
#define REG_MMU_CTRL 0x000
#define REG_MMU_CFG0x004
#define REG_MMU_STATUS 0x008
@@ -96,6 +98,9 @@
#define REG_MMU_VERSION0x034
+#define MMU_MAJ_VER(reg) (reg 28)
+#define MMU_MIN_VER(reg) ((reg 21) 0x7F)
+
#define REG_PB0_SADDR 0x04C
#define REG_PB0_EADDR 0x050
#define REG_PB1_SADDR 0x054
@@ -200,6 +205,22 @@ static bool is_sysmmu_active(struct sysmmu_drvdata
*data)
return data-activations 0;
}
+static unsigned int __sysmmu_version(struct sysmmu_drvdata *data,
+int idx, unsigned int *minor)
+{
+ unsigned long major;
+
+ major = readl(data-sfrbases[idx] + REG_MMU_VERSION);
+
+ if (minor)
+ *minor = MMU_MIN_VER(major);
+
+ if (MMU_MAJ_VER(major) 3)
+ return 1;
+
+ return MMU_MAJ_VER(major);
+}
+
static void sysmmu_unblock(void __iomem *sfrbase)
{
__raw_writel(CTRL_ENABLE, sfrbase + REG_MMU_CTRL);
@@ -460,14 +481,15 @@ static int __exynos_sysmmu_enable(struct
sysmmu_drvdata *data,
data-pgtable = pgtable;
for (i = 0; i data-nsfrs; i++) {
+ unsigned int min;
+
__sysmmu_set_ptbase(data-sfrbases[i], pgtable);
- if ((readl(data-sfrbases[i] + REG_MMU_VERSION) 28) ==
3) {
- /* System MMU version is 3.x */
- __raw_writel((1 12) | (2 28),
+ if ((__sysmmu_version(data, i, min) == 3) (min 1)) {
+ unsigned long cfg;
+ cfg = __raw_readl(data-sfrbases[i] + REG_MMU_CFG);
+ __raw_writel(cfg | CFG_FLPDCACHE,
data-sfrbases[i] + REG_MMU_CFG);
- __sysmmu_set_prefbuf(data-sfrbases[i], 0, -1, 0);
- __sysmmu_set_prefbuf(data-sfrbases[i], 0, -1, 1);
}
__raw_writel(CTRL_ENABLE, data-sfrbases[i] + REG_MMU_CTRL);
--
1.7.2.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 v8 06/12] ARM: dts: Add description of System MMU of Exynos SoCs
-Original Message- From: Cho KyongHo [mailto:pullip@samsung.com] Sent: Monday, July 29, 2013 4:20 PM -Original Message- From: Sachin Kamat [mailto:sachin.ka...@linaro.org] Sent: Monday, July 29, 2013 3:38 PM Hi KyongHo, On 26 July 2013 16:58, Cho KyongHo pullip@samsung.com wrote: Signed-off-by: Cho KyongHo pullip@samsung.com --- .../bindings/iommu/samsung,exynos4210-sysmmu.txt | 103 +++ arch/arm/boot/dts/exynos4.dtsi | 122 arch/arm/boot/dts/exynos4210.dtsi | 25 ++ arch/arm/boot/dts/exynos4x12.dtsi | 76 + arch/arm/boot/dts/exynos5250.dtsi | 291 5 files changed, 617 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase. OK. I will rebase the next patches on that. I don't get any conflict both on the latest of Linus's tree (3.11-rc3) and for-next branch of Samsung git. Can you show me the diff? Thank you. Cho KyongHo. -- With warm regards, Sachin -- 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 06/12] ARM: dts: Add description of System MMU of Exynos SoCs
On 29 July 2013 13:27, Cho KyongHo pullip@samsung.com wrote: -Original Message- From: Cho KyongHo [mailto:pullip@samsung.com] Sent: Monday, July 29, 2013 4:20 PM -Original Message- From: Sachin Kamat [mailto:sachin.ka...@linaro.org] Sent: Monday, July 29, 2013 3:38 PM Hi KyongHo, On 26 July 2013 16:58, Cho KyongHo pullip@samsung.com wrote: Signed-off-by: Cho KyongHo pullip@samsung.com --- .../bindings/iommu/samsung,exynos4210-sysmmu.txt | 103 +++ arch/arm/boot/dts/exynos4.dtsi | 122 arch/arm/boot/dts/exynos4210.dtsi | 25 ++ arch/arm/boot/dts/exynos4x12.dtsi | 76 + arch/arm/boot/dts/exynos5250.dtsi | 291 5 files changed, 617 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/samsung,exynos4210-sysmmu.txt This patch does not apply on the mainline Linus' tree (3.11-rc2). Please rebase. OK. I will rebase the next patches on that. I don't get any conflict both on the latest of Linus's tree (3.11-rc3) and for-next branch of Samsung git. Can you show me the diff? I get the following error when I do git am on this patch (linus' tree 3.11-rc3). Other patches apply fine. Applying: ARM: dts: Add description of System MMU of Exynos SoCs local_path/linux/.git/rebase-apply/patch:120: new blank line at EOF. + error: patch failed: arch/arm/boot/dts/exynos4.dtsi:161 error: arch/arm/boot/dts/exynos4.dtsi: patch does not apply error: patch failed: arch/arm/boot/dts/exynos4210.dtsi:119 error: arch/arm/boot/dts/exynos4210.dtsi: patch does not apply error: patch failed: arch/arm/boot/dts/exynos4x12.dtsi:79 error: arch/arm/boot/dts/exynos4x12.dtsi: patch does not apply error: patch failed: arch/arm/boot/dts/exynos5250.dtsi:614 error: arch/arm/boot/dts/exynos5250.dtsi: patch does not apply Patch failed at 0001 ARM: dts: Add description of System MMU of Exynos SoCs When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. -- With warm regards, Sachin -- 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: cpuidle: Skip C1 cpuidle state for exynos5440
On Monday 29 of July 2013 10:16:14 amit daniel kachhap wrote: Hi Daniel/Tomasz, From the discussion I can conclude that SOC check is needed in the cpuidle driver for deeper C states. A check is needed for the whole cpuidle driver, so it registers only on Exynos SoCs which support deeper C states. Only the question is where to insert this. Exynos doesn't support multiplatform yet, but we must make sure that any code being added is multiplatform-aware. So initcall is not a good idea. I would put this somewhere on Exynos-specific initialization path, i.e. something that would not called for all platforms compiled in (in case of multiplatform). As I discussed with Daniel, this should be using a traditional platform_driver model, with the difference that it can't be registered from device tree, but rather statically in mach code. For example, you can add an exynos_register_cpuidle() function in arch/arm/mach-exynos/common.c, which registers such platform device and always call it from exynos4_dt_machine_init() in mach-exynos4-dt.c. In mach-exynos5-dt.c you could make this conditional and check if !soc_is_exynos5440(). Best regards, Tomasz Also to perform the SOC there can be 2 ways like 1) each SOC check 4120, 4412, 5250 etc (long list) 2) negate the nonsupporting SOC's like 5440 (small list like current patch) Any opinion? As Bartlomiej suggested that this patch conflicts with Daniel's earlier patch http://marc.info/?l=linux-arm-kernelm=137467935712513w=2 So I can re-base my patch on top of this one if needed. Thanks, Amit Daniel On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 07/28/2013 11:22 AM, Tomasz Figa wrote: On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote: On 07/24/2013 01:47 PM, Kukjin Kim wrote: Amit Daniel Kachhap wrote: This patch skips the deep C1(AFTR -Arm off top running) state for exynos5440 soc as this soc does not support this state. All the cpu's only allows the basic C0 state. Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm/mach-exynos/cpuidle.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach- exynos/cpuidle.c index 17a18ff..9a776a1 100644 --- a/arch/arm/mach-exynos/cpuidle.c +++ b/arch/arm/mach-exynos/cpuidle.c @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void) device-cpu = cpu_id; /* Support IDLE only */ - if (cpu_id != 0) + if (soc_is_exynos5440() || cpu_id != 0) device-state_count = 1; ret = cpuidle_register_device(device); -- 1.7.1 Applied, thanks. You shouldn't have. This patch means exynos5540 has no cpuidle driver at all. It should be fixed in the Kconfig to unselect CONFIG_CPU_IDLE for an exynos5540. To shed more light on this, let me add that you need to register a cpuidle driver only if you have more states than a simple WFI or you need some crazy steps to enter WFI. Default setup falls back to generic ARM WFI. (Daniel, do we get the nice idle stats as provided by cpuidle core then?) Nope, but with one state, idle vs busy stats do the trick. BTW, I am writing a tool to do some stats based on the idle events [1]. It is still at a very early development stage but we can get some interesting informations. Anyway, Exynos cpuidle is using an initcall to initialize and we support multiple Exynos SoCs in single zImage, so deselecting CONFIG_CPU_IDLE is not an option. Good point. Considering multiplatform requirements, the driver has to be modified to initialize only on supported platforms, either by: a) dropping the initcall and calling the init function directly from arch/arm/mach-exynos or b) checking if machine we are running on is supported, which would mean a long list of all Exynos SoCs that needs to be checked. An evolution of option a) is registering a platform device somewhere in arch/arm/mach-exynos and making exynos-cpuidle a platform driver. Yes, I am favorable to this solution [2]. The problem is that you must register a static platform device from arch code, because cpuidle is not a real hardware block that can be put into device tree. Thanks -- Daniel [1] https://git.linaro.org/gitweb?p=people/dlezcano/idlestat.git;a=summar y [2] http://patches.linaro.org/18368/ -- 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
Re: [PATCH] [media] exynos-gsc: Register v4l2 device
Hi Arun,
On 07/26/2013 01:28 PM, Arun Kumar K wrote:
Gscaler video device registration was happening without
reference to a parent v4l2_dev causing probe to fail.
The patch creates a parent v4l2 device and uses it for
gsc m2m video device registration.
I've queued this patch for v3.11-rc as a regression fix, adding
the following to the changelog:
This fixes regression introduced with comit commit 1c1d86a1ea07506
[media] v4l2: always require v4l2_dev, rename parent to dev_parent
But please note that this patch will likely need to be reverted once
capture support is added the GScaler. Then a top level media device
would register struct v4l2_device, instead of the video M2M device
device driver.
Thanks,
Sylwester
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/exynos-gsc/gsc-core.c |9 -
drivers/media/platform/exynos-gsc/gsc-core.h |1 +
drivers/media/platform/exynos-gsc/gsc-m2m.c |1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 559fab2..1ec60264 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -1122,10 +1122,14 @@ static int gsc_probe(struct platform_device *pdev)
goto err_clk;
}
- ret = gsc_register_m2m_device(gsc);
+ ret = v4l2_device_register(dev, gsc-v4l2_dev);
if (ret)
goto err_clk;
+ ret = gsc_register_m2m_device(gsc);
+ if (ret)
+ goto err_v4l2;
+
platform_set_drvdata(pdev, gsc);
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(pdev-dev);
@@ -1147,6 +1151,8 @@ err_pm:
pm_runtime_put(dev);
err_m2m:
gsc_unregister_m2m_device(gsc);
+err_v4l2:
+ v4l2_device_unregister(gsc-v4l2_dev);
err_clk:
gsc_clk_put(gsc);
return ret;
@@ -1157,6 +1163,7 @@ static int gsc_remove(struct platform_device *pdev)
struct gsc_dev *gsc = platform_get_drvdata(pdev);
gsc_unregister_m2m_device(gsc);
+ v4l2_device_unregister(gsc-v4l2_dev);
vb2_dma_contig_cleanup_ctx(gsc-alloc_ctx);
pm_runtime_disable(pdev-dev);
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h
b/drivers/media/platform/exynos-gsc/gsc-core.h
index cc19bba..76435d3 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -343,6 +343,7 @@ struct gsc_dev {
unsigned long state;
struct vb2_alloc_ctx*alloc_ctx;
struct video_device vdev;
+ struct v4l2_device v4l2_dev;
};
/**
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 40a73f7..e576ff2 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -751,6 +751,7 @@ int gsc_register_m2m_device(struct gsc_dev *gsc)
gsc-vdev.release = video_device_release_empty;
gsc-vdev.lock = gsc-lock;
gsc-vdev.vfl_dir = VFL_DIR_M2M;
+ gsc-vdev.v4l2_dev = gsc-v4l2_dev;
snprintf(gsc-vdev.name, sizeof(gsc-vdev.name), %s.%d:m2m,
GSC_MODULE_NAME, gsc-id);
--
Sylwester Nawrocki
Samsung RD Institute Poland
--
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: [REVIEW PATCH 4/6] exynos4-is: Add clock provider for the external clocks
Hi Arun,
On 07/29/2013 07:52 AM, Arun Kumar K wrote:
Hi Sylwester,
On Wed, Jul 24, 2013 at 12:09 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
This patch adds clock provider to expose the sclk_cam0/1 clocks
for image sensor subdevs.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/media/samsung-fimc.txt | 17 +++-
drivers/media/platform/exynos4-is/media-dev.c | 92
drivers/media/platform/exynos4-is/media-dev.h | 19 +++-
3 files changed, 125 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 96312f6..04a2b87 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -91,6 +91,15 @@ Optional properties
- samsung,camclk-out : specifies clock output for remote sensor,
0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+'clock-controller' node (optional)
+--
+
+The purpose of this node is to define a clock provider for external image
+sensors and link any of the CAM_?_CLKOUT clock outputs with related external
+clock consumer device. Properties specific to this node are described in
+../clock/clock-bindings.txt.
+
+
Image sensor nodes
--
@@ -114,7 +123,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
- clocks = ...;
+ clocks = camclk 1;
clock-names = mclk;
port {
@@ -135,7 +144,7 @@ Example:
vddio-supply = ...;
clock-frequency = 2400;
- clocks = ...;
+ clocks = camclk 0;
clock-names = mclk;
port {
@@ -156,6 +165,10 @@ Example:
pinctrl-names = default;
pinctrl-0 = cam_port_a_clk_active;
+ camclk: clock-controller {
+ #clock-cells = 1;
Isn't it
#clock-cells = 1;
?
Yes, indeed. Thanks for spotting this!
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v8 03/12] iommu/exynos: fix page table maintenance
-Original Message-
From: grund...@google.com [mailto:grund...@google.com] On Behalf Of Grant
Grundler
Sent: Saturday, July 27, 2013 1:17 AM
To: Cho KyongHo
On Fri, Jul 26, 2013 at 4:27 AM, Cho KyongHo pullip@samsung.com wrote:
This prevents allocating lv2 page table for the lv1 page table entry
that already has 1MB page mapping. In addition some BUG_ON() is
changed to WARN_ON().
Signed-off-by: Cho KyongHo pullip@samsung.com
Reviewed-by: Grant Grundler grund...@chromium.org
In reviewing this, I noticed another issue that is related, but not
caused by this patch. See below.
---
drivers/iommu/exynos-iommu.c | 52
+
1 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index e3be3e5..6c4ecce 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -52,11 +52,11 @@
#define lv2ent_large(pent) ((*(pent) 3) == 1)
#define section_phys(sent) (*(sent) SECT_MASK)
-#define section_offs(iova) ((iova) 0xF)
+#define section_offs(iova) ((iova) ~SECT_MASK)
#define lpage_phys(pent) (*(pent) LPAGE_MASK)
-#define lpage_offs(iova) ((iova) 0x)
+#define lpage_offs(iova) ((iova) ~LPAGE_MASK)
#define spage_phys(pent) (*(pent) SPAGE_MASK)
-#define spage_offs(iova) ((iova) 0xFFF)
+#define spage_offs(iova) ((iova) ~SPAGE_MASK)
#define lv1ent_offset(iova) ((iova) SECT_ORDER)
#define lv2ent_offset(iova) (((iova) 0xFF000) SPAGE_ORDER)
@@ -862,12 +862,14 @@ static unsigned long *alloc_lv2entry(unsigned long
*sent, unsigned long iova,
pent = kzalloc(LV2TABLE_SIZE, GFP_ATOMIC);
BUG_ON((unsigned long)pent (LV2TABLE_SIZE - 1));
if (!pent)
- return NULL;
+ return ERR_PTR(-ENOMEM);
*sent = mk_lv1ent_page(__pa(pent));
*pgcounter = NUM_LV2ENTRIES;
pgtable_flush(pent, pent + NUM_LV2ENTRIES);
pgtable_flush(sent, sent + 1);
+ } else if (lv1ent_section(sent)) {
+ return ERR_PTR(-EADDRINUSE);
}
return page_entry(sent, iova);
@@ -894,6 +896,12 @@ static int lv1set_section(unsigned long *sent,
phys_addr_t paddr, short *pgcnt)
return 0;
}
+static void clear_page_table(unsigned long *ent, int n)
+{
+ if (n 0)
+ memset(ent, 0, sizeof(*ent) * n);
+}
+
static int lv2set_page(unsigned long *pent, phys_addr_t paddr, size_t size,
short
*pgcnt)
{
@@ -908,7 +916,7 @@ static int lv2set_page(unsigned long *pent, phys_addr_t
paddr, size_t size,
int i;
for (i = 0; i SPAGES_PER_LPAGE; i++, pent++) {
if (!lv2ent_fault(pent)) {
- memset(pent, 0, sizeof(*pent) * i);
+ clear_page_table(pent - i, i);
return -EADDRINUSE;
I am wondering about two issues with this error handling:
1) we don't call pgtable_flush() in this case - I think just for
consistency we should - don't rush to add since my next comment is to
change this error handling completely.
clear_page_table() is called for the page table entries that are already
fault pages. That is why it does not contain cache flush.
2) If -EADDRINUSE is correct, why does the code clear the IO Page
table entries?
I think this error path should either
(a) BUG_ON (ie panic) since this is an inconsistency between
generic IOMMU page allocation and chip specific IOMMU mapping code OR
(b) WARN_ON, not clear the entries, and hope whoever was using it
can finish using the system before crashing or gracefully shutting
down.
In any case, I'm pretty sure this code needs to change and it should
be in a follow up to this series.
Yes, you're right. But I worried the case that a kernel module calls IOMMU API
functions directly and does not want to make kernel panic when it tries to map
a region that is already in use.
I also wonder if the such kernel module exists.
WARN_ON is also a good idea.
Thank you.
thanks,
grant
}
@@ -944,17 +952,16 @@ static int exynos_iommu_map(struct iommu_domain
*domain, unsigned long iova,
pent = alloc_lv2entry(entry, iova,
priv-lv2entcnt[lv1ent_offset(iova)]);
- if (!pent)
- ret = -ENOMEM;
+ if (IS_ERR(pent))
+ ret = PTR_ERR(pent);
else
ret = lv2set_page(pent, paddr, size,
priv-lv2entcnt[lv1ent_offset(iova)]);
}
- if (ret) {
-
Re: [PATCH] of: provide of_platform_unpopulate()
On Fri, 2013-07-19 at 20:14 +0200, Sebastian Andrzej Siewior wrote: The problem is that platform_device_del() releases each ressource in its tree. This does not work on platform_devices created by OF becuase they were never added via insert_resource(). As a consequence old-parent in __release_resource() is NULL and we explode while accessing -child. So I either I do something completly wrong _or_ nobody here tested the rmmod path of their driver. But that's wrong. I am not familar with all that new code, but from step up, not having the resources in the resource tree is a bad idea to begin with This patch provides a common function to unregister / remove devices which added to the system via of_platform_populate(). While this works now on my test case I have not tested any of the driver I modify here so feedback is greatly appreciated. Ben. -- 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: cpuidle: Skip C1 cpuidle state for exynos5440
Hi Tomasz, On Mon, Jul 29, 2013 at 2:03 PM, Tomasz Figa tomasz.f...@gmail.com wrote: On Monday 29 of July 2013 10:16:14 amit daniel kachhap wrote: Hi Daniel/Tomasz, From the discussion I can conclude that SOC check is needed in the cpuidle driver for deeper C states. A check is needed for the whole cpuidle driver, so it registers only on Exynos SoCs which support deeper C states. Only the question is where to insert this. Exynos doesn't support multiplatform yet, but we must make sure that any code being added is multiplatform-aware. So initcall is not a good idea. I would put this somewhere on Exynos-specific initialization path, i.e. something that would not called for all platforms compiled in (in case of multiplatform). As I discussed with Daniel, this should be using a traditional platform_driver model, with the difference that it can't be registered from device tree, but rather statically in mach code. For example, you can add an exynos_register_cpuidle() function in arch/arm/mach-exynos/common.c, which registers such platform device and always call it from exynos4_dt_machine_init() in mach-exynos4-dt.c. In mach-exynos5-dt.c you could make this conditional and check if !soc_is_exynos5440(). thanks for the detailed explanation. Certainly initcall is not good for multikernel. Still I have few concerns. 1) Each C state might be SOC specific. Say there are 3 C states C0(basic wfi), c1(single CPU power down) and C2 (System wide power down like AFTR). In this case some exynos soc may support few of these states and cpuidle driver should bind C-state to correct SOC. 2) Even for default C0 ( simple wfi) currently there is no sysfs information if the cpuidle driver is not registered(Not quite sure). I will try to post the new driver by dynamically creating the cpuidle_state table based on SOC capability and removing the initcall. Regards, Amit D Best regards, Tomasz Also to perform the SOC there can be 2 ways like 1) each SOC check 4120, 4412, 5250 etc (long list) 2) negate the nonsupporting SOC's like 5440 (small list like current patch) Any opinion? As Bartlomiej suggested that this patch conflicts with Daniel's earlier patch http://marc.info/?l=linux-arm-kernelm=137467935712513w=2 So I can re-base my patch on top of this one if needed. Thanks, Amit Daniel On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 07/28/2013 11:22 AM, Tomasz Figa wrote: On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote: On 07/24/2013 01:47 PM, Kukjin Kim wrote: Amit Daniel Kachhap wrote: This patch skips the deep C1(AFTR -Arm off top running) state for exynos5440 soc as this soc does not support this state. All the cpu's only allows the basic C0 state. Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm/mach-exynos/cpuidle.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach- exynos/cpuidle.c index 17a18ff..9a776a1 100644 --- a/arch/arm/mach-exynos/cpuidle.c +++ b/arch/arm/mach-exynos/cpuidle.c @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void) device-cpu = cpu_id; /* Support IDLE only */ - if (cpu_id != 0) + if (soc_is_exynos5440() || cpu_id != 0) device-state_count = 1; ret = cpuidle_register_device(device); -- 1.7.1 Applied, thanks. You shouldn't have. This patch means exynos5540 has no cpuidle driver at all. It should be fixed in the Kconfig to unselect CONFIG_CPU_IDLE for an exynos5540. To shed more light on this, let me add that you need to register a cpuidle driver only if you have more states than a simple WFI or you need some crazy steps to enter WFI. Default setup falls back to generic ARM WFI. (Daniel, do we get the nice idle stats as provided by cpuidle core then?) Nope, but with one state, idle vs busy stats do the trick. BTW, I am writing a tool to do some stats based on the idle events [1]. It is still at a very early development stage but we can get some interesting informations. Anyway, Exynos cpuidle is using an initcall to initialize and we support multiple Exynos SoCs in single zImage, so deselecting CONFIG_CPU_IDLE is not an option. Good point. Considering multiplatform requirements, the driver has to be modified to initialize only on supported platforms, either by: a) dropping the initcall and calling the init function directly from arch/arm/mach-exynos or b) checking if machine we are running on is supported, which would mean a long list of all Exynos SoCs that needs to be checked. An evolution of option a) is registering a platform device somewhere in arch/arm/mach-exynos and making exynos-cpuidle a platform driver. Yes, I am favorable to this solution [2]. The problem is that you must
Re: [PATCH] of: provide of_platform_unpopulate()
On Mon, 2013-07-22 at 00:44 +0100, Grant Likely wrote: BTW, it looks like Grant has attempted this already: Yup, things broke badly. Unfortunately the of_platform_device and platform_device history doesn't treat resources in the same way. I would like to merge the code, but I haven't been able to figure out a clean way to do it. Looks like we do need the unpopulate function. What is the exact problem Grant ? Care to give me an example ? Cheers, Ben. -- 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: cpuidle: Skip C1 cpuidle state for exynos5440
On 07/29/2013 11:33 AM, amit daniel kachhap wrote: Hi Tomasz, On Mon, Jul 29, 2013 at 2:03 PM, Tomasz Figa tomasz.f...@gmail.com wrote: On Monday 29 of July 2013 10:16:14 amit daniel kachhap wrote: Hi Daniel/Tomasz, From the discussion I can conclude that SOC check is needed in the cpuidle driver for deeper C states. A check is needed for the whole cpuidle driver, so it registers only on Exynos SoCs which support deeper C states. Only the question is where to insert this. Exynos doesn't support multiplatform yet, but we must make sure that any code being added is multiplatform-aware. So initcall is not a good idea. I would put this somewhere on Exynos-specific initialization path, i.e. something that would not called for all platforms compiled in (in case of multiplatform). As I discussed with Daniel, this should be using a traditional platform_driver model, with the difference that it can't be registered from device tree, but rather statically in mach code. For example, you can add an exynos_register_cpuidle() function in arch/arm/mach-exynos/common.c, which registers such platform device and always call it from exynos4_dt_machine_init() in mach-exynos4-dt.c. In mach-exynos5-dt.c you could make this conditional and check if !soc_is_exynos5440(). thanks for the detailed explanation. Certainly initcall is not good for multikernel. Still I have few concerns. 1) Each C state might be SOC specific. Say there are 3 C states C0(basic wfi), c1(single CPU power down) and C2 (System wide power down like AFTR). In this case some exynos soc may support few of these states and cpuidle driver should bind C-state to correct SOC. 2) Even for default C0 ( simple wfi) currently there is no sysfs information if the cpuidle driver is not registered(Not quite sure). I will try to post the new driver by dynamically creating the cpuidle_state table based on SOC capability and removing the initcall. Why don't you create a cpuidle driver for each SoC family ? I am cleaning up all the drivers to unify the code, hoping we can factor all the drivers through a single ARM driver and assign the ops for the different states. As Thomasz said, the platform driver model should be used, no need of initcall, the code path will initialize the driver or not depending of the SoC. You should not have any soc_is_* checks. This is the direction all the ARM drivers are going to. Look at the example I sent with the ux500, it illustrates the idea. There are other examples also: cpuidle-kirkwood.c, cpuidle for davinci. Concerning the single cpu power down state, is the exynos able to handle that ? I mean, is it possible to power down a core and have it woken up by an interrupt ? Concerning the AFTR state : Is there a way to use this state with *all* cpus online ? If not, shall we use the same approach than omap4, that is CPU0 power down CPU1 and goes to AFTR (all interrupts migrated to CPU0) and then wake up CPU1 when CPU0 is woken up ? Concerning WFI and sysfs, if there are no cpuidle driver registered, no sysfs. I would not focus on and spent too much effort for the statistics because a lot of changes will certainly happen with the power aware scheduler and the statistics will likely appear at this level. Regards -- Daniel Best regards, Tomasz Also to perform the SOC there can be 2 ways like 1) each SOC check 4120, 4412, 5250 etc (long list) 2) negate the nonsupporting SOC's like 5440 (small list like current patch) Any opinion? As Bartlomiej suggested that this patch conflicts with Daniel's earlier patch http://marc.info/?l=linux-arm-kernelm=137467935712513w=2 So I can re-base my patch on top of this one if needed. Thanks, Amit Daniel On Sun, Jul 28, 2013 at 4:01 PM, Daniel Lezcano daniel.lezc...@linaro.org wrote: On 07/28/2013 11:22 AM, Tomasz Figa wrote: On Sunday 28 of July 2013 09:10:09 Daniel Lezcano wrote: On 07/24/2013 01:47 PM, Kukjin Kim wrote: Amit Daniel Kachhap wrote: This patch skips the deep C1(AFTR -Arm off top running) state for exynos5440 soc as this soc does not support this state. All the cpu's only allows the basic C0 state. Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- arch/arm/mach-exynos/cpuidle.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach- exynos/cpuidle.c index 17a18ff..9a776a1 100644 --- a/arch/arm/mach-exynos/cpuidle.c +++ b/arch/arm/mach-exynos/cpuidle.c @@ -210,7 +210,7 @@ static int __init exynos4_init_cpuidle(void) device-cpu = cpu_id; /* Support IDLE only */ - if (cpu_id != 0) + if (soc_is_exynos5440() || cpu_id != 0) device-state_count = 1; ret = cpuidle_register_device(device); -- 1.7.1 Applied, thanks. You shouldn't have. This patch means exynos5540 has no cpuidle driver at all. It should be fixed in the Kconfig to unselect
Re: [PATCH v4 12/20] pwm: samsung: Rename to pwm-samsung-legacy
On Sat, Jul 20, 2013 at 02:04:25AM +0200, Tomasz Figa wrote:
This patch renames the old pwm-samsung driver to pwm-samsung-legacy to
create place for the new, rewritten, DT-aware pwm-samsung driver using
Samsung PWM/timer master driver.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
drivers/pwm/Makefile| 2 +-
drivers/pwm/{pwm-samsung.c = pwm-samsung-legacy.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/pwm/{pwm-samsung.c = pwm-samsung-legacy.c} (100%)
Acked-by: Thierry Reding thierry.red...@gmail.com
pgpPDuGWhN6hR.pgp
Description: PGP signature
Re: [PATCH v4 16/20] pwm: Remove superseded pwm-samsung-legacy driver
On Sat, Jul 20, 2013 at 02:04:29AM +0200, Tomasz Figa wrote: This patch removes the now unused pwm-samsung-legacy driver, which was replaced by new pwm-samsung driver. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- drivers/pwm/Makefile | 1 - drivers/pwm/pwm-samsung-legacy.c | 353 --- 2 files changed, 354 deletions(-) delete mode 100644 drivers/pwm/pwm-samsung-legacy.c Acked-by: Thierry Reding thierry.red...@gmail.com pgp6FT6Zccrhq.pgp Description: PGP signature
Re: [PATCH v4 13/20] pwm: Add new pwm-samsung driver
On Sat, Jul 20, 2013 at 02:04:26AM +0200, Tomasz Figa wrote: This patch introduces new Samsung PWM driver, which uses Samsung PWM/timer master driver to control shared parts of the hardware. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- drivers/pwm/Makefile | 1 + drivers/pwm/pwm-samsung.c | 606 ++ 2 files changed, 607 insertions(+) create mode 100644 drivers/pwm/pwm-samsung.c Acked-by: Thierry Reding thierry.red...@gmail.com pgpRYIndDEJ7x.pgp Description: PGP signature
Re: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
Hi Mark,
On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat padma@gmail.com wrote:
Hi Mark,
On Fri, Jul 26, 2013 at 8:49 PM, Mark Brown broo...@kernel.org wrote:
On Fri, Jul 26, 2013 at 07:06:51PM +0530, Padmavathi Venna wrote:
This patch adds wm8994 codec node on i2c bus1 and the required
regulator supplies and properties on smdk5420 board.
This isn't a device tree patch for WM8994, it's a patch for the
SMDK5420.
Yes. I will correct the subject.
+ vdd: fixed-regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vdd-supply;
These names look wrong - they should reflect the names in the schematic
as they're for human comprehensibility. This may just be a case of
dropping the -supply.
When I posted the same patch for smdk5250, you asked me to club all
the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
better name for representing both supplies?
OK.
+ wm8994: wm8994@1a {
+ compatible = wlf,wm8994;
+ reg = 0x1a;
+
+ gpio-controller;
+ #gpio-cells = 2;
+
+ AVDD2-supply = vdd;
+ CPVDD-supply = vdd;
+ DBVDD-supply = dbvdd;
+ SPKVDD1-supply = spkvdd;
+ SPKVDD2-supply = spkvdd;
+ };
It would be helpful to also add a clock binding (I posted a binding
documentation update the other day, it's in my tree now) but it's not
essential and I suspect it needs some work on the clock driver side
still.
OK. I will check this.
As per schemata, input clock to MCLK1 is an oscillator clock with
16.9MHz and MCLK2 not showing any input clock. So here I need to add a
fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.
Is it correct?
Thanks
Padma
--
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 v6 02/20] clocksource: samsung_pwm_timer: Correct definition of AUTORELOAD bit
On 07/24/2013 01:32 AM, Tomasz Figa wrote: PWM channel 4 has its autoreload bit located at different position. This patch fixes the driver to account for that. This fixes a problem with the clocksource hanging after it overflows because it is not reloaded any more. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- Acked-by: Daniel Lezcano daniel.lezc...@linaro.org drivers/clocksource/samsung_pwm_timer.c | 13 - 1 file changed, 12 insertions(+), 1 deletion(-) Changes since v5: - Added more detailed comment about bit layout in TCON register. diff --git a/drivers/clocksource/samsung_pwm_timer.c b/drivers/clocksource/samsung_pwm_timer.c index 3fa5b07..5d0049f 100644 --- a/drivers/clocksource/samsung_pwm_timer.c +++ b/drivers/clocksource/samsung_pwm_timer.c @@ -44,10 +44,21 @@ #define TCFG1_SHIFT(x) ((x) * 4) #define TCFG1_MUX_MASK 0xf +/* + * Each channel occupies 4 bits in TCON register, but there is a gap of 4 + * bits (one channel) after channel 0, so channels have different numbering + * when accessing TCON register. + * + * In addition, the location of autoreload bit for channel 4 (TCON channel 5) + * in its set of bits is 2 as opposed to 3 for other channels. + */ #define TCON_START(chan) (1 (4 * (chan) + 0)) #define TCON_MANUALUPDATE(chan) (1 (4 * (chan) + 1)) #define TCON_INVERT(chan)(1 (4 * (chan) + 2)) -#define TCON_AUTORELOAD(chan)(1 (4 * (chan) + 3)) +#define _TCON_AUTORELOAD(chan) (1 (4 * (chan) + 3)) +#define _TCON_AUTORELOAD4(chan) (1 (4 * (chan) + 2)) +#define TCON_AUTORELOAD(chan)\ + ((chan 5) ? _TCON_AUTORELOAD(chan) : _TCON_AUTORELOAD4(chan)) DEFINE_SPINLOCK(samsung_pwm_lock); EXPORT_SYMBOL(samsung_pwm_lock); -- 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
Re: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
On Mon, Jul 29, 2013 at 05:31:16PM +0530, Padma Venkat wrote:
On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat padma@gmail.com wrote:
+ vdd: fixed-regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vdd-supply;
These names look wrong - they should reflect the names in the schematic
as they're for human comprehensibility. This may just be a case of
dropping the -supply.
When I posted the same patch for smdk5250, you asked me to club all
the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
better name for representing both supplies?
No, I'd have told you to combine things taht come from the same supply
on the board - things like the speaker supplies for example aren't going
to be coming from separate places. The names should reflect whatever
the names on the schemaric are, like I say that's probably just removing
the -supply.
documentation update the other day, it's in my tree now) but it's not
essential and I suspect it needs some work on the clock driver side
still.
OK. I will check this.
As per schemata, input clock to MCLK1 is an oscillator clock with
16.9MHz and MCLK2 not showing any input clock. So here I need to add a
fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.
Is it correct?
Yes, in the DTS (or to XCLKOUT on the AP?).
signature.asc
Description: Digital signature
[PATCH 0/7] Add DT nodes for FIMD and DP controller for Exynos5420 SoC
This patchset adds DT nodes for FIMD and DP controller for Exynos5420 based SMDK. It moves all common properties of FIMD and DP controller DT node specific to Exynos5 Socs like 5250 and 5420 to exynos5.dtsi file. It also adds required PM domain DT nodes for exynos5420. Is rebased on branch kgene's for-next https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next The DP PHY DT Node is based on Jingoo Han's inflight patchset at http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/66435 Vikas Sajjan (6): ARM: dts: move display-timimg information inside FIMD DT node for exynos5250 ARM: dts: Update FIMD DT node for Exynos5 SoCs ARM: dts: Add FIMD DT node to exynos5420 DTS files ARM: dts: Update DP controller DT Node for Exynos5 based SoCs ARM: dts: Add DP controller DT node to exynos5420 SoC ARM: dts: add pin state information for DP HPD support to Exynos5420 Yadwinder Singh Brar (1): ARM: dts: Add basic PM domains for EXYNOS5420 arch/arm/boot/dts/exynos5.dtsi| 39 +++ arch/arm/boot/dts/exynos5250-arndale.dts |9 -- arch/arm/boot/dts/exynos5250-smdk5250.dts | 35 + arch/arm/boot/dts/exynos5250.dtsi | 18 ++- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos5420-smdk5420.dts | 23 ++ arch/arm/boot/dts/exynos5420.dtsi | 49 + 7 files changed, 135 insertions(+), 45 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
[PATCH 3/7] ARM: dts: Add basic PM domains for EXYNOS5420
From: Yadwinder Singh Brar yadi.b...@samsung.com
Add DT nodes for gsc, isp, mfc, disp, mau, g2d and msc PM domains.
Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..bd6b310 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -90,6 +90,41 @@
};
};
+ gsc_pd: pd@10044000 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044000 0x20;
+ };
+
+ isp_pd: pd@10044020 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044020 0x20;
+ };
+
+ mfc_pd: pd@10044060 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044060 0x20;
+ };
+
+ disp_pd: pd@100440C0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440C0 0x20;
+ };
+
+ mau_pd: pd@100440E0 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x100440E0 0x20;
+ };
+
+ g2d_pd: pd@10044100 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044100 0x20;
+ };
+
+ msc_pd: pd@10044120 {
+ compatible = samsung,exynos4210-pd;
+ reg = 0x10044120 0x20;
+ };
+
pinctrl_0: pinctrl@1340 {
compatible = samsung,exynos5420-pinctrl;
reg = 0x1340 0x1000;
--
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/7] ARM: dts: Update FIMD DT node for Exynos5 SoCs
Moves the properties of FIMD DT node which are common across Exynos5 based
SoCs like Exynos5250 and Exxynos5420 to exynos5.dtsi
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos5.dtsi| 10 ++
arch/arm/boot/dts/exynos5250.dtsi |6 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..80a4630 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -108,4 +108,14 @@
interrupts = 0 42 0;
status = disabled;
};
+
+ fimd {
+ compatible = samsung,exynos5250-fimd;
+ interrupt-parent = combiner;
+ reg = 0x1440 0x4;
+ interrupt-names = fifo, vsync, lcd_sys;
+ interrupts = 18 4, 18 5, 18 6;
+ status = disabled;
+ };
+
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..20c32fc 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -631,12 +631,8 @@
};
fimd {
- compatible = samsung,exynos5250-fimd;
- interrupt-parent = combiner;
- reg = 0x1440 0x4;
- interrupt-names = fifo, vsync, lcd_sys;
- interrupts = 18 4, 18 5, 18 6;
clocks = clock 133, clock 339;
clock-names = sclk_fimd, fimd;
+ 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 1/7] ARM: dts: Move display-timimg information inside FIMD DT node for exynos5250
As the display-timing information is parsed by FIMD driver, it makes
sense to move the display-timimg DT node inside FIMD DT node for exynos5250
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 49f18c2..3b32c26 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -262,19 +262,21 @@
pinctrl-0 = dp_hpd;
};
- display-timings {
- native-mode = timing0;
- timing0: timing@0 {
- /* 1280x800 */
- clock-frequency = 5;
- hactive = 1280;
- vactive = 800;
- hfront-porch = 4;
- hback-porch = 4;
- hsync-len = 4;
- vback-porch = 4;
- vfront-porch = 4;
- vsync-len = 4;
+ fimd {
+ display-timings {
+ native-mode = timing0;
+ timing0: timing@0 {
+ /* 1280x800 */
+ clock-frequency = 5;
+ hactive = 1280;
+ vactive = 800;
+ hfront-porch = 4;
+ hback-porch = 4;
+ hsync-len = 4;
+ vback-porch = 4;
+ vfront-porch = 4;
+ vsync-len = 4;
+ };
};
};
--
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/7] ARM: dts: Update DP controller DT Node for Exynos5 based SoCs
Moves the properties of DP controller to exynos5.dtsi which are common
across exynos5 SoCs like Exynos5250 and Exynos5420.
The PHY DP Node is based on Jingoo Han's jg1@samsung.com patch at
https://patchwork.linuxtv.org/patch/19189/
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos5.dtsi| 29 +
arch/arm/boot/dts/exynos5250-arndale.dts |9 -
arch/arm/boot/dts/exynos5250-smdk5250.dts |7 ---
arch/arm/boot/dts/exynos5250.dtsi | 12 +---
4 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index 80a4630..682ecf9 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -118,4 +118,33 @@
status = disabled;
};
+ dp_phy: video-phy@10040720 {
+ compatible = samsung,exynos5250-dp-video-phy;
+ reg = 0x10040720 4;
+ #phy-cells = 0;
+ };
+
+ dp-controller {
+ compatible = samsung,exynos5-dp;
+ reg = 0x145b 0x1000;
+ interrupts = 10 3;
+ interrupt-parent = combiner;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ samsung,color-space = 0;
+ samsung,dynamic-range = 0;
+ samsung,ycbcr-coeff = 0;
+ samsung,color-depth = 1;
+ samsung,link-rate = 0x0a;
+ samsung,lane-count = 4;
+
+ phys = dp_phy;
+ phy-names = dp;
+
+ status = disabled;
+
+ };
+
+
};
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 96d528d..01eef7d 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -509,15 +509,6 @@
};
};
- dp-controller {
- samsung,color-space = 0;
- samsung,dynamic-range = 0;
- samsung,ycbcr-coeff = 0;
- samsung,color-depth = 1;
- samsung,link-rate = 0x0a;
- samsung,lane-count = 4;
- };
-
fimd: fimd@1440 {
display-timings {
native-mode = timing0;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3b32c26..109f9f7 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -251,13 +251,6 @@
};
dp-controller {
- samsung,color-space = 0;
- samsung,dynamic-range = 0;
- samsung,ycbcr-coeff = 0;
- samsung,color-depth = 1;
- samsung,link-rate = 0x0a;
- samsung,lane-count = 4;
-
pinctrl-names = default;
pinctrl-0 = dp_hpd;
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 20c32fc..3b5bf13 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -615,19 +615,9 @@
};
dp-controller {
- compatible = samsung,exynos5-dp;
- reg = 0x145b 0x1000;
- interrupts = 10 3;
- interrupt-parent = combiner;
clocks = clock 342;
clock-names = dp;
- #address-cells = 1;
- #size-cells = 0;
-
- dptx-phy {
- reg = 0x10040720;
- samsung,enable-mask = 1;
- };
+ status = okay;
};
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 7/7] ARM: dts: Add pin state information for DP HPD support to Exynos5420
Add pin state information for DP HPD support that requires pin configuration
support using pinctrl interface.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 +++
arch/arm/boot/dts/exynos5420-smdk5420.dts |5 +
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index 5848c42..e695aba 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -59,6 +59,13 @@
interrupt-controller;
#interrupt-cells = 2;
};
+
+ dp_hpd: dp_hpd {
+ samsung,pins = gpx0-7;
+ samsung,pin-function = 3;
+ samsung,pin-pud = 0;
+ samaung,pin-drv = 0;
+ };
};
pinctrl@1341 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 7c2f477..1237ad2 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -31,6 +31,11 @@
};
};
+ dp-controller {
+ pinctrl-names = default;
+ pinctrl-0 = dp_hpd;
+ };
+
fimd {
display-timings {
native-mode = timing0;
--
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 6/7] ARM: dts: Add DP controller DT node to exynos5420 SoC
Adds DP controller DT node to exynos5420 SoC
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos5420.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 1f659f4..948307c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -181,6 +181,12 @@
clock-names = uart, clk_uart_baud0;
};
+ dp-controller {
+ clocks = clock 412;
+ clock-names = dp;
+ status = okay;
+ };
+
fimd {
samsung,power-domain = disp_pd;
clocks = clock 147, clock 421;
--
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: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
On Monday 29 July 2013 08:58 PM, Kamil Debski wrote:
Hi Kishon,
A small fix follows inline.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Kishon Vijay Abraham I
Sent: Friday, July 26, 2013 2:49 PM
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference
to the PHY with or without using phandle. For dt-boot, the PHY drivers
should also register *PHY provider* with the framework.
PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found
at Documentation/devicetree/bindings/phy/phy-bindings.txt
Cc: Tomasz Figa t.f...@samsung.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../devicetree/bindings/phy/phy-bindings.txt | 66 ++
Documentation/phy.txt | 166 +
MAINTAINERS|8 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 18 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 714
include/linux/phy/phy.h| 270
9 files changed, 1251 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-
bindings.txt
create mode 100644 Documentation/phy.txt create mode 100644
drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create
mode 100644 drivers/phy/phy-core.c create mode 100644
include/linux/phy/phy.h
[snip]
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h new file
mode 100644 index 000..e444b23
--- /dev/null
+++ b/include/linux/phy/phy.h
@@ -0,0 +1,270 @@
[snip]
+struct phy_init_data {
+unsigned int num_consumers;
+struct phy_consumer *consumers;
+};
+
+#define PHY_CONSUMER(_dev_name, _port) \
+{ \
+.dev_name = _dev_name,\
+.port = _port,\
+}
+
+#define to_phy(dev) (container_of((dev), struct phy, dev))
+
+#define of_phy_provider_register(dev, xlate)\
+__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define devm_of_phy_provider_register(dev, xlate) \
+__of_phy_provider_register((dev), THIS_MODULE, (xlate))
I think this should be:
+ __devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))
Right?
right.. thanks for spotting this.
Regards
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: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
On 07/26/2013 02:49 PM, Kishon Vijay Abraham I wrote:
The PHY framework provides a set of APIs for the PHY drivers to
create/destroy a PHY and APIs for the PHY users to obtain a reference to the
PHY with or without using phandle. For dt-boot, the PHY drivers should
also register *PHY provider* with the framework.
PHY drivers should create the PHY by passing id and ops like init, exit,
power_on and power_off. This framework is also pm runtime enabled.
The documentation for the generic PHY framework is added in
Documentation/phy.txt and the documentation for dt binding can be found at
Documentation/devicetree/bindings/phy/phy-bindings.txt
Cc: Tomasz Figa t.f...@samsung.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Sylwester Nawrocki s.nawro...@samsung.com
---
.../devicetree/bindings/phy/phy-bindings.txt | 66 ++
Documentation/phy.txt | 166 +
MAINTAINERS|8 +
drivers/Kconfig|2 +
drivers/Makefile |2 +
drivers/phy/Kconfig| 18 +
drivers/phy/Makefile |5 +
drivers/phy/phy-core.c | 714
include/linux/phy/phy.h| 270
9 files changed, 1251 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt
create mode 100644 Documentation/phy.txt
create mode 100644 drivers/phy/Kconfig
create mode 100644 drivers/phy/Makefile
create mode 100644 drivers/phy/phy-core.c
create mode 100644 include/linux/phy/phy.h
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt
b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000..8ae844f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
[...]
@@ -0,0 +1,166 @@
+ PHY SUBSYSTEM
+ Kishon Vijay Abraham I kis...@ti.com
+
+This document explains the Generic PHY Framework along with the APIs
provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide
functions
+such as serialization, de-serialization, encoding, decoding and is
responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an
external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance
of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+#define of_phy_provider_register(dev, xlate)\
+__of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define devm_of_phy_provider_register(dev, xlate) \
+__of_phy_provider_register((dev), THIS_MODULE, (xlate))
This needs to be:
__devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))
as Kamil pointed out. We've tested it here with v9 and it makes
Bad Things happen. ;)
+of_phy_provider_register and devm_of_phy_provider_register macros can be
used to
+register the phy_provider and it takes device and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the
above
+2 macros to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+ struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
[...]
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
new file mode 100644
index 000..f1d15e5
--- /dev/null
+++ b/drivers/phy/phy-core.c
@@ -0,0 +1,714 @@
[...]
+static struct phy *phy_lookup(struct device *device, const char *port)
+{
+ unsigned int
Re: [PATCH v8 03/12] iommu/exynos: fix page table maintenance
On Mon, Jul 29, 2013 at 2:18 AM, Cho KyongHo pullip@samsung.com wrote:
...
@@ -908,7 +916,7 @@ static int lv2set_page(unsigned long *pent,
phys_addr_t paddr, size_t size,
int i;
for (i = 0; i SPAGES_PER_LPAGE; i++, pent++) {
if (!lv2ent_fault(pent)) {
- memset(pent, 0, sizeof(*pent) * i);
+ clear_page_table(pent - i, i);
return -EADDRINUSE;
I am wondering about two issues with this error handling:
1) we don't call pgtable_flush() in this case - I think just for
consistency we should - don't rush to add since my next comment is to
change this error handling completely.
clear_page_table() is called for the page table entries that are already
fault pages. That is why it does not contain cache flush.
2) If -EADDRINUSE is correct, why does the code clear the IO Page
table entries?
I think this error path should either
(a) BUG_ON (ie panic) since this is an inconsistency between
generic IOMMU page allocation and chip specific IOMMU mapping code OR
(b) WARN_ON, not clear the entries, and hope whoever was using it
can finish using the system before crashing or gracefully shutting
down.
In any case, I'm pretty sure this code needs to change and it should
be in a follow up to this series.
Yes, you're right. But I worried the case that a kernel module calls IOMMU API
functions directly and does not want to make kernel panic when it tries to map
a region that is already in use.
Using a DMA address for a different physical page while the current
mapping is still active can only be a bug. I can confidently say there
is no way to map the same DMA address twice (at least not for a single
page table.) We can try to fail the mapping somehow and WARN_ON to
indicate we had a Re-Use before free type bug.
I also wonder if the such kernel module exists.
I believe the kernel will never do this.
WARN_ON is also a good idea.
After this series goes in, post another patch and I'd be happy to
review that as well.
After thinking about it more, I'm also ok with removing this code.
It's a very defensive code to catch errors in the generic IOMMU code
that probably no longer exist. Or maybe just make it
CONFIG_DEBUG_IOMMU_ALLOC or something like that.
cheers,
grant
--
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/11] spi: Provide core support for runtime PM during transfers
On 07/28/2013 08:43 AM, Mark Brown wrote: From: Mark Brown broo...@linaro.org Most SPI drivers that implement runtime PM support use identical code to do so: they acquire a runtime PM lock in prepare_transfer_hardware() and then they release it in unprepare_transfer_hardware(). The variations in this are mostly missing error checking and the choice to use autosuspend. Since these runtime PM calls are normally the only thing in the prepare and unprepare callbacks and the autosuspend API transparently does the right thing on devices with autosuspend disabled factor all of this out into the core with a flag to enable the behaviour. Patch 1, 9, 10, 11, Reviewed-by: Stephen Warren swar...@nvidia.com -- 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] usb: phy-samsung-usb: Simplify PMU register handling
- if (sphy-phy_type == USB_PHY_TYPE_DEVICE) {
- reg = sphy-pmuregs + sphy-drv_data-devphy_reg_offset;
- en_mask = sphy-drv_data-devphy_en_mask;
- } else if (sphy-phy_type == USB_PHY_TYPE_HOST) {
- reg = sphy-pmuregs + sphy-drv_data-hostphy_reg_offset;
- en_mask = sphy-drv_data-hostphy_en_mask;
- }
How is en_mask supposed to get initialized, now when this code is removed ?
It's always 0 now, isn't it ?
Whoops... oh, I'm really sorry about that. I ported the patch from a
branch with slightly different code there and overlooked this. Thanks
for catching it, will send v2 in a minute.
--
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] usb: phy-samsung-usb: Simplify PMU register handling
This patch simplifies the way the phy-samsung-usb code finds the correct
power management register to enable PHY clock gating. Previously, the
code would calculate the register address from a device tree supplied
base address and add an offset based on the PHY type.
Since every PHY has its own device tree entry and needs only one
register, we can just encode the address itself in the device tree and
remove the diffentiation in the code. The bitmask needed to specify the
bit within that register stays in place, allowing support for platforms
like s3c64xx that use different bits within the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56
Signed-off-by: Julius Werner jwer...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb/phy/phy-samsung-usb.c | 51 +-
drivers/usb/phy/phy-samsung-usb.h | 34 ++---
drivers/usb/phy/phy-samsung-usb2.c | 34 +++--
drivers/usb/phy/phy-samsung-usb3.c | 13 +++---
5 files changed, 34 insertions(+), 102 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..5a754d7 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -473,7 +473,7 @@
ranges;
usbphy-sys {
- reg = 0x10040704 0x8;
+ reg = 0x10040704 0x4;
};
};
@@ -505,7 +505,7 @@
ranges;
usbphy-sys {
- reg = 0x10040704 0x8,
+ reg = 0x10040708 0x4,
0x10050230 0x4;
};
};
diff --git a/drivers/usb/phy/phy-samsung-usb.c
b/drivers/usb/phy/phy-samsung-usb.c
index ac025ca..32c5264 100644
--- a/drivers/usb/phy/phy-samsung-usb.c
+++ b/drivers/usb/phy/phy-samsung-usb.c
@@ -27,7 +27,6 @@
#include linux/io.h
#include linux/of.h
#include linux/of_address.h
-#include linux/usb/samsung_usb_phy.h
#include phy-samsung-usb.h
@@ -42,9 +41,9 @@ int samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
return -ENODEV;
}
- sphy-pmuregs = of_iomap(usbphy_sys, 0);
+ sphy-pmureg = of_iomap(usbphy_sys, 0);
- if (sphy-pmuregs == NULL) {
+ if (sphy-pmureg == NULL) {
dev_err(sphy-dev, Can't get usb-phy pmu control register\n);
goto err0;
}
@@ -75,35 +74,25 @@ EXPORT_SYMBOL_GPL(samsung_usbphy_parse_dt);
*/
void samsung_usbphy_set_isolation_4210(struct samsung_usbphy *sphy, bool on)
{
- void __iomem *reg = NULL;
u32 reg_val;
- u32 en_mask = 0;
- if (!sphy-pmuregs) {
+ if (!sphy-pmureg) {
dev_warn(sphy-dev, Can't set pmu isolation\n);
return;
}
- if (sphy-phy_type == USB_PHY_TYPE_DEVICE) {
- reg = sphy-pmuregs + sphy-drv_data-devphy_reg_offset;
- en_mask = sphy-drv_data-devphy_en_mask;
- } else if (sphy-phy_type == USB_PHY_TYPE_HOST) {
- reg = sphy-pmuregs + sphy-drv_data-hostphy_reg_offset;
- en_mask = sphy-drv_data-hostphy_en_mask;
- }
-
- reg_val = readl(reg);
+ reg_val = readl(sphy-pmureg);
if (on)
- reg_val = ~en_mask;
+ reg_val = ~sphy-drv_data-phy_en_mask;
else
- reg_val |= en_mask;
+ reg_val |= sphy-drv_data-phy_en_mask;
- writel(reg_val, reg);
+ writel(reg_val, sphy-pmureg);
if (sphy-drv_data-cpu_type == TYPE_EXYNOS4X12) {
- writel(reg_val, sphy-pmuregs + EXYNOS4X12_PHY_HSIC_CTRL0);
- writel(reg_val, sphy-pmuregs + EXYNOS4X12_PHY_HSIC_CTRL1);
+ writel(reg_val, sphy-pmureg + EXYNOS4X12_PHY_HSIC_CTRL0);
+ writel(reg_val, sphy-pmureg + EXYNOS4X12_PHY_HSIC_CTRL1);
}
}
EXPORT_SYMBOL_GPL(samsung_usbphy_set_isolation_4210);
@@ -111,7 +100,7 @@ EXPORT_SYMBOL_GPL(samsung_usbphy_set_isolation_4210);
/*
* Configure the mode of working of usb-phy here: HOST/DEVICE.
*/
-void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy)
+void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy, bool device_mode)
{
u32 reg;
@@ -122,31 +111,15 @@ void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy)
reg = readl(sphy-sysreg);
- if (sphy-phy_type == USB_PHY_TYPE_DEVICE)
+ if (device_mode)
reg = ~EXYNOS_USB20PHY_CFG_HOST_LINK;
- else if (sphy-phy_type == USB_PHY_TYPE_HOST)
+ else
reg |= EXYNOS_USB20PHY_CFG_HOST_LINK;
writel(reg, sphy-sysreg);
}
EXPORT_SYMBOL_GPL(samsung_usbphy_cfg_sel);
-/*
- * PHYs are different for USB Device and USB Host.
- * This make sure that correct PHY type is selected
Re: [PATCH v2] usb: phy-samsung-usb: Simplify PMU register handling
On Mon, Jul 29, 2013 at 02:17:56PM -0700, Julius Werner wrote: This patch simplifies the way the phy-samsung-usb code finds the correct power management register to enable PHY clock gating. Previously, the code would calculate the register address from a device tree supplied base address and add an offset based on the PHY type. Since every PHY has its own device tree entry and needs only one register, we can just encode the address itself in the device tree and remove the diffentiation in the code. The bitmask needed to specify the bit within that register stays in place, allowing support for platforms like s3c64xx that use different bits within the same register. Due to this simplification, the whole complication of a Samsung-specific USB PHY type can be removed from the PHY driver. Change-Id: Id823f04bbf1942f307bd1d24ec9d8d55a69b0e56 remove this Gerrit Change-Id, please. Also resend with linux-...@vger.kernel.org in Cc. -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/7] ARM: dts: Update FIMD DT node for Exynos5 SoCs
Hi Vikas,
Please see my comment inline.
On Monday 29 of July 2013 19:19:26 Vikas Sajjan wrote:
Moves the properties of FIMD DT node which are common across Exynos5 based
SoCs like Exynos5250 and Exxynos5420 to exynos5.dtsi
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos5.dtsi| 10 ++
arch/arm/boot/dts/exynos5250.dtsi |6 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..80a4630 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -108,4 +108,14 @@
interrupts = 0 42 0;
status = disabled;
};
+
+ fimd {
I don't know why this node was named incorrectly in original file (probably the
patch adding it did not have enough review), but if you are modifying it
anyway, could you fix it to be conformant to DT conventions?
Whenever there is a reg property inside a node, the node should be named
whatever@addr, where addr is comma separated list of addresses specified in reg
property, in hex, without 0x prefix.
So in this case this should be at least
fimd@1440
but ideally
display-controller@1440
as nodes should have generic names (see ePAPR, paragraph 2.2.2).
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 3/7] ARM: dts: Add basic PM domains for EXYNOS5420
Hi Vikas, Yadwinder,
Please see my comments inline.
On Monday 29 of July 2013 19:19:27 Vikas Sajjan wrote:
From: Yadwinder Singh Brar yadi.b...@samsung.com
Add DT nodes for gsc, isp, mfc, disp, mau, g2d and msc PM domains.
Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 35
+++ 1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi index 8c54c4b..bd6b310 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -90,6 +90,41 @@
};
};
+ gsc_pd: pd@10044000 {
Please use power-domain for node names. We might have pd for other Exynos
SoCs, but this needs to be fixed.
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
[PATCH v3] usb: phy-samsung-usb: Simplify PMU register handling
This patch simplifies the way the phy-samsung-usb code finds the correct
power management register to enable PHY clock gating. Previously, the
code would calculate the register address from a device tree supplied
base address and add an offset based on the PHY type.
Since every PHY has its own device tree entry and needs only one
register, we can just encode the address itself in the device tree and
remove the diffentiation in the code. The bitmask needed to specify the
bit within that register stays in place, allowing support for platforms
like s3c64xx that use different bits within the same register. Due to
this simplification, the whole complication of a Samsung-specific USB
PHY type can be removed from the PHY driver.
Signed-off-by: Julius Werner jwer...@chromium.org
---
arch/arm/boot/dts/exynos5250.dtsi | 4 +--
drivers/usb/phy/phy-samsung-usb.c | 51 +-
drivers/usb/phy/phy-samsung-usb.h | 34 ++---
drivers/usb/phy/phy-samsung-usb2.c | 34 +++--
drivers/usb/phy/phy-samsung-usb3.c | 13 +++---
5 files changed, 34 insertions(+), 102 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..5a754d7 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -473,7 +473,7 @@
ranges;
usbphy-sys {
- reg = 0x10040704 0x8;
+ reg = 0x10040704 0x4;
};
};
@@ -505,7 +505,7 @@
ranges;
usbphy-sys {
- reg = 0x10040704 0x8,
+ reg = 0x10040708 0x4,
0x10050230 0x4;
};
};
diff --git a/drivers/usb/phy/phy-samsung-usb.c
b/drivers/usb/phy/phy-samsung-usb.c
index ac025ca..32c5264 100644
--- a/drivers/usb/phy/phy-samsung-usb.c
+++ b/drivers/usb/phy/phy-samsung-usb.c
@@ -27,7 +27,6 @@
#include linux/io.h
#include linux/of.h
#include linux/of_address.h
-#include linux/usb/samsung_usb_phy.h
#include phy-samsung-usb.h
@@ -42,9 +41,9 @@ int samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
return -ENODEV;
}
- sphy-pmuregs = of_iomap(usbphy_sys, 0);
+ sphy-pmureg = of_iomap(usbphy_sys, 0);
- if (sphy-pmuregs == NULL) {
+ if (sphy-pmureg == NULL) {
dev_err(sphy-dev, Can't get usb-phy pmu control register\n);
goto err0;
}
@@ -75,35 +74,25 @@ EXPORT_SYMBOL_GPL(samsung_usbphy_parse_dt);
*/
void samsung_usbphy_set_isolation_4210(struct samsung_usbphy *sphy, bool on)
{
- void __iomem *reg = NULL;
u32 reg_val;
- u32 en_mask = 0;
- if (!sphy-pmuregs) {
+ if (!sphy-pmureg) {
dev_warn(sphy-dev, Can't set pmu isolation\n);
return;
}
- if (sphy-phy_type == USB_PHY_TYPE_DEVICE) {
- reg = sphy-pmuregs + sphy-drv_data-devphy_reg_offset;
- en_mask = sphy-drv_data-devphy_en_mask;
- } else if (sphy-phy_type == USB_PHY_TYPE_HOST) {
- reg = sphy-pmuregs + sphy-drv_data-hostphy_reg_offset;
- en_mask = sphy-drv_data-hostphy_en_mask;
- }
-
- reg_val = readl(reg);
+ reg_val = readl(sphy-pmureg);
if (on)
- reg_val = ~en_mask;
+ reg_val = ~sphy-drv_data-phy_en_mask;
else
- reg_val |= en_mask;
+ reg_val |= sphy-drv_data-phy_en_mask;
- writel(reg_val, reg);
+ writel(reg_val, sphy-pmureg);
if (sphy-drv_data-cpu_type == TYPE_EXYNOS4X12) {
- writel(reg_val, sphy-pmuregs + EXYNOS4X12_PHY_HSIC_CTRL0);
- writel(reg_val, sphy-pmuregs + EXYNOS4X12_PHY_HSIC_CTRL1);
+ writel(reg_val, sphy-pmureg + EXYNOS4X12_PHY_HSIC_CTRL0);
+ writel(reg_val, sphy-pmureg + EXYNOS4X12_PHY_HSIC_CTRL1);
}
}
EXPORT_SYMBOL_GPL(samsung_usbphy_set_isolation_4210);
@@ -111,7 +100,7 @@ EXPORT_SYMBOL_GPL(samsung_usbphy_set_isolation_4210);
/*
* Configure the mode of working of usb-phy here: HOST/DEVICE.
*/
-void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy)
+void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy, bool device_mode)
{
u32 reg;
@@ -122,31 +111,15 @@ void samsung_usbphy_cfg_sel(struct samsung_usbphy *sphy)
reg = readl(sphy-sysreg);
- if (sphy-phy_type == USB_PHY_TYPE_DEVICE)
+ if (device_mode)
reg = ~EXYNOS_USB20PHY_CFG_HOST_LINK;
- else if (sphy-phy_type == USB_PHY_TYPE_HOST)
+ else
reg |= EXYNOS_USB20PHY_CFG_HOST_LINK;
writel(reg, sphy-sysreg);
}
EXPORT_SYMBOL_GPL(samsung_usbphy_cfg_sel);
-/*
- * PHYs are different for USB Device and USB Host.
- * This make sure that correct PHY type is selected before
- * any operation on PHY.
- */
-int
Re: [PATCH] usb: phy-samsung-usb: Simplify PMU register handling
On 07/29/2013 11:12 PM, Julius Werner wrote:
- if (sphy-phy_type == USB_PHY_TYPE_DEVICE) {
- reg = sphy-pmuregs + sphy-drv_data-devphy_reg_offset;
- en_mask = sphy-drv_data-devphy_en_mask;
- } else if (sphy-phy_type == USB_PHY_TYPE_HOST) {
- reg = sphy-pmuregs + sphy-drv_data-hostphy_reg_offset;
- en_mask = sphy-drv_data-hostphy_en_mask;
- }
How is en_mask supposed to get initialized, now when this code is removed ?
It's always 0 now, isn't it ?
Whoops... oh, I'm really sorry about that. I ported the patch from a
branch with slightly different code there and overlooked this. Thanks
for catching it, will send v2 in a minute.
v2 looks good, thanks. :) As a side note, we are working on the USB PHYs
driver using the generic PHY framework (actually Kamil is working on that).
Thus it is likely the original driver will get replaced in near future by
something else. Not sure when that happens exactly but I suspect it is
not worth to invest in the Samsung USB PHY drivers at drivers/usb/phy/
too much and introduce changes, especially in *.dts, that won't be for
long time in use. Perhaps Kamil can provide more details on which devices
are initially going to be covered by the new driver.
--
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 4/7] ARM: dts: Add FIMD DT node to exynos5420 DTS files
Hi Vikas,
Please see my comments inline.
On Monday 29 of July 2013 19:19:28 Vikas Sajjan wrote:
Adds FIMD DT node to exynos5420 based SMDK. Also adds display-timimg
information node.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
arch/arm/boot/dts/exynos5420-smdk5420.dts | 18 ++
arch/arm/boot/dts/exynos5420.dtsi |8
2 files changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts index 08607df..7c2f477 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -30,4 +30,22 @@
clock-frequency = 2400;
};
};
+
+ fimd {
+ display-timings {
+ native-mode = timing0;
+ timing0: timing@0 {
+ clock-frequency = 5;
+ hactive = 2560;
+ vactive = 1600;
+ hfront-porch = 48;
+ hback-porch = 80;
+ hsync-len = 32;
+ vback-porch = 16;
+ vfront-porch = 8;
+ vsync-len = 6;
+ };
+ };
+ };
+
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi index bd6b310..1f659f4 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -180,4 +180,12 @@
clocks = clock 260, clock 131;
clock-names = uart, clk_uart_baud0;
};
+
+ fimd {
+ samsung,power-domain = disp_pd;
+ clocks = clock 147, clock 421;
+ clock-names = sclk_fimd, fimd;
+ status = okay;
FIMD can't operate without display timings, so status = okay doesn't
represent real device state here. Please move status override to board dts.
I know that dtsi files of Exynos 5 SoCs have okay status as default, but this
is broken and needs to be fixed, because it moves the responsibility of knowing
about all SoC hardware to board dts.
Generally, the ePAPR document, chapter 2.3.4, specifies following definition of
status property:
The status property indicates the operational status of a device. Valid
values are listed and defined in the following table.
The table specifies following values:
“okay”
Indicates the device is operational
“disabled”
Indicates that the device is not presently operational, but it might
become
operational in the future (for example, something is not plugged in, or
switched off). Refer to the device binding for details on what disabled
means for a given device.
“fail”
Indicates that the device is not operational. A serious error was
detected
in the device, and it is unlikely to become operational without repair.
“fail-sss”
Indicates that the device is not operational. A serious error was
detected
in the device and it is unlikely to become operational without repair.
The
sss portion of the value is specific to the device and indicates the
error
condition detected.
Without all required properties the device will not be operational, so its
status should be set to disabled and then overriden to okay when missing
properties are provided (e.g. in board dts).
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 0/7] Add DT nodes for FIMD and DP controller for Exynos5420 SoC
Hi Vikas, Please use new address of device tree mailing list for next version of this series, which is: devicet...@vger.kernel.org Best regards, Tomasz On Monday 29 of July 2013 19:19:24 Vikas Sajjan wrote: This patchset adds DT nodes for FIMD and DP controller for Exynos5420 based SMDK. It moves all common properties of FIMD and DP controller DT node specific to Exynos5 Socs like 5250 and 5420 to exynos5.dtsi file. It also adds required PM domain DT nodes for exynos5420. Is rebased on branch kgene's for-next https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h= for-next The DP PHY DT Node is based on Jingoo Han's inflight patchset at http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/664 35 Vikas Sajjan (6): ARM: dts: move display-timimg information inside FIMD DT node for exynos5250 ARM: dts: Update FIMD DT node for Exynos5 SoCs ARM: dts: Add FIMD DT node to exynos5420 DTS files ARM: dts: Update DP controller DT Node for Exynos5 based SoCs ARM: dts: Add DP controller DT node to exynos5420 SoC ARM: dts: add pin state information for DP HPD support to Exynos5420 Yadwinder Singh Brar (1): ARM: dts: Add basic PM domains for EXYNOS5420 arch/arm/boot/dts/exynos5.dtsi| 39 +++ arch/arm/boot/dts/exynos5250-arndale.dts |9 -- arch/arm/boot/dts/exynos5250-smdk5250.dts | 35 + arch/arm/boot/dts/exynos5250.dtsi | 18 ++- arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 + arch/arm/boot/dts/exynos5420-smdk5420.dts | 23 ++ arch/arm/boot/dts/exynos5420.dtsi | 49 + 7 files changed, 135 insertions(+), 45 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
Re: [PATCH V2 7/8] ARM: dts: wm8994: Add wm8994 support on smdk5420
Hi Mark,
On Mon, Jul 29, 2013 at 7:13 PM, Mark Brown broo...@kernel.org wrote:
On Mon, Jul 29, 2013 at 05:31:16PM +0530, Padma Venkat wrote:
On Sat, Jul 27, 2013 at 6:46 AM, Padma Venkat padma@gmail.com wrote:
+ vdd: fixed-regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = vdd-supply;
These names look wrong - they should reflect the names in the schematic
as they're for human comprehensibility. This may just be a case of
dropping the -supply.
When I posted the same patch for smdk5250, you asked me to club all
the same supply regulators. So I clubbed AVDD2 and CPVDD. So any other
better name for representing both supplies?
No, I'd have told you to combine things taht come from the same supply
on the board - things like the speaker supplies for example aren't going
to be coming from separate places. The names should reflect whatever
the names on the schemaric are, like I say that's probably just removing
the -supply.
documentation update the other day, it's in my tree now) but it's not
essential and I suspect it needs some work on the clock driver side
still.
OK. I will check this.
As per schemata, input clock to MCLK1 is an oscillator clock with
16.9MHz and MCLK2 not showing any input clock. So here I need to add a
fixed rate clock with 16.9MHz as MCLK1 in the smdk board file.
Is it correct?
Yes, in the DTS (or to XCLKOUT on the AP?).
On smdk boards(atleast on smdk5250 and smdk5420) there is no XCLKOUT
funda. Codec MCLK can get clock from oscillator clock in codec master
mode or i2scdclk in codec slave mode. XCLKOUT is there in some other
variants of 5250 and 5420 where it is using other codecs than wm8994.
But the mux and divider of XCLKOUT is out of CMU. As Sylwester told it
is there in PMU registers.
Thanks
Padma
--
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: SAMSUNG: fix to support for missing cpu specific map_io
Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
map_io() is not needed for exynos5440 so need to fix to lookup
cpu which using map_io(). Without this, kernel boot log complains
'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/plat-samsung/init.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
index 3e5c461..50a3ea0 100644
--- a/arch/arm/plat-samsung/init.c
+++ b/arch/arm/plat-samsung/init.c
@@ -55,12 +55,13 @@ void __init s3c_init_cpu(unsigned long idcode,
printk(CPU %s (id 0x%08lx)\n, cpu-name, idcode);
- if (cpu-map_io == NULL || cpu-init == NULL) {
+ if (cpu-init == NULL) {
printk(KERN_ERR CPU %s support not enabled\n, cpu-name);
panic(Unsupported Samsung CPU);
}
- cpu-map_io();
+ if (cpu-map_io)
+ cpu-map_io();
}
/* s3c24xx_init_clocks
--
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] ARM: exynos5440_defconfig: add defconfig for EXYNOS5440
Since current exynos_defconfig cannot support for EXYNOS5440 because of LPAE, there were discussions about that in mailing list. So this adds initial defconfig which is tested on SSDK5440 and SD5v1 for LPAE enabled EXYNOS5440. This defconfig enables ARCH_EXYNOS, ARM_LPAE, PCI, CPU_FREQ Signed-off-by: Kukjin Kim kgene@samsung.com --- arch/arm/configs/exynos5440_defconfig | 138 + 1 file changed, 138 insertions(+) create mode 100644 arch/arm/configs/exynos5440_defconfig diff --git a/arch/arm/configs/exynos5440_defconfig b/arch/arm/configs/exynos5440_defconfig new file mode 100644 index 000..53daf04 --- /dev/null +++ b/arch/arm/configs/exynos5440_defconfig @@ -0,0 +1,138 @@ +CONFIG_SYSVIPC=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_KALLSYMS_ALL=y +CONFIG_PERF_EVENTS=y +CONFIG_MODULES=y +CONFIG_MODULE_FORCE_LOAD=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +# CONFIG_BLK_DEV_BSG is not set +CONFIG_PARTITION_ADVANCED=y +CONFIG_ARCH_EXYNOS=y +# CONFIG_ARCH_EXYNOS4 is not set +CONFIG_ARCH_EXYNOS5=y +# CONFIG_SOC_EXYNOS5250 is not set +CONFIG_ARM_LPAE=y +CONFIG_PCI=y +CONFIG_PCI_EXYNOS=y +CONFIG_SMP=y +CONFIG_PREEMPT=y +CONFIG_AEABI=y +CONFIG_HIGHMEM=y +CONFIG_TRANSPARENT_HUGEPAGE=y +CONFIG_CMDLINE=root=/dev/sda2 rw rootwait ignore_loglevel early_printk no_console_suspend mem=2048M@0x8000 mem=6144M@0x1 console=ttySAC0,115200 +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +CONFIG_CPU_FREQ_GOV_POWERSAVE=y +CONFIG_CPU_FREQ_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y +CONFIG_CPU_IDLE=y +CONFIG_VFP=y +CONFIG_NEON=y +CONFIG_PM_AUTOSLEEP=y +CONFIG_PM_WAKELOCKS=y +CONFIG_PM_DEBUG=y +CONFIG_PM_ADVANCED_DEBUG=y +CONFIG_PM_TEST_SUSPEND=y +CONFIG_APM_EMULATION=y +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_IP_PNP_RARP=y +CONFIG_IPV6=y +CONFIG_RFKILL_REGULATOR=y +CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_MTD=y +CONFIG_MTD_M25P80=y +# CONFIG_M25PXX_USE_FAST_READ is not set +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=10240 +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_SG=y +CONFIG_ATA=y +CONFIG_SATA_AHCI_PLATFORM=y +# CONFIG_ATA_SFF is not set +CONFIG_NETDEVICES=y +CONFIG_SMSC911X=y +CONFIG_STMMAC_ETH=y +CONFIG_STMMAC_DA=y +CONFIG_MARVELL_PHY=y +CONFIG_FIXED_PHY=y +CONFIG_USB_USBNET=y +CONFIG_USB_NET_SMSC75XX=y +CONFIG_USB_NET_SMSC95XX=y +CONFIG_INPUT_EVDEV=y +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +CONFIG_INPUT_TOUCHSCREEN=y +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_SAMSUNG=y +CONFIG_SERIAL_SAMSUNG_CONSOLE=y +CONFIG_HW_RANDOM=y +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_S3C2410=y +CONFIG_SPI=y +CONFIG_SPI_S3C64XX=y +# CONFIG_HWMON is not set +CONFIG_THERMAL=y +CONFIG_CPU_THERMAL=y +CONFIG_THERMAL_EMULATION=y +CONFIG_EXYNOS_THERMAL=y +CONFIG_EXYNOS_THERMAL_CORE=y +CONFIG_WATCHDOG=y +CONFIG_S3C2410_WATCHDOG=y +CONFIG_MFD_TPS65090=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_REGULATOR_GPIO=y +CONFIG_REGULATOR_TPS65090=y +CONFIG_USB=y +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_S5P=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_EXYNOS=y +CONFIG_USB_STORAGE=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_S3C=y +CONFIG_EXT2_FS=y +CONFIG_EXT3_FS=y +CONFIG_EXT4_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_TMPFS=y +CONFIG_TMPFS_POSIX_ACL=y +CONFIG_HUGETLBFS=y +CONFIG_CRAMFS=y +CONFIG_ROMFS_FS=y +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_ASCII=y +CONFIG_NLS_ISO8859_1=y +CONFIG_PRINTK_TIME=y +CONFIG_DEBUG_INFO=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_KERNEL=y +CONFIG_DETECT_HUNG_TASK=y +CONFIG_DEBUG_RT_MUTEXES=y +CONFIG_DEBUG_SPINLOCK=y +CONFIG_DEBUG_MUTEXES=y +CONFIG_DEBUG_USER=y +CONFIG_DEBUG_LL=y +CONFIG_EARLY_PRINTK=y +CONFIG_CRYPTO_ANSI_CPRNG=y +CONFIG_CRC_CCITT=y +CONFIG_VIRTUALIZATION=y +CONFIG_KVM=y -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: fix to support for missing cpu specific map_io
On 30 July 2013 09:57, Kukjin Kim kgene@samsung.com wrote:
Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
map_io() is not needed for exynos5440 so need to fix to lookup
cpu which using map_io(). Without this, kernel boot log complains
'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/plat-samsung/init.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
index 3e5c461..50a3ea0 100644
--- a/arch/arm/plat-samsung/init.c
+++ b/arch/arm/plat-samsung/init.c
@@ -55,12 +55,13 @@ void __init s3c_init_cpu(unsigned long idcode,
printk(CPU %s (id 0x%08lx)\n, cpu-name, idcode);
- if (cpu-map_io == NULL || cpu-init == NULL) {
+ if (cpu-init == NULL) {
printk(KERN_ERR CPU %s support not enabled\n, cpu-name);
panic(Unsupported Samsung CPU);
While at it you could probably remove the printk and have that message
printed by panic instead?
--
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control
Hi, On Tuesday 30 July 2013 09:12 AM, Rahul Sharma wrote: On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.com mailto:kis...@ti.com wrote: Hi, On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote: Thanks all, On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com mailto:sw0312@samsung.com wrote: Hello Kishon, On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote: Hi, On Thursday 13 June 2013 04:51 PM, Inki Dae wrote: -Original Message- From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com mailto:s.nawro...@samsung.com] Sent: Thursday, June 13, 2013 5:56 PM To: Rahul Sharma Cc: Rahul Sharma; Inki Dae; linux-samsung-soc@vger.kernel.org mailto:linux-samsung-soc@vger.kernel.org; devicetree- disc...@lists.ozlabs.org mailto:disc...@lists.ozlabs.org; DRI mailing list; Kukjin Kim; Seung-Woo Kim; Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren; grant.lik...@linaro.org mailto:grant.lik...@linaro.org Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control Hi, On 06/13/2013 06:26 AM, Rahul Sharma wrote: Mr. Dae, Thanks for your valuable inputs. I posted it as RFC because, I also have received comments to register hdmiphy as a clock controller. As we always configure it for specific frequency, hdmi-phy looks similar to a PLL. But it really doesn't belong to that class. Secondly prior to exynos5420, it was a i2c device. I am not sure we can register a I2C device as a clock controller. I wanted to discuss and explore this option here. Have you considered using the generic PHY framework for those HDMI PHY devices [1] ? I guess we could add a dedicated group of ops for video PHYs, similarly as is is done with struct v4l2_subdev_ops. For configuring things like the carrier/pixel clock frequency or anything what's common across the video PHYs. Perhaps you could have a look and see if this framework would be useful for HDMI and possibly point out anything what might be missing ? I'm not sure it it really solves the issues specific to the Exynos HDMI but at least with a generic PHY driver the PHY module would be separate from the PHY controller, as often same HDMI DPHY can be used with various types of a HDMI controller. So this would allow to not duplicate the HDMI PHY drivers in the long-term perspective. Yeah, at least, it seems that we could use PHY module to control PMU register, HDMI_PHY_CONTROL. However, PHY module provides only init/on/off callbacks. As you may know, HDMIPHY needs i2c interfaces to control HDMIPHY clock. So with PHY module, HDMIPHY driver could enable PMU more generically, but also has to use existing i2c stuff to control HDMIPHY clock. I had a quick review to Generic PHY Framework[v6] but I didn't see that the PHY module could generically support more features such as i2c stuff. I don't think PHY framework needs to provide i2c interfaces to program certain configurations. Instead in one of the callbacks (init/on/off) PHY driver can program whatever it wants using any of the interfaces it needs. IMO PHY framework should work independent of the interfaces. In exnoys hdmi case, i2c interface is not the exact issue. In exynos hdmi, hdmiphy should send i2c configuration about video clock information as the video mode information including resolution, bit per pixel, refresh rate passed from drm subsystem. So init/on/off callbacks of phy framework are not enough for exynos hdmiphy and it should have a callback to set video mode. Do you have plan to add driver specific extend callback pointers to phy framework? Currently, hdmi directly calls phy operations, but Rahul's another patch set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and hdmiphy is connected with exynos hdmi own sub driver callback operations. IMHO, if phy framework can support extend callback feature, then this own sub driver callbacks can be replaced with phy framework at long term view. Extended callbacks are always welcome. I can also use phy device private data to pass on private ops like get_pixelclk and set_pixelclk. I would recommend creating a wrapper to the existing PHY framework for HDMI PHY. That way, we can have other HDMI phys added easily. We need to figure out all the ops that might be needed by the HDMI PHY to be added to the wrapper. IMO extended callbacks can lead to abuse of the system and should be used only when absolutely
Re: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
Hi, On Monday 29 July 2013 09:21 PM, Sylwester Nawrocki wrote: On 07/26/2013 02:49 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. For dt-boot, the PHY drivers should also register *PHY provider* with the framework. PHY drivers should create the PHY by passing id and ops like init, exit, power_on and power_off. This framework is also pm runtime enabled. The documentation for the generic PHY framework is added in Documentation/phy.txt and the documentation for dt binding can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt Cc: Tomasz Figa t.f...@samsung.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Felipe Balbi ba...@ti.com Tested-by: Sylwester Nawrocki s.nawro...@samsung.com --- .../devicetree/bindings/phy/phy-bindings.txt | 66 ++ Documentation/phy.txt | 166 + MAINTAINERS|8 + drivers/Kconfig|2 + drivers/Makefile |2 + drivers/phy/Kconfig| 18 + drivers/phy/Makefile |5 + drivers/phy/phy-core.c | 714 include/linux/phy/phy.h| 270 9 files changed, 1251 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/phy-bindings.txt create mode 100644 Documentation/phy.txt create mode 100644 drivers/phy/Kconfig create mode 100644 drivers/phy/Makefile create mode 100644 drivers/phy/phy-core.c create mode 100644 include/linux/phy/phy.h diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt new file mode 100644 index 000..8ae844f --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt @@ -0,0 +1,66 @@ +This document explains only the device tree data binding. For general +information about PHY subsystem refer to Documentation/phy.txt [...] @@ -0,0 +1,166 @@ +PHY SUBSYSTEM + Kishon Vijay Abraham I kis...@ti.com + +This document explains the Generic PHY Framework along with the APIs provided, +and how-to-use. + +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controllers have PHY functionality embedded into it and others use an external +PHY. Other peripherals that use PHY include Wireless LAN, Ethernet, +SATA etc. + +The intention of creating this framework is to bring the PHY drivers spread +all over the Linux kernel to drivers/phy to increase code re-use and for +better code maintainability. + +This framework will be of use only to devices that use external PHY (PHY +functionality is not embedded within the controller). + +2. Registering/Unregistering the PHY provider + +PHY provider refers to an entity that implements one or more PHY instances. +For the simple case where the PHY provider implements only a single instance of +the PHY, the framework provides its own implementation of of_xlate in +of_phy_simple_xlate. If the PHY provider implements multiple instances, it +should provide its own implementation of of_xlate. of_xlate is used only for +dt boot case. + +#define of_phy_provider_register(dev, xlate)\ +__of_phy_provider_register((dev), THIS_MODULE, (xlate)) + +#define devm_of_phy_provider_register(dev, xlate) \ +__of_phy_provider_register((dev), THIS_MODULE, (xlate)) This needs to be: __devm_of_phy_provider_register((dev), THIS_MODULE, (xlate)) as Kamil pointed out. We've tested it here with v9 and it makes Bad Things happen. ;) +of_phy_provider_register and devm_of_phy_provider_register macros can be used to +register the phy_provider and it takes device and of_xlate as +arguments. For the dt boot case, all PHY providers should use one of the above +2 macros to register the PHY provider. + +void devm_of_phy_provider_unregister(struct device *dev, +struct phy_provider *phy_provider); +void of_phy_provider_unregister(struct phy_provider *phy_provider); + +devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to +unregister the PHY. + [...] diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c new file mode 100644 index 000..f1d15e5 --- /dev/null +++ b/drivers/phy/phy-core.c @@ -0,0 +1,714 @@ [...] +static struct phy
