[PATCH] staging: lustre: cleanup align switch and case
From: samuel kihahu
Align switch and case to be at the same indent.
Signed-off-by: samuel kihahu
---
drivers/staging/lustre/lnet/selftest/module.c | 50 +--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/lustre/lnet/selftest/module.c
b/drivers/staging/lustre/lnet/selftest/module.c
index 6dd4309..b5f07fa 100644
--- a/drivers/staging/lustre/lnet/selftest/module.c
+++ b/drivers/staging/lustre/lnet/selftest/module.c
@@ -61,31 +61,31 @@ lnet_selftest_fini(void)
int i;
switch (lst_init_step) {
- case LST_INIT_CONSOLE:
- lstcon_console_fini();
- case LST_INIT_FW:
- sfw_shutdown();
- case LST_INIT_RPC:
- srpc_shutdown();
- case LST_INIT_WI_TEST:
- for (i = 0;
-i < cfs_cpt_number(lnet_cpt_table()); i++) {
- if (lst_sched_test[i] == NULL)
- continue;
- cfs_wi_sched_destroy(lst_sched_test[i]);
- }
- LIBCFS_FREE(lst_sched_test,
- sizeof(lst_sched_test[0]) *
- cfs_cpt_number(lnet_cpt_table()));
- lst_sched_test = NULL;
-
- case LST_INIT_WI_SERIAL:
- cfs_wi_sched_destroy(lst_sched_serial);
- lst_sched_serial = NULL;
- case LST_INIT_NONE:
- break;
- default:
- LBUG();
+ case LST_INIT_CONSOLE:
+ lstcon_console_fini();
+ case LST_INIT_FW:
+ sfw_shutdown();
+ case LST_INIT_RPC:
+ srpc_shutdown();
+ case LST_INIT_WI_TEST:
+ for (i = 0;
+i < cfs_cpt_number(lnet_cpt_table()); i++) {
+ if (lst_sched_test[i] == NULL)
+ continue;
+ cfs_wi_sched_destroy(lst_sched_test[i]);
+ }
+ LIBCFS_FREE(lst_sched_test,
+ sizeof(lst_sched_test[0]) *
+ cfs_cpt_number(lnet_cpt_table()));
+ lst_sched_test = NULL;
+
+ case LST_INIT_WI_SERIAL:
+ cfs_wi_sched_destroy(lst_sched_serial);
+ lst_sched_serial = NULL;
+ case LST_INIT_NONE:
+ break;
+ default:
+ LBUG();
}
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memory: Add NVIDIA SMMU suspend/resume support
On 12/12/2014 04:18 PM, Alexandre Courbot wrote:
> Hi Mark,
>
> On Mon, Dec 8, 2014 at 3:20 PM, Mark Zhang wrote:
>> This patch adds suspend/resume support for NVIDIA SMMU.
>
>
>> This patch is created on top of Thierry Reding's patch set:
>>
>> "[PATCH v7 00/12] NVIDIA Tegra memory controller and IOMMU support"
>
> You should have this comment under the "---" as we don't need it to
> persist once this patch is merged.
>
Yep, will do.
>>
>> Signed-off-by: Mark Zhang
>> ---
>> drivers/iommu/tegra-smmu.c | 79
>> +-
>> drivers/memory/tegra/mc.c | 21
>> drivers/memory/tegra/mc.h | 4 +++
>> 3 files changed, 103 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
>> index 0909e0bae9ec..ab38805055a4 100644
>> --- a/drivers/iommu/tegra-smmu.c
>> +++ b/drivers/iommu/tegra-smmu.c
>> @@ -17,6 +17,8 @@
>> #include
>> #include
>>
>> +struct tegra_smmu_as;
>> +
>> struct tegra_smmu {
>> void __iomem *regs;
>> struct device *dev;
>> @@ -25,9 +27,10 @@ struct tegra_smmu {
>> const struct tegra_smmu_soc *soc;
>>
>> unsigned long *asids;
>> + struct tegra_smmu_as **as;
>> struct mutex lock;
>>
>> - struct list_head list;
>> + struct list_head swgroup_asid_list;
>> };
>>
>> struct tegra_smmu_as {
>> @@ -40,6 +43,12 @@ struct tegra_smmu_as {
>> u32 attr;
>> };
>>
>> +struct tegra_smmu_swgroup_asid {
>> + struct list_head list;
>> + unsigned swgroup_id;
>> + unsigned asid;
>> +};
>> +
>> static inline void smmu_writel(struct tegra_smmu *smmu, u32 value,
>>unsigned long offset)
>> {
>> @@ -376,6 +385,7 @@ static int tegra_smmu_as_prepare(struct tegra_smmu *smmu,
>> as->smmu = smmu;
>> as->use_count++;
>>
>> + smmu->as[as->id] = as;
>> return 0;
>> }
>>
>> @@ -386,6 +396,7 @@ static void tegra_smmu_as_unprepare(struct tegra_smmu
>> *smmu,
>> return;
>>
>> tegra_smmu_free_asid(smmu, as->id);
>> + smmu->as[as->id] = NULL;
>> as->smmu = NULL;
>> }
>>
>> @@ -398,6 +409,7 @@ static int tegra_smmu_attach_dev(struct iommu_domain
>> *domain,
>> struct of_phandle_args args;
>> unsigned int index = 0;
>> int err = 0;
>> + struct tegra_smmu_swgroup_asid *sa = NULL;
>
> This initialization is unneeded. Actually this declaration would
> probably be better placed in the while() loop below since its usage is
> local to it.
>
Correct.
>>
>> while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
>> index,
>>)) {
>> @@ -411,6 +423,14 @@ static int tegra_smmu_attach_dev(struct iommu_domain
>> *domain,
>> return err;
>>
>> tegra_smmu_enable(smmu, swgroup, as->id);
>> +
>> + sa = kzalloc(sizeof(struct tegra_smmu_swgroup_asid),
>> + GFP_KERNEL);
>> + INIT_LIST_HEAD(>list);
>
> You don't need to call INIT_LIST_HEAD on this, list_add_tail() will
> effectively overwrite any initialization done by this macro (see
> include/linux/list.h).
Right. So why we still need "INIT_LIST_HEAD"? Given most of the list
functions will manipulate "list->prev" & "list->next", I can't imagine a
scenario that we create a list while not calling list functions.
>
>> + sa->swgroup_id = swgroup;
>> + sa->asid = as->id;
>> + list_add_tail(>list, >swgroup_asid_list);
>> +
>> index++;
>> }
>>
>> @@ -427,6 +447,7 @@ static void tegra_smmu_detach_dev(struct iommu_domain
>> *domain, struct device *de
>> struct tegra_smmu *smmu = as->smmu;
>> struct of_phandle_args args;
>> unsigned int index = 0;
>> + struct tegra_smmu_swgroup_asid *sa = NULL;
>
> Same here, move the declaration into the while() loop and remove the
> initialization.
>
OK.
>>
>> while (of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
>> index,
>> )) {
>> @@ -435,6 +456,13 @@ static void tegra_smmu_detach_dev(struct iommu_domain
>> *domain, struct device *de
>> if (args.np != smmu->dev->of_node)
>> continue;
>>
>> + list_for_each_entry(sa, >swgroup_asid_list, list) {
>> + if (sa->asid == as->id && sa->swgroup_id == swgroup)
>> + break;
>> + }
>> + list_del(>list);
>> + kfree(sa);
>> +
>> tegra_smmu_disable(smmu, swgroup, as->id);
>> tegra_smmu_as_unprepare(smmu, as);
>> index++;
>> @@ -651,6 +679,48 @@ static void tegra_smmu_ahb_enable(void)
>> }
>> }
>>
>> +void tegra_smmu_resume(struct tegra_smmu *smmu)
>> +{
>> + struct tegra_smmu_as
Ask help about killing irqchip.irq_print_chip on PPC platforms
Hi Scott and Tudor, Sorry, resend and Ccing the list. We are trying to clean up some irqchip interfaces, and irqchip.irq_print_chip is a candidate for removal. After some changes on x86 side, arch/powerpc/sysdev/fsl_msi.c may be the last user of irqchip.irq_print_chip. So could you please help to advice on whether we could kill irqchip.irq_print_chip by using "fsl-msi" instead of "fsl-msi-%d" for irqchip name? Will it break any userspace interfaces? Thanks! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/23 15:26, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/23 9:50, Chen, Tiejun wrote: On 2014/12/22 17:23, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/21 20:46, Jamie Heilman wrote: With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 Looks some MSR writing issues such a failed entry. If you're running a guest on an Intel machine without unrestricted mode support, the failure can be most likely due to the guest entering an invalid state for Intel VT. For example, the guest maybe running in big real mode which is not supported on less recent Intel processors. EAX= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= And I don't see any obvious wrong as well. Any valuable info from dmesg? With the simple qemu command above, on 3.18.1 I see: kern.info: kvm: zapping shadow pages for mmio generation wraparound when I fire up a full guest that's actually useful I get: kern.info: kvm: zapping shadow pages for mmio generation wraparound kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the message I mention above to stderr. Same thing with a stock 3.19.0-rc1. Once I apply your patch the simple test command produces the same zapping shadow pages messages as 3.18.1, and a test guest of a Debian Jessie image (w/stock distro kernel) produces the same thing with disabled perfctr wrmsr message. However, it doesn't look like Sorry I'm not sure if I understood current status. Looks 3.19-rc1 & my patch just fix that error above, KVM: entry failed, hardware error 0x8021 ... Right? I'm entirely out of the woods, because one of my other guest VMs with a custom kernel that works great under 3.18.1 now fails to run. Nothing in dmesg, but here's the stderr: But even you revert 34a1cd60d17 or just apply my patch, something else introduced between 3.18.1 and 3.19-rc1 led this error below, right? KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 <5b> 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this So if my understanding is correct, this is probably another bug. And especially, I already saw the same log in another thread, "Cleaning up the KVM clock". Maybe you can continue to `git bisect` to locate that bad commit. Looks just now Andy found that commit, 0e60b0799fedc495a5c57dbd669de3c10d72edd2 "kvm: change memslot sorting rule from size to GFN", maybe you can try to revert this to try yours again. That doesn't revert cleanly for me, and I don't have much time to Yeah, I guess all associated commits should be reverted gradually. fiddle with it until the 24th---so checked out the commit before it (d4ae84a0), applied your patch, built, and yes, everything works fine Thanks for your test. I think I can submit this patch to fix one of yours problems and I'd like to add you as Reported-by & Tested-by. Then we can step into another issue. And I'm trying to fetch 3.19-rc1 (because I'm always working on kvm/next.) to take a look at that but maybe Paolo is already going on that. Tiejun at that point. I'll probably have time for another full bisection later, assuming things aren't ironed out already by then.
[PATCH 3/3] clk: samsung: exynos4415: Use samsung_cmu_register_one() to simplify code
This patch uses the samsung_cmu_register_one() to simplify complicated code
for Exynos4415.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Cc: Mike Turquette
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/clk/samsung/clk-exynos4415.c | 216 ---
1 file changed, 48 insertions(+), 168 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4415.c
b/drivers/clk/samsung/clk-exynos4415.c
index 2123fc2..6c78b09 100644
--- a/drivers/clk/samsung/clk-exynos4415.c
+++ b/drivers/clk/samsung/clk-exynos4415.c
@@ -113,19 +113,6 @@
#define DIV_CPU0 0x14500
#define DIV_CPU1 0x14504
-enum exynos4415_plls {
- apll, epll, g3d_pll, isp_pll, disp_pll,
- nr_plls,
-};
-
-static struct samsung_clk_provider *exynos4415_ctx;
-
-/*
- * Support for CMU save/restore across system suspends
- */
-#ifdef CONFIG_PM_SLEEP
-static struct samsung_clk_reg_dump *exynos4415_clk_regs;
-
static unsigned long exynos4415_cmu_clk_regs[] __initdata = {
SRC_LEFTBUS,
DIV_LEFTBUS,
@@ -219,41 +206,6 @@ static unsigned long exynos4415_cmu_clk_regs[] __initdata
= {
DIV_CPU1,
};
-static int exynos4415_clk_suspend(void)
-{
- samsung_clk_save(exynos4415_ctx->reg_base, exynos4415_clk_regs,
- ARRAY_SIZE(exynos4415_cmu_clk_regs));
-
- return 0;
-}
-
-static void exynos4415_clk_resume(void)
-{
- samsung_clk_restore(exynos4415_ctx->reg_base, exynos4415_clk_regs,
- ARRAY_SIZE(exynos4415_cmu_clk_regs));
-}
-
-static struct syscore_ops exynos4415_clk_syscore_ops = {
- .suspend = exynos4415_clk_suspend,
- .resume = exynos4415_clk_resume,
-};
-
-static void exynos4415_clk_sleep_init(void)
-{
- exynos4415_clk_regs =
- samsung_clk_alloc_reg_dump(exynos4415_cmu_clk_regs,
- ARRAY_SIZE(exynos4415_cmu_clk_regs));
- if (!exynos4415_clk_regs) {
- pr_warn("%s: Failed to allocate sleep save data\n", __func__);
- return;
- }
-
- register_syscore_ops(_clk_syscore_ops);
-}
-#else
-static inline void exynos4415_clk_sleep_init(void) { }
-#endif
-
/* list of all parent clock list */
PNAME(mout_g3d_pllsrc_p) = { "fin_pll", };
@@ -959,56 +911,40 @@ static struct samsung_pll_rate_table
exynos4415_epll_rates[] = {
{ /* sentinel */ }
};
-static struct samsung_pll_clock exynos4415_plls[nr_plls] __initdata = {
- [apll] = PLL(pll_35xx, CLK_FOUT_APLL, "fout_apll", "fin_pll",
- APLL_LOCK, APLL_CON0, NULL),
- [epll] = PLL(pll_36xx, CLK_FOUT_EPLL, "fout_epll", "fin_pll",
- EPLL_LOCK, EPLL_CON0, NULL),
- [g3d_pll] = PLL(pll_35xx, CLK_FOUT_G3D_PLL, "fout_g3d_pll",
- "mout_g3d_pllsrc", G3D_PLL_LOCK, G3D_PLL_CON0, NULL),
- [isp_pll] = PLL(pll_35xx, CLK_FOUT_ISP_PLL, "fout_isp_pll", "fin_pll",
- ISP_PLL_LOCK, ISP_PLL_CON0, NULL),
- [disp_pll] = PLL(pll_35xx, CLK_FOUT_DISP_PLL, "fout_disp_pll",
- "fin_pll", DISP_PLL_LOCK, DISP_PLL_CON0, NULL),
+static struct samsung_pll_clock exynos4415_plls[] __initdata = {
+ PLL(pll_35xx, CLK_FOUT_APLL, "fout_apll", "fin_pll",
+ APLL_LOCK, APLL_CON0, exynos4415_pll_rates),
+ PLL(pll_36xx, CLK_FOUT_EPLL, "fout_epll", "fin_pll",
+ EPLL_LOCK, EPLL_CON0, exynos4415_epll_rates),
+ PLL(pll_35xx, CLK_FOUT_G3D_PLL, "fout_g3d_pll", "mout_g3d_pllsrc",
+ G3D_PLL_LOCK, G3D_PLL_CON0, exynos4415_pll_rates),
+ PLL(pll_35xx, CLK_FOUT_ISP_PLL, "fout_isp_pll", "fin_pll",
+ ISP_PLL_LOCK, ISP_PLL_CON0, exynos4415_pll_rates),
+ PLL(pll_35xx, CLK_FOUT_DISP_PLL, "fout_disp_pll",
+ "fin_pll", DISP_PLL_LOCK, DISP_PLL_CON0, exynos4415_pll_rates),
+};
+
+static struct samsung_cmu_info cmu_info __initdata = {
+ .pll_clks = exynos4415_plls,
+ .nr_pll_clks= ARRAY_SIZE(exynos4415_plls),
+ .mux_clks = exynos4415_mux_clks,
+ .nr_mux_clks= ARRAY_SIZE(exynos4415_mux_clks),
+ .div_clks = exynos4415_div_clks,
+ .nr_div_clks= ARRAY_SIZE(exynos4415_div_clks),
+ .gate_clks = exynos4415_gate_clks,
+ .nr_gate_clks = ARRAY_SIZE(exynos4415_gate_clks),
+ .fixed_clks = exynos4415_fixed_rate_clks,
+ .nr_fixed_clks = ARRAY_SIZE(exynos4415_fixed_rate_clks),
+ .fixed_factor_clks = exynos4415_fixed_factor_clks,
+ .nr_fixed_factor_clks = ARRAY_SIZE(exynos4415_fixed_factor_clks),
+ .nr_clk_ids = CLK_NR_CLKS,
+ .clk_regs = exynos4415_cmu_clk_regs,
+ .nr_clk_regs= ARRAY_SIZE(exynos4415_cmu_clk_regs),
};
static void __init exynos4415_cmu_init(struct device_node *np)
{
- void __iomem
[PATCH 0/3] clk: samsung: Use samsung_cmu_register_one() to simplify code
This patch-set uses the samsung_cmu_register_one() function to simplify the clock driver for Exynos3250/Exynos4415 SoC and change return value of samsung_cmu_register_one() because some clock driver may need the instance of samsung_clk_provider structure. Chanwoo Choi (3): clk: samsung: Changes the return value of samsung_cmu_register_one() clk: samsung: exynos3250: Use samsung_cmu_register_one() to simplify code clk: samsung: exynos4415: Use samsung_cmu_register_one() to simplify code drivers/clk/samsung/clk-exynos3250.c | 217 --- drivers/clk/samsung/clk-exynos4415.c | 216 -- drivers/clk/samsung/clk.c| 13 ++- drivers/clk/samsung/clk.h| 3 +- 4 files changed, 107 insertions(+), 342 deletions(-) -- 1.8.5.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] clk: samsung: exynos3250: Use samsung_cmu_register_one() to simplify code
This patch uses the samsung_cmu_register_one() to simplify complicated code.
for Exynos3250.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Cc: Mike Turquette
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
drivers/clk/samsung/clk-exynos3250.c | 217 ---
1 file changed, 47 insertions(+), 170 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index 6e6cca3..cc4c348 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -104,27 +104,6 @@
#define PWR_CTRL1_USE_CORE1_WFI(1 << 1)
#define PWR_CTRL1_USE_CORE0_WFI(1 << 0)
-/* list of PLLs to be registered */
-enum exynos3250_plls {
- apll, mpll, vpll, upll,
- nr_plls
-};
-
-/* list of PLLs in DMC block to be registered */
-enum exynos3250_dmc_plls {
- bpll, epll,
- nr_dmc_plls
-};
-
-static void __iomem *reg_base;
-static void __iomem *dmc_reg_base;
-
-/*
- * Support for CMU save/restore across system suspends
- */
-#ifdef CONFIG_PM_SLEEP
-static struct samsung_clk_reg_dump *exynos3250_clk_regs;
-
static unsigned long exynos3250_cmu_clk_regs[] __initdata = {
SRC_LEFTBUS,
DIV_LEFTBUS,
@@ -195,43 +174,6 @@ static unsigned long exynos3250_cmu_clk_regs[] __initdata
= {
PWR_CTRL2,
};
-static int exynos3250_clk_suspend(void)
-{
- samsung_clk_save(reg_base, exynos3250_clk_regs,
- ARRAY_SIZE(exynos3250_cmu_clk_regs));
- return 0;
-}
-
-static void exynos3250_clk_resume(void)
-{
- samsung_clk_restore(reg_base, exynos3250_clk_regs,
- ARRAY_SIZE(exynos3250_cmu_clk_regs));
-}
-
-static struct syscore_ops exynos3250_clk_syscore_ops = {
- .suspend = exynos3250_clk_suspend,
- .resume = exynos3250_clk_resume,
-};
-
-static void exynos3250_clk_sleep_init(void)
-{
- exynos3250_clk_regs =
- samsung_clk_alloc_reg_dump(exynos3250_cmu_clk_regs,
- ARRAY_SIZE(exynos3250_cmu_clk_regs));
- if (!exynos3250_clk_regs) {
- pr_warn("%s: Failed to allocate sleep save data\n", __func__);
- goto err;
- }
-
- register_syscore_ops(_clk_syscore_ops);
- return;
-err:
- kfree(exynos3250_clk_regs);
-}
-#else
-static inline void exynos3250_clk_sleep_init(void) { }
-#endif
-
/* list of all parent clock list */
PNAME(mout_vpllsrc_p) = { "fin_pll", };
@@ -782,18 +724,18 @@ static struct samsung_pll_rate_table
exynos3250_vpll_rates[] = {
{ /* sentinel */ }
};
-static struct samsung_pll_clock exynos3250_plls[nr_plls] __initdata = {
- [apll] = PLL(pll_35xx, CLK_FOUT_APLL, "fout_apll", "fin_pll",
- APLL_LOCK, APLL_CON0, NULL),
- [mpll] = PLL(pll_35xx, CLK_FOUT_MPLL, "fout_mpll", "fin_pll",
- MPLL_LOCK, MPLL_CON0, NULL),
- [vpll] = PLL(pll_36xx, CLK_FOUT_VPLL, "fout_vpll", "fin_pll",
- VPLL_LOCK, VPLL_CON0, NULL),
- [upll] = PLL(pll_35xx, CLK_FOUT_UPLL, "fout_upll", "fin_pll",
- UPLL_LOCK, UPLL_CON0, NULL),
+static struct samsung_pll_clock exynos3250_plls[] __initdata = {
+ PLL(pll_35xx, CLK_FOUT_APLL, "fout_apll", "fin_pll",
+ APLL_LOCK, APLL_CON0, exynos3250_pll_rates),
+ PLL(pll_35xx, CLK_FOUT_MPLL, "fout_mpll", "fin_pll",
+ MPLL_LOCK, MPLL_CON0, exynos3250_pll_rates),
+ PLL(pll_36xx, CLK_FOUT_VPLL, "fout_vpll", "fin_pll",
+ VPLL_LOCK, VPLL_CON0, exynos3250_vpll_rates),
+ PLL(pll_35xx, CLK_FOUT_UPLL, "fout_upll", "fin_pll",
+ UPLL_LOCK, UPLL_CON0, exynos3250_pll_rates),
};
-static void __init exynos3_core_down_clock(void)
+static void __init exynos3_core_down_clock(void __iomem *reg_base)
{
unsigned int tmp;
@@ -814,38 +756,31 @@ static void __init exynos3_core_down_clock(void)
__raw_writel(0x0, reg_base + PWR_CTRL2);
}
+static struct samsung_cmu_info cmu_info __initdata = {
+ .pll_clks = exynos3250_plls,
+ .nr_pll_clks= ARRAY_SIZE(exynos3250_plls),
+ .mux_clks = mux_clks,
+ .nr_mux_clks= ARRAY_SIZE(mux_clks),
+ .div_clks = div_clks,
+ .nr_div_clks= ARRAY_SIZE(div_clks),
+ .gate_clks = gate_clks,
+ .nr_gate_clks = ARRAY_SIZE(gate_clks),
+ .fixed_factor_clks = fixed_factor_clks,
+ .nr_fixed_factor_clks = ARRAY_SIZE(fixed_factor_clks),
+ .nr_clk_ids = CLK_NR_CLKS,
+ .clk_regs = exynos3250_cmu_clk_regs,
+ .nr_clk_regs= ARRAY_SIZE(exynos3250_cmu_clk_regs),
+};
+
static void __init exynos3250_cmu_init(struct device_node *np)
{
struct samsung_clk_provider *ctx;
- reg_base =
[PATCH 1/3] clk: samsung: Changes the return value of samsung_cmu_register_one()
This patch changes the return value of samsung_cmu_register_one()
from 'void type' to 'samsung_clk_provider structure' pointer type because
samsung_clk_provider may be used in each clock driver.
Cc: Sylwester Nawrocki
Cc: Tomasz Figa
Cc: Mike Turquette
Signed-off-by: Chanwoo Choi
---
drivers/clk/samsung/clk.c | 13 ++---
drivers/clk/samsung/clk.h | 3 ++-
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 4bda540..980c5da 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -374,19 +374,24 @@ static void samsung_clk_sleep_init(void __iomem *reg_base,
* Common function which registers plls, muxes, dividers and gates
* for each CMU. It also add CMU register list to register cache.
*/
-void __init samsung_cmu_register_one(struct device_node *np,
+struct samsung_clk_provider* __init samsung_cmu_register_one(
+ struct device_node *np,
struct samsung_cmu_info *cmu)
{
void __iomem *reg_base;
struct samsung_clk_provider *ctx;
reg_base = of_iomap(np, 0);
- if (!reg_base)
+ if (!reg_base) {
panic("%s: failed to map registers\n", __func__);
+ return NULL;
+ }
ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids);
- if (!ctx)
+ if (!ctx) {
panic("%s: unable to alllocate ctx\n", __func__);
+ return ctx;
+ }
if (cmu->pll_clks)
samsung_clk_register_pll(ctx, cmu->pll_clks, cmu->nr_pll_clks,
@@ -410,4 +415,6 @@ void __init samsung_cmu_register_one(struct device_node *np,
cmu->nr_clk_regs);
samsung_clk_of_add_provider(np, ctx);
+
+ return ctx;
}
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index 8acabe1..e4c7538 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -392,7 +392,8 @@ extern void __init samsung_clk_register_pll(struct
samsung_clk_provider *ctx,
struct samsung_pll_clock *pll_list,
unsigned int nr_clk, void __iomem *base);
-extern void __init samsung_cmu_register_one(struct device_node *,
+extern struct samsung_clk_provider __init *samsung_cmu_register_one(
+ struct device_node *,
struct samsung_cmu_info *);
extern unsigned long _get_rate(const char *clk_name);
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH 6/6] f2fs: avoid double lock for cp_rwsem
Hi, On Tue, Dec 23, 2014 at 03:01:36PM +0800, Chao Yu wrote: > Hi Jaegeuk, > > > -Original Message- > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > > Sent: Monday, December 22, 2014 12:35 AM > > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > > linux-f2fs-de...@lists.sourceforge.net > > Cc: Jaegeuk Kim > > Subject: [f2fs-dev] [PATCH 6/6] f2fs: avoid double lock for cp_rwsem > > > > The __f2fs_add_link is covered by cp_rwsem all the time. > > This calls init_inode_metadata, which conducts some acl operations including > > memory allocation with GFP_KERNEL previously. > > But, under memory pressure, f2fs_write_data_page can be called, which also > > grabs cp_mutex too. > > grabs cp_rwsem. Got it. > > > Basically, it's safe since down_read was used in both of cases, but it'd > > better avoid this situation in advance. > > If checkpoint intend to hold down_write in the middle of the two down_read > caller, it will cause a deadlock, so it's not safe. What I meant was like this. - down_read - down_read - up_read - up_read This should be safe, right? Thanks, > > Could you update the comments? > > > > > Signed-off-by: Jaegeuk Kim > > Anyway, Nice catch and please add: > > Reviewed-by: Chao Yu > > > --- > > fs/f2fs/acl.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c > > index 1ccb26b..7f12d28 100644 > > --- a/fs/f2fs/acl.c > > +++ b/fs/f2fs/acl.c > > @@ -62,7 +62,7 @@ static struct posix_acl *f2fs_acl_from_disk(const char > > *value, size_t size) > > if (count == 0) > > return NULL; > > > > - acl = posix_acl_alloc(count, GFP_KERNEL); > > + acl = posix_acl_alloc(count, GFP_NOFS); > > if (!acl) > > return ERR_PTR(-ENOMEM); > > > > @@ -116,7 +116,7 @@ static void *f2fs_acl_to_disk(const struct posix_acl > > *acl, size_t *size) > > int i; > > > > f2fs_acl = kmalloc(sizeof(struct f2fs_acl_header) + acl->a_count * > > - sizeof(struct f2fs_acl_entry), GFP_KERNEL); > > + sizeof(struct f2fs_acl_entry), GFP_NOFS); > > if (!f2fs_acl) > > return ERR_PTR(-ENOMEM); > > > > -- > > 2.1.1 > > > > > > -- > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=164703151=/4140/ostg.clktrk > > ___ > > Linux-f2fs-devel mailing list > > linux-f2fs-de...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] f2fs: add extent cache base on rb-tree
Hi Chao, On Tue, Dec 23, 2014 at 11:01:39AM +0800, Chao Yu wrote: > Hi Jaegeuk, > > > -Original Message- > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > > Sent: Tuesday, December 23, 2014 7:16 AM > > To: Chao Yu > > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net; > > linux-kernel@vger.kernel.org > > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > > > Hi Chao, > > > > On Mon, Dec 22, 2014 at 03:10:30PM +0800, Chao Yu wrote: > > > Hi Changman, > > > > > > > -Original Message- > > > > From: Changman Lee [mailto:cm224@samsung.com] > > > > Sent: Monday, December 22, 2014 10:03 AM > > > > To: Chao Yu > > > > Cc: Jaegeuk Kim; linux-f2fs-de...@lists.sourceforge.net; > > > > linux-kernel@vger.kernel.org > > > > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > > > > > > > Hi Yu, > > > > > > > > Good approach. > > > > > > Thank you. :) > > > > > > > As you know, however, f2fs breaks extent itself due to COW. > > > > > > Yes, and sometimes f2fs use IPU when override writing, in this condition, > > > by using this approach we can cache more contiguous mapping extent for > > > better > > > performance. > > > > Hmm. When f2fs faces with this case, there is no chance to make an extent > > itself > > at all. > > With new implementation of this patch f2fs will build extent cache when > readpage/readpages. I don't understand your points exactly. :( If there are no on-disk extents, it doesn't matter when the caches are built. Could you define what scenarios you're looking at? > > > > > > > > > > Unlike other filesystem like btrfs, minimum extent of f2fs could have > > > > 4KB granularity. > > > > So we would have lots of extents per inode and it could lead to overhead > > > > to manage extents. > > > > > > Agree, the more number of extents are growing in one inode, the more > > > memory > > > pressure and longer latency operating in rb-tree we are facing. > > > IMO, to solve this problem, we'd better to add limitation or shrink > > > ability into > > > extent cache: > > > 1.limit extent number per inode with the value set from sysfs and discard > > > extent > > > from inode's extent lru list if we touch the limitation; (e.g. in FAT, > > > max number > > > of mapping extent per inode is fixed: 8) > > > 2.add all extents of inodes into a global lru list, we will try to shrink > > > this list > > > if we're facing memory pressure. > > > > > > How do you think? or any better ideas are welcome. :) > > > > Historically, the reason that I added only one small extent cache is that I > > wanted to avoid additional data structures having any overhead in critical > > data > > write path. > > Thank you for telling me the history of original extent cache. > > > Instead, I intended to use a well operating node page cache. > > > > We need to consider what would be the benefit when using extent cache rather > > than existing node page cache. > > IMO, node page cache belongs to system level cache, filesystem sub system can > not control it completely, cached uptodate node page will be invalidated by > using drop_caches from sysfs, or reclaimer of mm, result in more IO when we > need > these node page next time. Yes, that's exactly what I wanted. > New extent cache belongs to filesystem level cache, it is completely > controlled > by filesystem itself. What we can profit is: on the one hand, it is used as > first level cache above the node page cache, which can also increase the cache > hit ratio. I don't think so. The hit ratio depends on the cache policy. The node page cache is managed globally by kernel in LRU manner, so I think this can show affordable hit ratio. > On the other hand, it is more instable and controllable than node page > cache. It depends on how you can control the extent cache. But, I'm not sure that would be better than page cache managed by MM. So, my concerns are: 1. Redundant memory overhead : The extent cache is likely on top of the node page cache, which will consume memory redundantly. 2. CPU overhead : In every block address updates, it needs to traverse extent cache entries. 3. Effectiveness : We have a node page cache that is managed by MM in LRU order. I think this provides good hit ratio, system-wide memory relciaming algorithms, and well- defined locking mechanism. 4. Cache reclaiming policy a. global approach: it needs to consider lock contention, CPU overhead, and shrinker. I don't think it is better than page cache. b. local approach: there still exists cold misses at the initial read operations. After then, how does the extent cache increase hit ratio more than giving node page cache? For example, in the case of pretty normal scenario like open -> read -> close -> open -> read ..., we can't get benefits form locally-managed extent cache, while node
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
Chen, Tiejun wrote: > On 2014/12/23 9:50, Chen, Tiejun wrote: > >On 2014/12/22 17:23, Jamie Heilman wrote: > >>Chen, Tiejun wrote: > >>>On 2014/12/21 20:46, Jamie Heilman wrote: > With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I > get: > > KVM: entry failed, hardware error 0x8021 > >>> > >>>Looks some MSR writing issues such a failed entry. > >>> > If you're running a guest on an Intel machine without unrestricted mode > support, the failure can be most likely due to the guest entering an > invalid > state for Intel VT. For example, the guest maybe running in big real > mode > which is not supported on less recent Intel processors. > > EAX= EBX= ECX= EDX=0663 > ESI= EDI= EBP= ESP= > EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES = 9300 > CS =f000 000f 9b00 > SS = 9300 > DS = 9300 > FS = 9300 > GS = 9300 > LDT= 8200 > TR = 8b00 > GDT= > IDT= > CR0=6010 CR2= CR3= CR4= > DR0= DR1= DR2= > DR3= > DR6=0ff0 DR7=0400 > EFER= > >>> > >>>And I don't see any obvious wrong as well. Any valuable info from dmesg? > >> > >>With the simple qemu command above, on 3.18.1 I see: > >> > >>kern.info: kvm: zapping shadow pages for mmio generation wraparound > >> > >>when I fire up a full guest that's actually useful I get: > >> > >>kern.info: kvm: zapping shadow pages for mmio generation wraparound > >>kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x > >> > >>On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the > >>message I mention above to stderr. Same thing with a stock > >>3.19.0-rc1. Once I apply your patch the simple test command produces > >>the same zapping shadow pages messages as 3.18.1, and a test guest of > >>a Debian Jessie image (w/stock distro kernel) produces the same thing > >>with disabled perfctr wrmsr message. However, it doesn't look like > > > >Sorry I'm not sure if I understood current status. Looks 3.19-rc1 & my > >patch just fix that error above, > > > >KVM: entry failed, hardware error 0x8021 > >... > > > >Right? > > > >>I'm entirely out of the woods, because one of my other guest VMs with a > >>custom kernel that works great under 3.18.1 now fails to run. Nothing > >>in dmesg, but here's the stderr: > > > >But even you revert 34a1cd60d17 or just apply my patch, something else > >introduced between 3.18.1 and 3.19-rc1 led this error below, right? > > > >> > >>KVM internal error. Suberror: 1 > >>emulation failure > >>EAX=000de494 EBX= ECX= EDX=0cfd > >>ESI=0059 EDI= EBP= ESP=6fb4 > >>EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 > >>ES =0010 00c09300 DPL=0 DS [-WA] > >>CS =0008 00c09b00 DPL=0 CS32 [-RA] > >>SS =0010 00c09300 DPL=0 DS [-WA] > >>DS =0010 00c09300 DPL=0 DS [-WA] > >>FS =0010 00c09300 DPL=0 DS [-WA] > >>GS =0010 00c09300 DPL=0 DS [-WA] > >>LDT= 8200 DPL=0 LDT > >>TR = 8b00 DPL=0 TSS32-busy > >>GDT= 000f6be8 0037 > >>IDT= 000f6c26 > >>CR0=6011 CR2= CR3= CR4= > >>DR0= DR1= DR2= > >>DR3= > >>DR6=0ff0 DR7=0400 > >>EFER= > >>Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 <5b> > >>5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 > >>b0 04 e6 21 b0 02 > >> > >>FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are > >>two bugs, maybe there's more to this first one. I can repro this > > > >So if my understanding is correct, this is probably another bug. And > >especially, I already saw the same log in another thread, "Cleaning up > >the KVM clock". Maybe you can continue to `git bisect` to locate that > >bad commit. > > > > Looks just now Andy found that commit, > 0e60b0799fedc495a5c57dbd669de3c10d72edd2 "kvm: change memslot sorting rule > from size to GFN", maybe you can try to revert this to try yours again. That doesn't revert cleanly for me, and I don't have much time to fiddle with it until the 24th---so checked out the commit before it (d4ae84a0), applied your patch, built, and yes, everything works fine at that point. I'll probably have time for another full bisection later, assuming things aren't ironed out already by then.
Re: [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups
On 23/12/2014 01:39, Andy Lutomirski wrote: > This is a dramatic simplification and speedup of the vdso pvclock read > code. Is it correct? > > Andy Lutomirski (2): > x86, vdso: Use asm volatile in __getcpu > x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader Patch 1 is ok, Acked-by: Paolo Bonzini For patch 2 I will defer to Marcelo and Glauber (and the Xen folks). Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch Part2 v6 22/27] x86, uv: Use hierarchy irqdomain to manage UV interrupts
On 2014/12/18 0:45, Russ Anderson wrote:
> On Wed, Dec 17, 2014 at 10:41:51AM +0800, Jiang Liu wrote:
>> On 2014/12/17 1:29, Dimitri Sivanich wrote:
>>> I answered my own question, this had never been tested on UV.
>>>
>>> The gru driver fails with:
>>> SGI GRU Device Driver: uv_setup_irq failed, errno=22
>>>
>>> The info->type in uv_domain_alloc() is not set to X86_IRQ_ALLOC_TYPE_UV
>>> (info->type is never set to that value anywhere).
>>>
>>> Adding the following to uv_setup_irq allows it to work:
>>>
>>> --- linux.orig/arch/x86/platform/uv/uv_irq.c
>>> +++ linux/arch/x86/platform/uv/uv_irq.c
>>> @@ -187,6 +187,7 @@ int uv_setup_irq(char *irq_name, int cpu
>>> return -ENOMEM;
>>>
>>> init_irq_alloc_info(, cpumask_of(cpu));
>>> + info.type = X86_IRQ_ALLOC_TYPE_UV;
>>> info.uv_limit = limit;
>>> info.uv_blade = mmr_blade;
>>> info.uv_offset = mmr_offset;
>>>
>>> On Mon, Dec 15, 2014 at 03:37:35PM -0600, Dimitri Sivanich wrote:
>> Hi Dimitri,
>> Thanks for reporting and fixing this bug. We will rebase the
>> tip/x86/apic branch and fold the above patch into the original patch.
>> May I assume a Tested-by from you? I have no UV systems for testing.
>
> 287 lines of change in uv_irq.c completely untested in linux-next? Ouch.
>
> Dimitri tested the one line change above, because the driver would
> not even load without it. It will take some time to look through
> your extensive changes to understand and verify it works.
Hi Anderson,
The whole patch set has been exposed to linux-next through
tip/x86/apic, but not sure why this bug hasn't been discovered.
Will Cc you and Dimitri next time.
Regards!
Gerry
>
> Thanks.
>
>> Regards!
>> Gerry
>>
Was this patch ever tested on a UV system?
Also, adding some SGI folks to the CC list, since there were none listed
before.
On Tue, Nov 25, 2014 at 01:53:31PM +0800, Jiang Liu wrote:
> Enhance UV code to support hierarchy irqdomain, it helps to make
> the architecture more clear.
>
> We should construct hwirq based on mmr_blade and mmr_offset, but
> mmr_offset is type of unsigned long, it may exceed the range of
> irq_hw_number_t. So help about the way to construct hwirq based
> on mmr_blade and mmr_offset is welcomed!
>
> Signed-off-by: Jiang Liu
> ---
> arch/x86/include/asm/hw_irq.h |9 ++
> arch/x86/platform/uv/uv_irq.c | 287
> -
> 2 files changed, 117 insertions(+), 179 deletions(-)
>
> diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
> index 46dec7e37829..bbf90fe2a224 100644
> --- a/arch/x86/include/asm/hw_irq.h
> +++ b/arch/x86/include/asm/hw_irq.h
> @@ -123,6 +123,7 @@ enum irq_alloc_type {
> X86_IRQ_ALLOC_TYPE_MSI,
> X86_IRQ_ALLOC_TYPE_MSIX,
> X86_IRQ_ALLOC_TYPE_DMAR,
> + X86_IRQ_ALLOC_TYPE_UV,
> };
>
> struct irq_alloc_info {
> @@ -169,6 +170,14 @@ struct irq_alloc_info {
> void*ht_update;
> };
> #endif
> +#ifdef CONFIG_X86_UV
> + struct {
> + int uv_limit;
> + int uv_blade;
> + unsigned long uv_offset;
> + char*uv_name;
> + };
> +#endif
> };
> };
>
> diff --git a/arch/x86/platform/uv/uv_irq.c b/arch/x86/platform/uv/uv_irq.c
> index 474912d03f40..c237ed34a498 100644
> --- a/arch/x86/platform/uv/uv_irq.c
> +++ b/arch/x86/platform/uv/uv_irq.c
> @@ -19,17 +19,31 @@
> #include
>
> /* MMR offset and pnode of hub sourcing interrupts for a given irq */
> -struct uv_irq_2_mmr_pnode{
> - struct rb_node list;
> +struct uv_irq_2_mmr_pnode {
> unsigned long offset;
> int pnode;
> - int irq;
> };
>
> -static DEFINE_SPINLOCK(uv_irq_lock);
> -static struct rb_rootuv_irq_root;
> +static void uv_program_mmr(struct irq_cfg *cfg, struct
> uv_irq_2_mmr_pnode *info)
> +{
> + unsigned long mmr_value;
> + struct uv_IO_APIC_route_entry *entry;
> +
> + BUILD_BUG_ON(sizeof(struct uv_IO_APIC_route_entry) !=
> + sizeof(unsigned long));
> +
> + mmr_value = 0;
> + entry = (struct uv_IO_APIC_route_entry *)_value;
> + entry->vector = cfg->vector;
> + entry->delivery_mode= apic->irq_delivery_mode;
> + entry->dest_mode= apic->irq_dest_mode;
> + entry->polarity = 0;
> + entry->trigger = 0;
> + entry->mask = 0;
> + entry->dest = cfg->dest_apicid;
>
> -static int uv_set_irq_affinity(struct irq_data *, const struct cpumask
> *, bool);
> +
Re: [PATCH] ftracetest: Replace usleep with sleep 0.000001
On Tue, 2014-12-23 at 13:21 +0900, Namhyung Kim wrote: > On Sat, Dec 20, 2014 at 05:07:25PM -0500, Steven Rostedt wrote: > > On Sat, 20 Dec 2014 21:42:13 +0100 > > Pavel Machek wrote: > > > > > On Wed 2014-12-10 15:38:27, Michael Ellerman wrote: > > > > usleep is a Fedoraism, it's not generally available on Debian based > > > > systems AFAICS. > > > > > > > > GNU sleep accepts a floating point argument, so use that instead. > > > > > > > > Signed-off-by: Michael Ellerman > > > > > > Could ftrace user interface be enhanced not to need random delays? > > > > > > > Not sure what you are talking about. These "random delays" are not for > > the interface, but instead to force some events to happen and to make > > sure they did. > > > > As the subject states, this is for "ftracetest" which is the selftests > > for ftrace. > > > > The usleep is basically a "do something to trigger events", and we > > don't want to wait long in doing it. > > Right. AFAIK what ftracetest expects is a scheduler event so it > doesn't need to be the [u]sleep. Would /bin/true work in that case? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH 6/6] f2fs: avoid double lock for cp_rwsem
Hi Jaegeuk, > -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Monday, December 22, 2014 12:35 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Cc: Jaegeuk Kim > Subject: [f2fs-dev] [PATCH 6/6] f2fs: avoid double lock for cp_rwsem > > The __f2fs_add_link is covered by cp_rwsem all the time. > This calls init_inode_metadata, which conducts some acl operations including > memory allocation with GFP_KERNEL previously. > But, under memory pressure, f2fs_write_data_page can be called, which also > grabs cp_mutex too. grabs cp_rwsem. > Basically, it's safe since down_read was used in both of cases, but it'd > better avoid this situation in advance. If checkpoint intend to hold down_write in the middle of the two down_read caller, it will cause a deadlock, so it's not safe. Could you update the comments? > > Signed-off-by: Jaegeuk Kim Anyway, Nice catch and please add: Reviewed-by: Chao Yu > --- > fs/f2fs/acl.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c > index 1ccb26b..7f12d28 100644 > --- a/fs/f2fs/acl.c > +++ b/fs/f2fs/acl.c > @@ -62,7 +62,7 @@ static struct posix_acl *f2fs_acl_from_disk(const char > *value, size_t size) > if (count == 0) > return NULL; > > - acl = posix_acl_alloc(count, GFP_KERNEL); > + acl = posix_acl_alloc(count, GFP_NOFS); > if (!acl) > return ERR_PTR(-ENOMEM); > > @@ -116,7 +116,7 @@ static void *f2fs_acl_to_disk(const struct posix_acl > *acl, size_t *size) > int i; > > f2fs_acl = kmalloc(sizeof(struct f2fs_acl_header) + acl->a_count * > - sizeof(struct f2fs_acl_entry), GFP_KERNEL); > + sizeof(struct f2fs_acl_entry), GFP_NOFS); > if (!f2fs_acl) > return ERR_PTR(-ENOMEM); > > -- > 2.1.1 > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151=/4140/ostg.clktrk > ___ > Linux-f2fs-devel mailing list > linux-f2fs-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH 1/6] f2fs: use f2fs_io_info to clean up messy parameters during IO path
> -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Monday, December 22, 2014 12:35 AM > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Cc: Jaegeuk Kim > Subject: [f2fs-dev] [PATCH 1/6] f2fs: use f2fs_io_info to clean up messy > parameters during IO > path > > This patch cleans up parameters on IO paths. > The key idea is to use f2fs_io_info adding a parameter, block address, and > then > use this structure as parameters. > Nice clean work. > Signed-off-by: Jaegeuk Kim Reviewed-by: Chao Yu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] ipw2200: select CFG80211_WEXT
Paul Bolle writes:
> Commit 24a0aa212ee2 ("cfg80211: make WEXT compatibility unselectable")
> made it impossible to depend on CFG80211_WEXT. It does still allow to
> select that symbol. (Yes, the commit summary is confusing.)
>
> So make IPW2200 select CFG80211_WEXT, so that the ipw2200 driver can be
> built again.
I think the last sentence is a bit misleading (this isn't a compilation
error, right?) and I would like to clarify it like this:
"So make IPW2200 select CFG80211_WEXT, so that the ipw2200 driver can be
enabled in config again."
Does that look ok?
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 3/9] devfreq: event: Add exynos-ppmu devfreq-event driver
Hi Varka,
On 12/23/2014 01:35 PM, Chanwoo Choi wrote:
> On 12/23/2014 12:40 PM, Varka Bhadram wrote:
>> On Tue, Dec 23, 2014 at 8:48 AM, Chanwoo Choi wrote:
>>> This patch adds exynos-ppmu devfreq-event driver to get performance data
>>> of each IP for Samsung Exynos SoC. These event from Exynos PPMU provide
>>> useful information about the behavior of the SoC that you can use when
>>> analyzing system performance, and made visible and can be counted using
>>> logic in each IP.
>>>
>>> This patch is based on existing drivers/devfreq/exynos/exynos-ppmu.c
>>>
>>> Cc: MyungJoo Ham
>>> Cc: Kyungmin Park
>>> Signed-off-by: Chanwoo Choi
>>
snip.
>
>>
>>> + }
>>> +
>>> + data->clk_ppmu = devm_clk_get(dev, "ppmu");
>>> + if (IS_ERR(data->clk_ppmu)) {
>>> + data->clk_ppmu = NULL;
>>> + dev_warn(dev, "failed to get PPMU clock\n");
>>> + }
>> If PPMU clk get fails..? return PTR_ERR(data->clk_ppmu)
>
> If Exynos SoC don't register the clock to clock tree, the clock remains on
> state.
> So, I print just warning message.
>
> But, It is not proper. I'll fix it.
I faced on unthinkable issue. I'm implementing missing PPMU clock of Exynos3250
(PPMUDMC0, PPMUDMC1, PPMUFSYS).
But, I can't find the parent clock of PPMUDMC0, PPMUDMC1 and the clock of
PPMUFSYS on Exynos3250 datasheet.
Like this, some PPMU clocks is not specified on Exynos SoC datasheet because
some clocks should be remained
with always-on state.
So, I want to show just warning message if exynos-ppmu driver fail to get ppmu
clock.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: gadget: udc-core: call udc_stop() before gadget unbind
Hi Felipe, On 12/22/2014 05:34 PM, Felipe Balbi wrote: > On Mon, Dec 15, 2014 at 11:05:22AM +0100, Robert Baldyga wrote: >> On 12/15/2014 06:13 AM, Peter Chen wrote: >>> On Fri, Dec 12, 2014 at 02:17:28PM +0100, Robert Baldyga wrote: As usb function drivers assumes that all usb request will be completed before function unbind call, we should supply such behavior. In some cases ep_disable() won't kill all request effectively, because some IN requests can be in running state. In such situation it's possible to have unbind function called before last request completion, which can cause problems. >>> >>> Doesn't the function's disable/unbind should call usb_ep_dequeue to make >>> sure the transfer has ended? >> >> USB function drivers like ECM or HID surely doesn't. It looks like >> there's assumption that all requests will be completed by UDC driver. > > that's a bug on those drivers :-) So we can't make assumptions that requests will be completed in ep_disable()? > >> Function ep_disable() should complete requests in hardware driver, but >> at least in DWC2 driver not all requests are completed at this stage > > and that's a bug on dwc2 :-) I have already found that out. Another UDC drivers simply kill all request without waiting for currently running, so I did the same in DWC2. Here is my patch: http://www.spinics.net/lists/linux-usb/msg118698.html > >> (request which are in hardware FIFO are omitted to give them chance to >> be transferred). Those requests are forced to complete in udc_stop() > > that's wrong, we're disabling the endpoint anyway. Either dwc2 needs to > wait_for_completion() or forcibly cancel the request. The bottom line is > that control should not exit ep_disable() until all requests have been > quiesced. So that's not bug in function drivers. They make correct assumption, because they expect that requests will be completed in ep_disable(). > >> function, and that's why it's needed to be called before unbind. >> >>> >>> .udc_stop may stop the controller, and .unbind may still visit hardware. >> >> Hmm, indeed it can be problem. > > yes, it will be :-) > Thanks, Robert Baldyga -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: missing merge fix for the access_once tree
Hi Linus, On Mon, 22 Dec 2014 20:12:22 -0800 Linus Torvalds wrote: > > On Mon, Dec 22, 2014 at 6:17 PM, Stephen Rothwell > wrote: > > > > I have been carrying this merge fix patch for some time. It should > > have gone into the merge of the access_once tree. > > No, you had a different tree that got merged into linux-next, that > made it an error to do ACCESS_ONCE() on a structure. > > The thing I merged didn't actually have that final commit, exactly so > that things wouldn't break from missing conversions. > > So that patch isn't wrong, but it also isn't exactly a required fix > until the next merge window.. True, so "should" was a bit strong. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpdgSHY613FI.pgp Description: OpenPGP digital signature
Re: linux-next: missing merge fix patch for the merge of the xen-tip tree with the arm-soc tree
Hi Linus, On Mon, 22 Dec 2014 20:09:50 -0800 Linus Torvalds wrote: > > On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell > wrote: > > Hi Linus, > > > > I have been carrying this merge fix patch for some time that is now > > needed in your tree: > > No, it's not. Look more closely. > > My merge put the > > dev->archdata.dma_coherent = coherent; > > line at the top of the function, like the way it was in the original commit. Oops, sorry about that. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpY58O4hgSZr.pgp Description: OpenPGP digital signature
[PATCH] perf core: Use KSTK_ESP() instead of pt_regs->sp while output user regs
From: Chenggang Qin For x86_64, the exact value of user stack's esp should be got by KSTK_ESP(current). current->thread.usersp is copied from PDA while enter ring0. Now, we output the value of sp from pt_regs. But pt_regs->sp has changed before it was pushed into kernel stack. So, we cannot get the correct callchain while unwind some user stacks. For example, if the stack contains __lll_unlock_wake()/__lll_lock_wait(), the callchain will break some times with the latest version of libunwind. The root cause is the sp that is used by libunwind may be wrong. If we use KSTK_ESP(current), the correct callchain can be got everytime. Other architectures also have KSTK_ESP() macro. Signed-off-by: Chenggang Qin Cc: Andrew Morton Cc: Arjan van de Ven Cc: David Ahern Cc: Ingo Molnar Cc: Mike Galbraith Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Wu Fengguang Cc: Yanmin Zhang --- arch/x86/kernel/perf_regs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c index e309cc5..5da8df8 100644 --- a/arch/x86/kernel/perf_regs.c +++ b/arch/x86/kernel/perf_regs.c @@ -60,6 +60,9 @@ u64 perf_reg_value(struct pt_regs *regs, int idx) if (WARN_ON_ONCE(idx >= ARRAY_SIZE(pt_regs_offset))) return 0; + if (idx == PERF_REG_X86_SP) + return KSTK_ESP(current); + return regs_get_register(regs, pt_regs_offset[idx]); } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] OHCI: add a quirk for ULi M5237 blocking on reset
23.12.2014 08:36, Arseny Solokha пишет:
>> On Sat, 6 Dec 2014, Arseny Solokha wrote:
>>
>>> From: Arseny Solokha
>>>
>>> Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
>>> introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
>>> board. The code path that was previously specific to NVIDIA controllers
>>> had then become taken for all chips.
>>>
>>> However, the M5237 installed on the board wedges solid when accessing
>>> its base+OHCI_FMINTERVAL register, making it impossible to boot any
>>> kernel newer than 3.1.8 on this particular and apparently other similar
>>> machines.
>>>
>>> Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.
>>>
>>> The patch is suitable for the -next tree as well as all maintained
>>> kernels up to 3.2 inclusive.
>>>
>>> Signed-off-by: Arseny Solokha
>>> ---
>>> Changes in v2:
>>> - review comments applied
>>
>> Much better this time.
>>
>> Acked-by: Alan Stern
>
> Meanwhile, I discovered a similar thread where the issue was previously
> discussed, and have tried to implement a workaround suggested in [1]. No luck
> so
> far: even if the code manages to check a value returned by
> readl(base + OHCI_FMINTERVAL), it then still hangs during device
> unregistering.
>
> Of course, unregistering a device instead of just not accessing
> OHCI_FMINTERVAL
> like in my or Nikita's patch is also possible but it requires hardcoding all
> flawed device IDs instead of figuring out misbehaving devices at boot time.
In my case root cause was elsewhere - USB port that I thought was driven
by ULI, actually was not. And ULI's builtin OHCI was not
hardware-enabled (but still was available on bus). I workarounded it by
masking entire device in platform-specific quirk.
Nikita
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: cleanup align switch and case
On Tue, Dec 23, 2014 at 07:38:04AM +0300, samuel kihahu wrote: > On Mon, Dec 22, 2014 at 01:18:01PM -0800, Greg KH wrote: > > On Mon, Dec 22, 2014 at 11:48:57PM +0300, samuel kihahu wrote: > > > From: skihahu > > > > > > Align switch and case to be at the same indent. > > > > > > Signed-off-by: samuel kihahu > > > > The "From:" and "Signed-off-by:" names don't match, which doesn't make > > much sense, right? Please fix and resend. > > > > I have corrected as requested above. > >From 766dd7eefe8992b90dc69cca085e6719019aae82 Mon Sep 17 00:00:00 2001 > From: samuel kihahu > Date: Mon, 22 Dec 2014 18:16:29 +0300 > Subject: [PATCH] staging: lustre: cleanup align switch and case > > Align switch and case to be at the same indent. > > Signed-off-by: samuel kihahu > --- > drivers/staging/lustre/lnet/selftest/module.c | 50 > +-- > 1 file changed, 25 insertions(+), 25 deletions(-) But this isn't in a form I can apply, please resend in a format I don't have to hand-edit the email. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a white space coding style problem
On Tue, Dec 23, 2014 at 05:10:28AM +, Kroderia wrote: > Signed-off-by: Kroderia I doubt that is the name you sign legal documents with, right? Please fix that up, and give a much better subject: and body of the changelog for what you are doing. Look at the archives for how to properly do this. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
On Mon, 2014-12-22 at 18:44 -0800, Geoff Levand wrote: > Hi Michael, > > On Tue, 2014-12-23 at 11:26 +1100, Michael Ellerman wrote: > > On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote: > > > ps3_repository_write_highmem_info() is needed by otheros++. What we > > > need is a kernel patch to add the highmem info to the repository once it > > > is known. > > > > OK so where's that patch? > > I put one in my ps3-linux repo. I'll post it after I do some more > testing. Great, thanks. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[LKP] [tracing] 0184d50f9fd:
FYI, we noticed the below changes on
commit 0184d50f9fd17658c232d6ee6d465a87f989d706 ("tracing: Fix bad parameter
passed in branch selftest")
The kernel Oops before is fixed, but there are still some warning in dmesg as
follow, just FYI.
[1.676055] Switching to clocksource kvm-clock
[1.679154] Warning: could not register all branches stats
[1.679154] Warning: could not register annotated branches stats
[1.750323] pnp: PnP ACPI init
[1.750960] ACPI: bus type PNP registered
[1.751697] IOAPIC[0]: Set routing entry (0-8 -> 0x38 -> IRQ 8 Mode:0
Active:0 Dest:1)
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
---
testcase: boot
default_monitors:
boottime:
kernel-size:
default_watchdogs:
watch-oom:
watchdog:
cpufreq_governor:
model: qemu-system-x86_64 -enable-kvm -cpu Westmere
nr_vm: 32
nr_cpu: 1
memory: 320M
rootfs: yocto-minimal-i386.cgz
swap_partitions: "/dev/vda"
boot-meminfo:
boot-slabinfo:
boot-memory:
memmap:
bootmem:
sleep: 1
branch: jtkirshe-net/i40e-queue
commit: 4f79861e82847a49fe000937d64a0fdb228ed536
repeat_to: 2
testbox: vm-kbuild-yocto-ia32-21
tbox_group: vm-kbuild-yocto-ia32
kconfig: x86_64-randconfig-ib0-12210359
enqueue_time: 2014-12-21 04:53:14.814672441 +08:00
kernel:
"/kernel/x86_64-randconfig-ib0-12210359/4f79861e82847a49fe000937d64a0fdb228ed536/vmlinuz-3.18.0"
user: lkp
queue: rand
result_root:
"/result/vm-kbuild-yocto-ia32/boot/1/yocto-minimal-i386.cgz/x86_64-randconfig-ib0-12210359/4f79861e82847a49fe000937d64a0fdb228ed536/0"
job_file:
"/lkp/scheduled/vm-kbuild-yocto-ia32-21/rand_boot-1-yocto-minimal-i386.cgz-x86_64-randconfig-ib0-12210359-4f79861e82847a49fe000937d64a0fdb228ed536-1.yaml"
dequeue_time: 2014-12-21 04:53:25.984733245 +08:00
job_state: finished
___
LKP mailing list
l...@linux.intel.com
early console in setup code
Probing EDD (edd=off to disable)... ok
[0.00] Linux version 3.10.0-rc1-00010-g0184d50 (kbuild@lkp-ib04) (gcc
version 4.9.1 (Debian 4.9.1-19) ) #5 SMP Sun Dec 21 09:47:53 CST 2014
[0.00] Command line: user=lkp
job=/lkp/scheduled/vm-kbuild-yocto-ia32-15/bisect_boot-1-yocto-minimal-i386.cgz-x86_64-randconfig-ib0-12210359-0184d50f9fd17658c232d6ee6d465a87f989d706-1.yaml
ARCH=x86_64
BOOT_IMAGE=/kernel/x86_64-randconfig-ib0-12210359/0184d50f9fd17658c232d6ee6d465a87f989d706/vmlinuz-3.10.0-rc1-00010-g0184d50
kconfig=x86_64-randconfig-ib0-12210359
commit=0184d50f9fd17658c232d6ee6d465a87f989d706 branch=jtkirshe-net/i40e-queue
root=/dev/ram0 max_uptime=3600
RESULT_ROOT=/result/vm-kbuild-yocto-ia32/boot/1/yocto-minimal-i386.cgz/x86_64-randconfig-ib0-12210359/0184d50f9fd17658c232d6ee6d465a87f989d706/4
ip=vm-kbuild-yocto-ia32-15::dhcp earlyprintk=ttyS0,115200 debug apic=debug
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw
drbd.minor_count=8
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x13ffdfff] usable
[0.00] BIOS-e820: [mem 0x13ffe000-0x13ff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: Bochs Bochs, BIOS Bochs 01/01/2011
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x13ffe max_arch_pfn = 0x4
[0.00] Base memory trampoline at [88099000] 99000 size 24576
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00] [mem 0x-0x000f] page 4k
[0.00] BRK [0x03758000, 0x03758fff] PGTABLE
[0.00] BRK [0x03759000, 0x03759fff] PGTABLE
[0.00] BRK [0x0375a000, 0x0375afff] PGTABLE
[0.00] init_memory_mapping: [mem 0x12c0-0x12df]
[0.00] [mem 0x12c0-0x12df] page 4k
[0.00] BRK [0x0375b000, 0x0375bfff] PGTABLE
[0.00] init_memory_mapping: [mem 0x1000-0x12bf]
[0.00] [mem 0x1000-0x12bf] page 4k
[0.00] BRK [0x0375c000, 0x0375cfff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0010-0x0fff]
[0.00] [mem 0x0010-0x0fff] page 4k
[
[PATCH 4/5] hwrng: core - Drop current rng in set_current_rng
Rather than having callers of set_current_rng call drop_current_rng,
we can do it directly in set_current_rng.
Signed-off-by: Herbert Xu
---
drivers/char/hw_random/core.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 1d342f0..787ef42 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -70,6 +70,7 @@ module_param(default_quality, ushort, 0644);
MODULE_PARM_DESC(default_quality,
"default entropy content of hwrng per mill");
+static void drop_current_rng(void);
static void start_khwrngd(void);
static inline int rng_get_data(struct hwrng *rng, u8 *buffer, size_t size,
@@ -105,6 +106,7 @@ static inline void cleanup_rng(struct kref *kref)
static void set_current_rng(struct hwrng *rng)
{
BUG_ON(!mutex_is_locked(_mutex));
+ drop_current_rng();
current_rng = rng;
}
@@ -315,7 +317,6 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
err = hwrng_init(rng);
if (err)
break;
- drop_current_rng();
set_current_rng(rng);
err = 0;
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] hwrng: core - Fix current_rng init/cleanup race yet again
The kref solution is still buggy because we were only focusing
on the register/unregister race. The same race affects the
setting of current_rng through sysfs.
This patch fixes it by using kref_get_unless_zero.
Signed-off-by: Herbert Xu
---
drivers/char/hw_random/core.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 3dba2cf..42827fd 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -105,7 +105,6 @@ static inline void cleanup_rng(struct kref *kref)
static void set_current_rng(struct hwrng *rng)
{
BUG_ON(!mutex_is_locked(_mutex));
- kref_get(>ref);
current_rng = rng;
}
@@ -150,6 +149,9 @@ static void put_rng(struct hwrng *rng)
static inline int hwrng_init(struct hwrng *rng)
{
+ if (kref_get_unless_zero(>ref))
+ goto skip_init;
+
if (rng->init) {
int ret;
@@ -157,6 +159,11 @@ static inline int hwrng_init(struct hwrng *rng)
if (ret)
return ret;
}
+
+ kref_init(>ref);
+ reinit_completion(>cleanup_done);
+
+skip_init:
add_early_randomness(rng);
current_quality = rng->quality ? : default_quality;
@@ -467,6 +474,9 @@ int hwrng_register(struct hwrng *rng)
goto out_unlock;
}
+ init_completion(>cleanup_done);
+ complete(>cleanup_done);
+
old_rng = current_rng;
err = 0;
if (!old_rng) {
@@ -494,8 +504,6 @@ int hwrng_register(struct hwrng *rng)
add_early_randomness(rng);
}
- init_completion(>cleanup_done);
-
out_unlock:
mutex_unlock(_mutex);
out:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] hwrng: core - Do not register device opportunistically
Currently we only register the device when a valid RNG is added.
However the way it's done is buggy because we test whether there
is a current RNG to determine whether we need to register. As
the current RNG may be missing due to a reinitialisation error
this can lead to a reregistration of the device.
As the device already has to handle a NULL current RNG anyway,
let's just register the device always and remove the complexity.
Signed-off-by: Herbert Xu
---
drivers/char/hw_random/core.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 42827fd..1d342f0 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -372,14 +372,14 @@ static DEVICE_ATTR(rng_available, S_IRUGO,
NULL);
-static void unregister_miscdev(void)
+static void __exit unregister_miscdev(void)
{
device_remove_file(rng_miscdev.this_device, _attr_rng_available);
device_remove_file(rng_miscdev.this_device, _attr_rng_current);
misc_deregister(_miscdev);
}
-static int register_miscdev(void)
+static int __init register_miscdev(void)
{
int err;
@@ -484,12 +484,6 @@ int hwrng_register(struct hwrng *rng)
if (err)
goto out_unlock;
set_current_rng(rng);
-
- err = register_miscdev();
- if (err) {
- drop_current_rng();
- goto out_unlock;
- }
}
list_add_tail(>list, _list);
@@ -530,7 +524,6 @@ void hwrng_unregister(struct hwrng *rng)
if (list_empty(_list)) {
mutex_unlock(_mutex);
- unregister_miscdev();
if (hwrng_fill)
kthread_stop(hwrng_fill);
} else
@@ -540,16 +533,24 @@ void hwrng_unregister(struct hwrng *rng)
}
EXPORT_SYMBOL_GPL(hwrng_unregister);
-static void __exit hwrng_exit(void)
+static int __init hwrng_modinit(void)
+{
+ return register_miscdev();
+}
+
+static void __exit hwrng_modexit(void)
{
mutex_lock(_mutex);
BUG_ON(current_rng);
kfree(rng_buffer);
kfree(rng_fillbuf);
mutex_unlock(_mutex);
+
+ unregister_miscdev();
}
-module_exit(hwrng_exit);
+module_init(hwrng_modinit);
+module_exit(hwrng_modexit);
MODULE_DESCRIPTION("H/W Random Number Generator (RNG) driver");
MODULE_LICENSE("GPL");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [drm/fb] 6cadd306033:
FYI, similar information for 4a91ebc4ec70e83a2fbca622653da22bf8afda7b
too.
Best Regards,
Huang, Ying
On Tue, 2014-12-23 at 13:40 +0800, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit 6cadd306033e70b4edb136815807060e168cac67 ("drm/fb-helper: Propagate
> errors from initial config failure")
>
>
> testbox/testcase/testparams: vm-kbuild-yocto-ia32/boot/1
>
> drm-intel/topic/ 6cadd306033e70b4edb1368158
> --
>fail:runs %reproductionfail:runs
>| | |
>:10 100% 10:10
> kmsg.drm:cirrus_modeset_init]*ERROR*cirrus_fbdev_init_failed
>:10 100% 10:10
> kmsg.cirrus#:#:#:Fatal_error_during_modeset_init
> 1:10 -10%:10
> kmsg.Initramfs_unpacking_failed:junk_in_compressed_archive
> 1:10 -10%:10kmsg.BUG:kernel_boot_hang
> 1:10 -10%:10dmesg.Initramfs_unpacking_failed
> 1:10 -10%:10dmesg.BUG:kernel_boot_hang
>:2 50% 1:2 kmsg.BUG:kernel_test_crashed
>:2 100% 2:2
> kmsg.APIC_calibration_not_consistent_with_PM-Timer:#ms_instead_of#ms
>:2 50% 1:2
> kmsg.i6300esb:Unexpected_close,not_stopping_watchdog
>:2 50% 1:2 dmesg.BUG:kernel_test_crashed
>
> vm-kbuild-yocto-ia32: qemu-system-x86_64 -enable-kvm -cpu Westmere
> Memory: 320M
>
>
> To reproduce:
>
> apt-get install ruby ruby-oj
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
> cd lkp-tests
> bin/setup-local job.yaml # the job file attached in this email
> bin/run-local job.yaml
>
>
> Disclaimer:
> Results have been estimated based on internal Intel analysis and are provided
> for informational purposes only. Any difference in system hardware or software
> design or configuration may affect actual performance.
>
>
> Thanks,
> Huang, Ying
>
> ___
> LKP mailing list
> l...@linux.intel.com
> ___ LKP mailing list
> l...@lists.01.org https://lists.01.org/mailman/listinfo/lkp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[LKP] [drm/fb] 6cadd306033:
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 6cadd306033e70b4edb136815807060e168cac67 ("drm/fb-helper: Propagate
errors from initial config failure")
testbox/testcase/testparams: vm-kbuild-yocto-ia32/boot/1
drm-intel/topic/ 6cadd306033e70b4edb1368158
--
fail:runs %reproductionfail:runs
| | |
:10 100% 10:10
kmsg.drm:cirrus_modeset_init]*ERROR*cirrus_fbdev_init_failed
:10 100% 10:10
kmsg.cirrus#:#:#:Fatal_error_during_modeset_init
1:10 -10%:10
kmsg.Initramfs_unpacking_failed:junk_in_compressed_archive
1:10 -10%:10kmsg.BUG:kernel_boot_hang
1:10 -10%:10dmesg.Initramfs_unpacking_failed
1:10 -10%:10dmesg.BUG:kernel_boot_hang
:2 50% 1:2 kmsg.BUG:kernel_test_crashed
:2 100% 2:2
kmsg.APIC_calibration_not_consistent_with_PM-Timer:#ms_instead_of#ms
:2 50% 1:2
kmsg.i6300esb:Unexpected_close,not_stopping_watchdog
:2 50% 1:2 dmesg.BUG:kernel_test_crashed
vm-kbuild-yocto-ia32: qemu-system-x86_64 -enable-kvm -cpu Westmere
Memory: 320M
To reproduce:
apt-get install ruby ruby-oj
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
---
testcase: boot
default_monitors:
boottime:
kernel-size:
default_watchdogs:
watch-oom:
watchdog:
cpufreq_governor:
model: qemu-system-x86_64 -enable-kvm -cpu Westmere
nr_vm: 32
nr_cpu: 1
memory: 320M
rootfs: yocto-minimal-i386.cgz
swap_partitions: "/dev/vda"
boot-meminfo:
boot-slabinfo:
boot-memory:
memmap:
bootmem:
sleep: 1
branch: linux-devel/devel-athens-smoke-201412202308
commit: 2c89ae63e7c992890e6d206c5918dad78e3f118e
repeat_to: 2
testbox: vm-kbuild-yocto-ia32-11
tbox_group: vm-kbuild-yocto-ia32
kconfig: x86_64-randconfig-a1-12202258
enqueue_time: 2014-12-20 23:17:59.043453185 +08:00
kernel:
"/kernel/x86_64-randconfig-a1-12202258/2c89ae63e7c992890e6d206c5918dad78e3f118e/vmlinuz-3.18.0-g2c89ae6"
user: lkp
queue: rand
result_root:
"/result/vm-kbuild-yocto-ia32/boot/1/yocto-minimal-i386.cgz/x86_64-randconfig-a1-12202258/2c89ae63e7c992890e6d206c5918dad78e3f118e/0"
job_file:
"/lkp/scheduled/vm-kbuild-yocto-ia32-11/rand_boot-1-yocto-minimal-i386.cgz-x86_64-randconfig-a1-12202258-2c89ae63e7c992890e6d206c5918dad78e3f118e-1.yaml"
dequeue_time: 2014-12-20 23:18:14.727622240 +08:00
job_state: finished
___
LKP mailing list
l...@linux.intel.com
early console in setup code
early console in decompress_kernel
KASLR using RDTSC...
Decompressing Linux... Parsing ELF... Performing relocations... done.
Booting the kernel.
[0.00] Linux version 3.18.0-rc4-00653-g6cadd30 (kbuild@athens) (gcc
version 4.9.1 (Debian 4.9.1-19) ) #14 SMP Sun Dec 21 01:51:20 CST 2014
[0.00] Command line: user=lkp
job=/lkp/scheduled/vm-kbuild-yocto-ia32-17/validate_boot-1-yocto-minimal-i386.cgz-x86_64-randconfig-a1-12202258-6cadd306033e70b4edb136815807060e168cac67-9.yaml
ARCH=x86_64
BOOT_IMAGE=/kernel/x86_64-randconfig-a1-12202258/6cadd306033e70b4edb136815807060e168cac67/vmlinuz-3.18.0-rc4-00653-g6cadd30
kconfig=x86_64-randconfig-a1-12202258
commit=6cadd306033e70b4edb136815807060e168cac67
branch=linux-devel/devel-athens-smoke-201412202308 root=/dev/ram0
max_uptime=3600
RESULT_ROOT=/result/vm-kbuild-yocto-ia32/boot/1/yocto-minimal-i386.cgz/x86_64-randconfig-a1-12202258/6cadd306033e70b4edb136815807060e168cac67/5
ip=vm-kbuild-yocto-ia32-17::dhcp earlyprintk=ttyS0,115200 debug apic=debug
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw
drbd.minor_count=8
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x13ffdfff] usable
[0.00] BIOS-e820: [mem 0x13ffe000-0x13ff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00]
RE: [DISCUSSION] USB device remote wakeup is not working for S3 case
> You have to make sure that wakeup is also enabled for the host > controller the device is attached to. For some host controllers, it > may also be necessary to enable wakeup for the root hub. > Yes, the root-hub is not wakeup enabled by default, actually hub devices are not enabled. It works after I enable it via sysfs interface. > > Could we also enable wakeup for usb mouse? Or is there any concern to > enable it? > > Per my opinion, most people may expect clicking mouse can awake system. > > It doesn't matter to me, but you should ask the people on the > linux-input mailing list. > > Also, what about wakeup for a non-USB mouse? Shouldn't that be enabled > as well? Unfortunately the mouse I found are all of usb so cannot confirm it. The concern is if we want usb keyboard/mouse wakeup work by default, it does make sense only if the parent hubs are also enabled by default. This is a policy issue and may be better place it on userspace. I have no better idea :) . > > Alan Stern Regards Du, Changbin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] hwrng: core - Use struct completion for cleanup_done
There is no point in doing a manual completion for cleanup_done
when struct completion fits in perfectly.
Signed-off-by: Herbert Xu
---
drivers/char/hw_random/core.c | 12 +++-
include/linux/hw_random.h |3 ++-
2 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 6ec4225..3dba2cf 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -60,7 +60,6 @@ static DEFINE_MUTEX(rng_mutex);
static DEFINE_MUTEX(reading_mutex);
static int data_avail;
static u8 *rng_buffer, *rng_fillbuf;
-static DECLARE_WAIT_QUEUE_HEAD(rng_done);
static unsigned short current_quality;
static unsigned short default_quality; /* = 0; default to "off" */
@@ -100,10 +99,7 @@ static inline void cleanup_rng(struct kref *kref)
if (rng->cleanup)
rng->cleanup(rng);
- /* cleanup_done should be updated after cleanup finishes */
- smp_wmb();
- rng->cleanup_done = true;
- wake_up_all(_done);
+ complete(>cleanup_done);
}
static void set_current_rng(struct hwrng *rng)
@@ -498,7 +494,7 @@ int hwrng_register(struct hwrng *rng)
add_early_randomness(rng);
}
- rng->cleanup_done = false;
+ init_completion(>cleanup_done);
out_unlock:
mutex_unlock(_mutex);
@@ -532,9 +528,7 @@ void hwrng_unregister(struct hwrng *rng)
} else
mutex_unlock(_mutex);
- /* Just in case rng is reading right now, wait. */
- wait_event(rng_done, rng->cleanup_done &&
- atomic_read(>ref.refcount) == 0);
+ wait_for_completion(>cleanup_done);
}
EXPORT_SYMBOL_GPL(hwrng_unregister);
diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
index 7832e50..eb7b414 100644
--- a/include/linux/hw_random.h
+++ b/include/linux/hw_random.h
@@ -12,6 +12,7 @@
#ifndef LINUX_HWRANDOM_H_
#define LINUX_HWRANDOM_H_
+#include
#include
#include
#include
@@ -46,7 +47,7 @@ struct hwrng {
/* internal. */
struct list_head list;
struct kref ref;
- bool cleanup_done;
+ struct completion cleanup_done;
};
/** Register a new Hardware Random Number Generator driver. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] hwrng: core - Move hwrng_init call into set_current_rng
We always do hwrng_init in set_current_rng. In fact, our current
reference count system relies on this. So make this explicit by
moving hwrng_init into set_current_rng.
Signed-off-by: Herbert Xu
---
drivers/char/hw_random/core.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 787ef42..32a8a86 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -71,6 +71,7 @@ MODULE_PARM_DESC(default_quality,
"default entropy content of hwrng per mill");
static void drop_current_rng(void);
+static int hwrng_init(struct hwrng *rng);
static void start_khwrngd(void);
static inline int rng_get_data(struct hwrng *rng, u8 *buffer, size_t size,
@@ -103,11 +104,20 @@ static inline void cleanup_rng(struct kref *kref)
complete(>cleanup_done);
}
-static void set_current_rng(struct hwrng *rng)
+static int set_current_rng(struct hwrng *rng)
{
+ int err;
+
BUG_ON(!mutex_is_locked(_mutex));
+
+ err = hwrng_init(rng);
+ if (err)
+ return err;
+
drop_current_rng();
current_rng = rng;
+
+ return 0;
}
static void drop_current_rng(void)
@@ -149,7 +159,7 @@ static void put_rng(struct hwrng *rng)
mutex_unlock(_mutex);
}
-static inline int hwrng_init(struct hwrng *rng)
+static int hwrng_init(struct hwrng *rng)
{
if (kref_get_unless_zero(>ref))
goto skip_init;
@@ -310,15 +320,9 @@ static ssize_t hwrng_attr_current_store(struct device *dev,
err = -ENODEV;
list_for_each_entry(rng, _list, list) {
if (strcmp(rng->name, buf) == 0) {
- if (rng == current_rng) {
- err = 0;
- break;
- }
- err = hwrng_init(rng);
- if (err)
- break;
- set_current_rng(rng);
err = 0;
+ if (rng != current_rng)
+ err = set_current_rng(rng);
break;
}
}
@@ -481,10 +485,9 @@ int hwrng_register(struct hwrng *rng)
old_rng = current_rng;
err = 0;
if (!old_rng) {
- err = hwrng_init(rng);
+ err = set_current_rng(rng);
if (err)
goto out_unlock;
- set_current_rng(rng);
}
list_add_tail(>list, _list);
@@ -518,8 +521,7 @@ void hwrng_unregister(struct hwrng *rng)
tail = list_entry(rng_list.prev, struct hwrng, list);
- if (hwrng_init(tail) == 0)
- set_current_rng(tail);
+ set_current_rng(tail);
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[0/5] hwrng: Fix kref warning and underlying bugs
On Mon, Dec 22, 2014 at 07:09:56PM -0800, Fengguang Wu wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is Sigh, looks like more work is needed on this. Here is a series of patches that should fix this along with the underlying issue exposed by it and some other related problems. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] OHCI: add a quirk for ULi M5237 blocking on reset
> On Sat, 6 Dec 2014, Arseny Solokha wrote:
>
>> From: Arseny Solokha
>>
>> Commit 8dccddbc2368 ("OHCI: final fix for NVIDIA problems (I hope)")
>> introduced into 3.1.9 broke boot on e.g. Freescale P2020DS development
>> board. The code path that was previously specific to NVIDIA controllers
>> had then become taken for all chips.
>>
>> However, the M5237 installed on the board wedges solid when accessing
>> its base+OHCI_FMINTERVAL register, making it impossible to boot any
>> kernel newer than 3.1.8 on this particular and apparently other similar
>> machines.
>>
>> Don't readl() and writel() base+OHCI_FMINTERVAL on PCI ID 10b9:5237.
>>
>> The patch is suitable for the -next tree as well as all maintained
>> kernels up to 3.2 inclusive.
>>
>> Signed-off-by: Arseny Solokha
>> ---
>> Changes in v2:
>> - review comments applied
>
> Much better this time.
>
> Acked-by: Alan Stern
Meanwhile, I discovered a similar thread where the issue was previously
discussed, and have tried to implement a workaround suggested in [1]. No luck so
far: even if the code manages to check a value returned by
readl(base + OHCI_FMINTERVAL), it then still hangs during device unregistering.
Of course, unregistering a device instead of just not accessing OHCI_FMINTERVAL
like in my or Nikita's patch is also possible but it requires hardcoding all
flawed device IDs instead of figuring out misbehaving devices at boot time.
[1] https://lkml.org/lkml/2014/5/29/828
Arsény
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] TTY: add support for "tty slave" devices.
On Sun, 21 Dec 2014 11:20:19 +0100 Sebastian Reichel wrote:
> Hi Neil,
>
> On Sat, Dec 20, 2014 at 11:09:20AM +1100, NeilBrown wrote:
> > A "tty slave" is a device connected via UART.
> > It may need a driver to, for example, power the device on
> > when the tty is opened, and power it off when the tty
> > is released.
>
> How about (reads a bit easier to me, but I'm not a
> native speaker):
>
> Such a device may need its own driver, e.g. for powering
> it up on tty open and powering it down on tty release.
Yes, that does read better - thanks.
>
> > A "tty slave" is a platform device which is declared as a
> > child of the uart in device-tree:
>
> maybe make this into its own device class instead of making
> it a platform device?
Did you mean "class" or "bus"?? or "type". I'm going to have to figure out
exactly what role each of those has.
In any case, the real question is "why?". Where is the gain?
>
> > {
> > bluetooth {
> > compatible = "wi2wi,w2cbw003";
> > vdd-supply = <>;
> > };
> > };
> >
> > The driver can attach to the tty by calling
> >tty_set_slave(dev->parent, dev, _ops);
>
> this could be handled by the tty core if a custom tty slave device
> class is used (similar to spi_device for spi slaves or i2c_client
> for i2c slaves).
spi_device seems to be a 'bus' device - spi_bus_type.
i2_client is also a 'bus' device - i2c_bus_type. But there is also an
i2c_client_type.
Having a specific bus type (rather than the more generic 'platform') allows
these drivers to use the functionality of the bus to access the device.
e.g. the probe function of an i2c device gets a 'struct i2c_client' handle to
send commands to the device.
But that is not the functionality that my 'tty slave' needs. The driver
doesn't want to access the bus (the parent) - rather we need to arrange for
the parent (the uart/tty) to access the slave driver.
i.e. even if we had a 'serial bus', we would still need to register some
call-backs with the parent. I don't see that the 'bus' model provides any
particular simplified way to do this.
If there were a 'tty_client' bus type, I would expect it to behave a lot like
the current "line disciplines". They use the tty as a bus to provide a
higher-level channel to a specific uart attached device such as an hci
interface to a bluetooth module.
I has occasionally been suggested that the functionality I want should be
implemented as a line discipline. As I understand it, the line discipline
cannot be imposed until you open the device, which make it too late for me...
Note that I'm not convinced that I have the model correct - I just don't see
how the change you suggest would be an improvement.
>
> > where slave_ops' is a set of interface that
> > the tty layer must call when appropriate.
> > Currently only 'open' and 'release' are defined.
> > They are called at first open and last close.
> > They cannot fail.
> >
> > Signed-off-by: NeilBrown
> > ---
> > .../devicetree/bindings/serial/of-serial.txt |4 +
> > drivers/tty/tty_io.c | 73
> > +++-
> > include/linux/tty.h| 16
> > 3 files changed, 90 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt
> > b/Documentation/devicetree/bindings/serial/of-serial.txt
> > index 8c4fd0332028..fc5d00c3c474 100644
> > --- a/Documentation/devicetree/bindings/serial/of-serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/of-serial.txt
> > @@ -39,6 +39,10 @@ Optional properties:
> >driver is allowed to detect support for the capability even without this
> >property.
> >
> > +Optional child node:
> > +- a platform device listed as a child node will be probed and can
> > + register with the tty for open/close events to manage power.
> > +
>
> Drop the Linux specific bits and add the requirement of a compatible
> value here. Suggestion:
>
> Optional child node:
> A slave device connected to the serial port. It must contain at
> least a compatible property with a name string following generic
> names recommended practice.
That looks good, thanks.
>
> > Example:
> >
> > uart@8023 {
> > diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> > index 0508a1d8e4cd..6c67a3fd257e 100644
> > diff --git a/include/linux/tty.h b/include/linux/tty.h
> > index 5171ef8f7b85..fab8af995bd3 100644
> > --- a/include/linux/tty.h
> > +++ b/include/linux/tty.h
> > @@ -299,6 +299,22 @@ struct tty_file_private {
> > struct list_head list;
> > };
> >
> > +/* A "tty slave" device is permanently attached to a tty, typically
> > + * via a UART.
> > + * The driver can register for notifications for power management
> > + * etc. Any operation can be NULL.
> > + * Operations are called under dev->mutex for the tty device.
> > + */
> > +struct tty_slave_operations {
> > + /* 'open' is called when the device is
[LKP] [sched] a15b12ac36a: -46.9% time.voluntary_context_switches +1.5% will-it-scale.per_process_ops
FYI, we noticed the below changes on
commit a15b12ac36ad4e7b856a4ae54937ae26a51aebad ("sched: Do not stop cpu in
set_cpus_allowed_ptr() if task is not running")
testbox/testcase/testparams: lkp-g5/will-it-scale/performance-lock1
1ba93d42727c4400 a15b12ac36ad4e7b856a4ae549
--
%stddev %change %stddev
\ |\
1517261 ± 0% +1.5%1539994 ± 0% will-it-scale.per_process_ops
247 ± 30%+131.8%573 ± 49% sched_debug.cpu#61.ttwu_count
225 ± 22%+142.8%546 ± 34% sched_debug.cpu#81.ttwu_local
15115 ± 44% +37.3% 20746 ± 40% numa-meminfo.node7.Active
1028 ± 38%+115.3% 2214 ± 36% sched_debug.cpu#16.ttwu_local
2 ± 19%+133.3% 5 ± 43% sched_debug.cpu#89.cpu_load[3]
21 ± 45% +88.2% 40 ± 23%
sched_debug.cfs_rq[99]:/.tg_load_contrib
414 ± 33% +98.6%823 ± 28% sched_debug.cpu#81.ttwu_count
4 ± 10% +88.2% 8 ± 12%
sched_debug.cfs_rq[33]:/.runnable_load_avg
22 ± 26% +80.9% 40 ± 24%
sched_debug.cfs_rq[103]:/.tg_load_contrib
7 ± 17% -41.4% 4 ± 25% sched_debug.cfs_rq[41]:/.load
7 ± 17% -37.9% 4 ± 19% sched_debug.cpu#41.load
3 ± 22%+106.7% 7 ± 10%
sched_debug.cfs_rq[36]:/.runnable_load_avg
174 ± 13% +48.7%259 ± 31% sched_debug.cpu#112.ttwu_count
4 ± 19% +88.9% 8 ± 5%
sched_debug.cfs_rq[35]:/.runnable_load_avg
260 ± 10% +55.6%405 ± 26% numa-vmstat.node3.nr_anon_pages
1042 ± 10% +56.0% 1626 ± 26% numa-meminfo.node3.AnonPages
26 ± 22% +74.3% 45 ± 16%
sched_debug.cfs_rq[65]:/.tg_load_contrib
21 ± 43% +71.3% 37 ± 26%
sched_debug.cfs_rq[100]:/.tg_load_contrib
3686 ± 21% +40.2% 5167 ± 19% sched_debug.cpu#16.ttwu_count
142 ± 9% +34.4%191 ± 24% sched_debug.cpu#112.ttwu_local
5 ± 18% +69.6% 9 ± 15% sched_debug.cfs_rq[35]:/.load
2 ± 30%+100.0% 5 ± 37% sched_debug.cpu#106.cpu_load[1]
3 ± 23%+100.0% 6 ± 48% sched_debug.cpu#106.cpu_load[2]
5 ± 18% +69.6% 9 ± 15% sched_debug.cpu#35.load
9 ± 20% +48.6% 13 ± 16%
sched_debug.cfs_rq[7]:/.runnable_load_avg
1727 ± 15% +43.9% 2484 ± 30% sched_debug.cpu#34.ttwu_local
10 ± 17% -40.5% 6 ± 13% sched_debug.cpu#41.cpu_load[0]
10 ± 14% -29.3% 7 ± 5% sched_debug.cpu#45.cpu_load[4]
10 ± 17% -33.3% 7 ± 10% sched_debug.cpu#41.cpu_load[1]
6121 ± 8% +56.7% 9595 ± 30% sched_debug.cpu#13.sched_goidle
13 ± 8% -25.9% 10 ± 17% sched_debug.cpu#39.cpu_load[2]
12 ± 16% -24.0% 9 ± 15% sched_debug.cpu#37.cpu_load[2]
492 ± 17% -21.3%387 ± 24% sched_debug.cpu#46.ttwu_count
3761 ± 11% -23.9% 2863 ± 15% sched_debug.cpu#93.curr->pid
570 ± 19% +43.2%816 ± 17% sched_debug.cpu#86.ttwu_count
5279 ± 8% +63.5% 8631 ± 33% sched_debug.cpu#13.ttwu_count
377 ± 22% -28.6%269 ± 14% sched_debug.cpu#46.ttwu_local
5396 ± 10% +29.9% 7007 ± 14% sched_debug.cpu#16.sched_goidle
1959 ± 12% +36.9% 2683 ± 15%
numa-vmstat.node2.nr_slab_reclaimable
7839 ± 12% +37.0% 10736 ± 15% numa-meminfo.node2.SReclaimable
5 ± 15% +66.7% 8 ± 9% sched_debug.cfs_rq[33]:/.load
5 ± 25% +47.8% 8 ± 10% sched_debug.cfs_rq[37]:/.load
2 ± 0% +87.5% 3 ± 34% sched_debug.cpu#89.cpu_load[4]
5 ± 15% +66.7% 8 ± 9% sched_debug.cpu#33.load
6 ± 23% +41.7% 8 ± 10% sched_debug.cpu#37.load
8 ± 10% -26.5% 6 ± 6% sched_debug.cpu#51.cpu_load[1]
7300 ± 37% +63.6% 11943 ± 16% softirqs.TASKLET
2984 ± 6% +43.1% 4271 ± 23% sched_debug.cpu#20.ttwu_count
328 ± 4% +40.5%462 ± 25% sched_debug.cpu#26.ttwu_local
10 ± 7% -27.5% 7 ± 5% sched_debug.cpu#43.cpu_load[3]
9 ± 8% -30.8% 6 ± 6% sched_debug.cpu#41.cpu_load[3]
9 ± 8% -27.0% 6 ± 6% sched_debug.cpu#41.cpu_load[4]
10 ± 14% -32.5% 6 ± 6% sched_debug.cpu#41.cpu_load[2]
16292 ± 6% +42.8% 23260 ± 25% sched_debug.cpu#13.nr_switches
14 ± 28% +55.9% 23 ± 8% sched_debug.cpu#99.cpu_load[0]
5 ± 8% +28.6% 6 ± 12% sched_debug.cpu#17.load
13 ± 7% -23.1% 10 ± 12% sched_debug.cpu#39.cpu_load[3]
7 ± 10% -35.7% 4 ± 11%
[PATCH] Fix a white space coding style problem
Signed-off-by: Kroderia --- drivers/staging/skein/skein_generic.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/skein/skein_generic.c b/drivers/staging/skein/skein_generic.c index 85bd7d0..899078f 100644 --- a/drivers/staging/skein/skein_generic.c +++ b/drivers/staging/skein/skein_generic.c @@ -191,7 +191,6 @@ static int __init skein_generic_init(void) return 0; - unreg512: crypto_unregister_shash(); unreg256: -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/8] mm/debug-pagealloc: prepare boottime configurable on/off
On Mon, Dec 22, 2014 at 10:10:42AM +0100, Paul Bolle wrote: > Hi Joonsoo, > > On Fri, 2014-11-28 at 16:35 +0900, Joonsoo Kim wrote: > > Hello, Paul. > > > > Thanks for spotting this. > > I attach the patch. :) > > > > Andrew, > > Could you kindly fold this into the patch in your tree? > > > > Thanks. > > > > --->8--- > > From a33c480160904cc9807a448960151ac4c534 Mon Sep 17 00:00:00 2001 > > From: Joonsoo Kim > > Date: Fri, 28 Nov 2014 16:05:32 +0900 > > Subject: [PATCH] mm/debug_pagealloc: remove obsolete Kconfig options > > > > These are obsolete since commit "mm/debug-pagealloc: prepare boottime > > configurable" is merged. So, remove it. > > > > [pebo...@tiscali.nl: find obsolete Kconfig options] > > Signed-off-by: Joonsoo Kim > > --- > > mm/Kconfig.debug |9 - > > 1 file changed, 9 deletions(-) > > > > diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug > > index 56badfc..957d3da 100644 > > --- a/mm/Kconfig.debug > > +++ b/mm/Kconfig.debug > > @@ -14,7 +14,6 @@ config DEBUG_PAGEALLOC > > depends on !KMEMCHECK > > select PAGE_EXTENSION > > select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC > > - select PAGE_GUARD if ARCH_SUPPORTS_DEBUG_PAGEALLOC > > ---help--- > > Unmap pages from the kernel linear mapping after free_pages(). > > This results in a large slowdown, but helps to find certain types > > @@ -27,13 +26,5 @@ config DEBUG_PAGEALLOC > > that would result in incorrect warnings of memory corruption after > > a resume because free pages are not saved to the suspend image. > > > > -config WANT_PAGE_DEBUG_FLAGS > > - bool > > - > > config PAGE_POISONING > > bool > > - select WANT_PAGE_DEBUG_FLAGS > > - > > -config PAGE_GUARD > > - bool > > - select WANT_PAGE_DEBUG_FLAGS > > This patch didn't make it into v3.19-rc1. And I think it never entered > linux-next. Did this fall through the cracks or was there some other > issue with this patch? Hello, I guess that it is just missed. I re-sent the patch to Andrew a while ago. Thank you for reporting. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/debug_pagealloc: remove obsolete Kconfig options
These are obsolete since commit e30825f1869a ("mm/debug-pagealloc:
prepare boottime configurable on/off") is merged. Remove them.
Reported-by: Paul Bolle
Signed-off-by: Joonsoo Kim
---
mm/Kconfig.debug |9 -
1 file changed, 9 deletions(-)
diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
index 56badfc..957d3da 100644
--- a/mm/Kconfig.debug
+++ b/mm/Kconfig.debug
@@ -14,7 +14,6 @@ config DEBUG_PAGEALLOC
depends on !KMEMCHECK
select PAGE_EXTENSION
select PAGE_POISONING if !ARCH_SUPPORTS_DEBUG_PAGEALLOC
- select PAGE_GUARD if ARCH_SUPPORTS_DEBUG_PAGEALLOC
---help---
Unmap pages from the kernel linear mapping after free_pages().
This results in a large slowdown, but helps to find certain types
@@ -27,13 +26,5 @@ config DEBUG_PAGEALLOC
that would result in incorrect warnings of memory corruption after
a resume because free pages are not saved to the suspend image.
-config WANT_PAGE_DEBUG_FLAGS
- bool
-
config PAGE_POISONING
bool
- select WANT_PAGE_DEBUG_FLAGS
-
-config PAGE_GUARD
- bool
- select WANT_PAGE_DEBUG_FLAGS
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: cleanup align switch and case
On Mon, Dec 22, 2014 at 01:18:01PM -0800, Greg KH wrote:
> On Mon, Dec 22, 2014 at 11:48:57PM +0300, samuel kihahu wrote:
> > From: skihahu
> >
> > Align switch and case to be at the same indent.
> >
> > Signed-off-by: samuel kihahu
>
> The "From:" and "Signed-off-by:" names don't match, which doesn't make
> much sense, right? Please fix and resend.
>
I have corrected as requested above.
>From 766dd7eefe8992b90dc69cca085e6719019aae82 Mon Sep 17 00:00:00 2001
From: samuel kihahu
Date: Mon, 22 Dec 2014 18:16:29 +0300
Subject: [PATCH] staging: lustre: cleanup align switch and case
Align switch and case to be at the same indent.
Signed-off-by: samuel kihahu
---
drivers/staging/lustre/lnet/selftest/module.c | 50 +--
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/lustre/lnet/selftest/module.c
b/drivers/staging/lustre/lnet/selftest/module.c
index 6dd4309..b5f07fa 100644
--- a/drivers/staging/lustre/lnet/selftest/module.c
+++ b/drivers/staging/lustre/lnet/selftest/module.c
@@ -61,31 +61,31 @@ lnet_selftest_fini(void)
int i;
switch (lst_init_step) {
- case LST_INIT_CONSOLE:
- lstcon_console_fini();
- case LST_INIT_FW:
- sfw_shutdown();
- case LST_INIT_RPC:
- srpc_shutdown();
- case LST_INIT_WI_TEST:
- for (i = 0;
-i < cfs_cpt_number(lnet_cpt_table()); i++) {
- if (lst_sched_test[i] == NULL)
- continue;
- cfs_wi_sched_destroy(lst_sched_test[i]);
- }
- LIBCFS_FREE(lst_sched_test,
- sizeof(lst_sched_test[0]) *
- cfs_cpt_number(lnet_cpt_table()));
- lst_sched_test = NULL;
-
- case LST_INIT_WI_SERIAL:
- cfs_wi_sched_destroy(lst_sched_serial);
- lst_sched_serial = NULL;
- case LST_INIT_NONE:
- break;
- default:
- LBUG();
+ case LST_INIT_CONSOLE:
+ lstcon_console_fini();
+ case LST_INIT_FW:
+ sfw_shutdown();
+ case LST_INIT_RPC:
+ srpc_shutdown();
+ case LST_INIT_WI_TEST:
+ for (i = 0;
+i < cfs_cpt_number(lnet_cpt_table()); i++) {
+ if (lst_sched_test[i] == NULL)
+ continue;
+ cfs_wi_sched_destroy(lst_sched_test[i]);
+ }
+ LIBCFS_FREE(lst_sched_test,
+ sizeof(lst_sched_test[0]) *
+ cfs_cpt_number(lnet_cpt_table()));
+ lst_sched_test = NULL;
+
+ case LST_INIT_WI_SERIAL:
+ cfs_wi_sched_destroy(lst_sched_serial);
+ lst_sched_serial = NULL;
+ case LST_INIT_NONE:
+ break;
+ default:
+ LBUG();
}
return;
}
[PATCH v2] perf hists: Fix children sort key behavior
When perf report --children resorts output fields, it tries to put
caller above the callee. But this was only meaningful for a same
thread and doing this requires callchain enabled. So fix its check
before comparing the callchain depth.
This also changes the hist accumulation tests: In test 3, xmalloc in
bash thread should be above than other perf threads due to
alphabetical order of comm string. Also it's under page_fault in bash
thread since alphabetical order of dso name. The sys_perf_event_open
in perf thread is put on the last line since it's self overhead is 0.
In test 4, the sys_perf_event_open is put above other perf entries
that have same children overhead since its callchain depth is smaller.
Signed-off-by: Namhyung Kim
---
Do not change return value calculation.
tools/perf/tests/hists_cumulate.c | 64 +++
tools/perf/ui/hist.c | 3 ++
2 files changed, 35 insertions(+), 32 deletions(-)
diff --git a/tools/perf/tests/hists_cumulate.c
b/tools/perf/tests/hists_cumulate.c
index 5bb3ad42be57..18619966454c 100644
--- a/tools/perf/tests/hists_cumulate.c
+++ b/tools/perf/tests/hists_cumulate.c
@@ -454,12 +454,12 @@ static int test3(struct perf_evsel *evsel, struct machine
*machine)
* 30.00%10.00% perf perf [.] cmd_record
* 20.00% 0.00% bash libc [.] malloc
* 10.00%10.00% bash [kernel] [k] page_fault
-* 10.00%10.00% perf [kernel] [k] schedule
-* 10.00% 0.00% perf [kernel] [k] sys_perf_event_open
+* 10.00%10.00% bash bash [.] xmalloc
* 10.00%10.00% perf [kernel] [k] page_fault
-* 10.00%10.00% perf libc [.] free
* 10.00%10.00% perf libc [.] malloc
-* 10.00%10.00% bash bash [.] xmalloc
+* 10.00%10.00% perf [kernel] [k] schedule
+* 10.00%10.00% perf libc [.] free
+* 10.00% 0.00% perf [kernel] [k] sys_perf_event_open
*/
struct result expected[] = {
{ 7000, 2000, "perf", "perf", "main" },
@@ -468,12 +468,12 @@ static int test3(struct perf_evsel *evsel, struct machine
*machine)
{ 3000, 1000, "perf", "perf", "cmd_record" },
{ 2000,0, "bash", "libc", "malloc" },
{ 1000, 1000, "bash", "[kernel]", "page_fault" },
- { 1000, 1000, "perf", "[kernel]", "schedule" },
- { 1000,0, "perf", "[kernel]", "sys_perf_event_open" },
+ { 1000, 1000, "bash", "bash", "xmalloc" },
{ 1000, 1000, "perf", "[kernel]", "page_fault" },
+ { 1000, 1000, "perf", "[kernel]", "schedule" },
{ 1000, 1000, "perf", "libc", "free" },
{ 1000, 1000, "perf", "libc", "malloc" },
- { 1000, 1000, "bash", "bash", "xmalloc" },
+ { 1000,0, "perf", "[kernel]", "sys_perf_event_open" },
};
symbol_conf.use_callchain = false;
@@ -537,10 +537,13 @@ static int test4(struct perf_evsel *evsel, struct machine
*machine)
* malloc
* main
*
-* 10.00%10.00% perf [kernel] [k] schedule
+* 10.00%10.00% bash bash [.] xmalloc
* |
-* --- schedule
-* run_command
+* --- xmalloc
+* malloc
+* xmalloc <--- NOTE: there's a cycle
+* malloc
+* xmalloc
* main
*
* 10.00% 0.00% perf [kernel] [k] sys_perf_event_open
@@ -556,6 +559,12 @@ static int test4(struct perf_evsel *evsel, struct machine
*machine)
* run_command
* main
*
+* 10.00%10.00% perf [kernel] [k] schedule
+* |
+* --- schedule
+* run_command
+* main
+*
* 10.00%10.00% perf libc [.] free
* |
* --- free
@@ -570,15 +579,6 @@ static int test4(struct perf_evsel *evsel, struct machine
*machine)
* run_command
* main
*
-* 10.00%10.00% bash bash [.] xmalloc
-* |
-* --- xmalloc
-* malloc
-* xmalloc <--- NOTE: there's a cycle
-* malloc
-* xmalloc
-* main
-*
*/
Re: [PATCHv5 3/9] devfreq: event: Add exynos-ppmu devfreq-event driver
On 12/23/2014 12:40 PM, Varka Bhadram wrote:
> On Tue, Dec 23, 2014 at 8:48 AM, Chanwoo Choi wrote:
>> This patch adds exynos-ppmu devfreq-event driver to get performance data
>> of each IP for Samsung Exynos SoC. These event from Exynos PPMU provide
>> useful information about the behavior of the SoC that you can use when
>> analyzing system performance, and made visible and can be counted using
>> logic in each IP.
>>
>> This patch is based on existing drivers/devfreq/exynos/exynos-ppmu.c
>>
>> Cc: MyungJoo Ham
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>
> (...)
>> +static int exynos_ppmu_parse_dt(struct exynos_ppmu_data *data)
>> +{
>> + struct device *dev = data->dev;
>> + struct device_node *np = dev->of_node;
>> + int ret = 0;
>> +
>> + if (!np) {
>> + dev_err(dev, "failed to find devicetree node\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* Maps the memory mapped IO to control PPMU register */
>> + data->ppmu.base = of_iomap(np, 0);
>> + if (IS_ERR_OR_NULL(data->ppmu.base)) {
>> + dev_err(dev, "failed to map memory region\n");
>> + return -EINVAL;
> -ENOMEM or -ENXIO is the proper error return value..?
OK. I'll return -ENOMEM value.
>
>> + }
>> +
>> + data->clk_ppmu = devm_clk_get(dev, "ppmu");
>> + if (IS_ERR(data->clk_ppmu)) {
>> + data->clk_ppmu = NULL;
>> + dev_warn(dev, "failed to get PPMU clock\n");
>> + }
> If PPMU clk get fails..? return PTR_ERR(data->clk_ppmu)
If Exynos SoC don't register the clock to clock tree, the clock remains on
state.
So, I print just warning message.
But, It is not proper. I'll fix it.
>> +
>> + ret = of_get_devfreq_events(np, data);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to parse exynos ppmu dt node\n");
>> + goto err;
>> + }
>> +
>> + return 0;
>> +
>> +err:
>> + iounmap(data->ppmu.base);
>> +
>> + return ret;
>> +}
>> +
>> +static int exynos_ppmu_probe(struct platform_device *pdev)
>> +{
>> + struct exynos_ppmu_data *data;
>> + struct devfreq_event_dev **edev;
>> + struct devfreq_event_desc *desc;
>> + int i, ret = 0, size;
>> +
>> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + mutex_init(>lock);
>> + data->dev = >dev;
>> +
>> + /* Parse dt data to get resource */
>> + ret = exynos_ppmu_parse_dt(data);
>> + if (ret < 0) {
>> + dev_err(>dev,
>> + "failed to parse devicetree for resource\n");
>> + return ret;
>> + }
>> + desc = data->desc;
>> +
>> + size = sizeof(struct devfreq_event_dev *) * data->num_events;
>> + data->edev = devm_kzalloc(>dev, size, GFP_KERNEL);
>> + if (!data->edev) {
>> + dev_err(>dev,
>> + "failed to allocate memory devfreq-event devices\n");
>> + return -ENOMEM;
>> + }
>> + edev = data->edev;
>> + platform_set_drvdata(pdev, data);
>> +
>> + for (i = 0; i < data->num_events; i++) {
>> + edev[i] = devfreq_event_add_edev(>dev, [i]);
>> + if (IS_ERR(edev)) {
>> + ret = PTR_ERR(edev);
>> + dev_err(>dev,
>> + "failed to add devfreq-event device\n");
>> + goto err;
>> + }
>> + }
>> +
>> + clk_prepare_enable(data->clk_ppmu);
>> +
>> + return 0;
>> +err:
>> + iounmap(data->ppmu.base);
>> +
>> + return ret;
>> +}
>> +
>> +static int exynos_ppmu_remove(struct platform_device *pdev)
>> +{
>> + struct exynos_ppmu_data *data = platform_get_drvdata(pdev);
>> + int i, ret = 0;
>> +
>> + for (i = 0; i < data->num_events; i++) {
>> + ret = devfreq_event_remove_edev(data->edev[i]);
>> + if (ret < 0) {
>> + dev_err(>dev,
>> + "failed to remove devfreq-event device\n");
>> + goto err;
>> + }
>> + }
>> +
>> +err:
>> + clk_disable_unprepare(data->clk_ppmu);
>> + iounmap(data->ppmu.base);
>> +
>> + return ret;
>> +}
>> +
>> +static struct of_device_id exynos_ppmu_id_match[] = {
>> + { .compatible = "samsung,exynos-ppmu", },
>> + { /* sentinel */ },
>> +};
>> +
>> +static struct platform_driver exynos_ppmu_driver = {
>> + .probe = exynos_ppmu_probe,
>> + .remove = exynos_ppmu_remove,
>> + .driver = {
>> + .name = "exynos-ppmu",
>> + .owner = THIS_MODULE,
> remove owner field. It will be populate by driver core.
OK. I'll remove it.
Thanks for your review.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe
Re: [RFC PATCH] f2fs: add extent cache base on rb-tree
Hi, On Mon, Dec 22, 2014 at 03:10:30PM +0800, Chao Yu wrote: > Hi Changman, > > > -Original Message- > > From: Changman Lee [mailto:cm224@samsung.com] > > Sent: Monday, December 22, 2014 10:03 AM > > To: Chao Yu > > Cc: Jaegeuk Kim; linux-f2fs-de...@lists.sourceforge.net; > > linux-kernel@vger.kernel.org > > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > > > Hi Yu, > > > > Good approach. > > Thank you. :) > > > As you know, however, f2fs breaks extent itself due to COW. > > Yes, and sometimes f2fs use IPU when override writing, in this condition, > by using this approach we can cache more contiguous mapping extent for better > performance. > > > Unlike other filesystem like btrfs, minimum extent of f2fs could have 4KB > > granularity. > > So we would have lots of extents per inode and it could lead to overhead > > to manage extents. > > Agree, the more number of extents are growing in one inode, the more memory > pressure and longer latency operating in rb-tree we are facing. > IMO, to solve this problem, we'd better to add limitation or shrink ability > into > extent cache: > 1.limit extent number per inode with the value set from sysfs and discard > extent > from inode's extent lru list if we touch the limitation; (e.g. in FAT, max > number > of mapping extent per inode is fixed: 8) > 2.add all extents of inodes into a global lru list, we will try to shrink > this list > if we're facing memory pressure. > > How do you think? or any better ideas are welcome. :) > I think both of them are considerable options. How about adding extent to inode selected by user using ioctl or xattr? In the case of read most files having large size, user could get a benefit surely although they are seperated some pieces. Thanks, > > > > Anyway, mount option could be alternative for this patch. > > Yes, will do. > > Thanks, > Yu > > > > > On Fri, Dec 19, 2014 at 06:49:29PM +0800, Chao Yu wrote: > > > Now f2fs have page-block mapping cache which can cache only one extent > > > mapping > > > between contiguous logical address and physical address. > > > Normally, this design will work well because f2fs will expand coverage > > > area of > > > the mapping extent when we write forward sequentially. But when we write > > > data > > > randomly in Out-Place-Update mode, the extent will be shorten and hardly > > > be > > > expanded for most time as following reasons: > > > 1.The short part of extent will be discarded if we break contiguous > > > mapping in > > > the middle of extent. > > > 2.The new mapping will be added into mapping cache only at head or tail > > > of the > > > extent. > > > 3.We will drop the extent cache when the extent became very fragmented. > > > 4.We will not update the extent with mapping which we get from readpages > > > or > > > readpage. > > > > > > To solve above problems, this patch adds extent cache base on rb-tree > > > like other > > > filesystems (e.g.: ext4/btrfs) in f2fs. By this way, f2fs can support > > > another > > > more effective cache between dnode page cache and disk. It will supply > > > high hit > > > ratio in the cache with fewer memory when dnode page cache are reclaimed > > > in > > > environment of low memory. > > > > > > Todo: > > > *introduce mount option for extent cache. > > > *add shrink ability for extent cache. > > > > > > Signed-off-by: Chao Yu > > > --- > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf hists: Fix children sort key behavior
When perf report --children resorts output fields, it tries to put
caller above the callee. But this was only meaningful for a same
thread and doing this requires callchain enabled. So fix its check
before comparing the callchain depth.
This also changes the hist accumulation tests: In test 3, xmalloc in
bash thread should be above than other perf threads due to
alphabetical order of comm string. Also it's under page_fault in bash
thread since alphabetical order of dso name. The sys_perf_event_open
in perf thread is put on the last line since it's self overhead is 0.
In test 4, the sys_perf_event_open is put above other perf entries
that have same children overhead since its callchain depth is smaller.
Signed-off-by: Namhyung Kim
---
tools/perf/tests/hists_cumulate.c | 64 +++
tools/perf/ui/hist.c | 5 ++-
2 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/tools/perf/tests/hists_cumulate.c
b/tools/perf/tests/hists_cumulate.c
index b1a2bed721a8..9fcf27efd6c8 100644
--- a/tools/perf/tests/hists_cumulate.c
+++ b/tools/perf/tests/hists_cumulate.c
@@ -454,12 +454,12 @@ static int test3(struct perf_evsel *evsel, struct machine
*machine)
* 30.00%10.00% perf perf [.] cmd_record
* 20.00% 0.00% bash libc [.] malloc
* 10.00%10.00% bash [kernel] [k] page_fault
-* 10.00%10.00% perf [kernel] [k] schedule
-* 10.00% 0.00% perf [kernel] [k] sys_perf_event_open
+* 10.00%10.00% bash bash [.] xmalloc
* 10.00%10.00% perf [kernel] [k] page_fault
-* 10.00%10.00% perf libc [.] free
* 10.00%10.00% perf libc [.] malloc
-* 10.00%10.00% bash bash [.] xmalloc
+* 10.00%10.00% perf [kernel] [k] schedule
+* 10.00%10.00% perf libc [.] free
+* 10.00% 0.00% perf [kernel] [k] sys_perf_event_open
*/
struct result expected[] = {
{ 7000, 2000, "perf", "perf", "main" },
@@ -468,12 +468,12 @@ static int test3(struct perf_evsel *evsel, struct machine
*machine)
{ 3000, 1000, "perf", "perf", "cmd_record" },
{ 2000,0, "bash", "libc", "malloc" },
{ 1000, 1000, "bash", "[kernel]", "page_fault" },
- { 1000, 1000, "perf", "[kernel]", "schedule" },
- { 1000,0, "perf", "[kernel]", "sys_perf_event_open" },
+ { 1000, 1000, "bash", "bash", "xmalloc" },
{ 1000, 1000, "perf", "[kernel]", "page_fault" },
+ { 1000, 1000, "perf", "[kernel]", "schedule" },
{ 1000, 1000, "perf", "libc", "free" },
{ 1000, 1000, "perf", "libc", "malloc" },
- { 1000, 1000, "bash", "bash", "xmalloc" },
+ { 1000,0, "perf", "[kernel]", "sys_perf_event_open" },
};
symbol_conf.use_callchain = false;
@@ -537,10 +537,13 @@ static int test4(struct perf_evsel *evsel, struct machine
*machine)
* malloc
* main
*
-* 10.00%10.00% perf [kernel] [k] schedule
+* 10.00%10.00% bash bash [.] xmalloc
* |
-* --- schedule
-* run_command
+* --- xmalloc
+* malloc
+* xmalloc <--- NOTE: there's a cycle
+* malloc
+* xmalloc
* main
*
* 10.00% 0.00% perf [kernel] [k] sys_perf_event_open
@@ -556,6 +559,12 @@ static int test4(struct perf_evsel *evsel, struct machine
*machine)
* run_command
* main
*
+* 10.00%10.00% perf [kernel] [k] schedule
+* |
+* --- schedule
+* run_command
+* main
+*
* 10.00%10.00% perf libc [.] free
* |
* --- free
@@ -570,15 +579,6 @@ static int test4(struct perf_evsel *evsel, struct machine
*machine)
* run_command
* main
*
-* 10.00%10.00% bash bash [.] xmalloc
-* |
-* --- xmalloc
-* malloc
-* xmalloc <--- NOTE: there's a cycle
-* malloc
-* xmalloc
-* main
-*
*/
struct result expected[] = {
Re: [PATCH] tools: lib: traceevent: kbuffer-parse.c: Remove some unused functions
On Sat, Dec 20, 2014 at 05:40:00PM +0100, Rickard Strandqvist wrote: > Removes some functions that are not used anywhere: > kbuffer_set_old_format() kbuffer_missed_events() kbuffer_curr_size() > kbuffer_event_size() kbuffer_curr_offset() kbuffer_curr_index() > kbuffer_subbuffer_size() kbuffer_read_at_offset() kbuffer_timestamp() > kbuffer_read_event() kbuffer_translate_data() kbuffer_free() kbuffer_alloc() > > This was partially found by using a static code analysis program called > cppcheck. This kbuffer API will be used by other (out-of-tree currently) tools.. And I have a plan to add an in-kernel user (perf-ftrace command) later. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftracetest: Replace usleep with sleep 0.000001
On Sat, Dec 20, 2014 at 05:07:25PM -0500, Steven Rostedt wrote: > On Sat, 20 Dec 2014 21:42:13 +0100 > Pavel Machek wrote: > > > On Wed 2014-12-10 15:38:27, Michael Ellerman wrote: > > > usleep is a Fedoraism, it's not generally available on Debian based > > > systems AFAICS. > > > > > > GNU sleep accepts a floating point argument, so use that instead. > > > > > > Signed-off-by: Michael Ellerman > > > > Could ftrace user interface be enhanced not to need random delays? > > > > Not sure what you are talking about. These "random delays" are not for > the interface, but instead to force some events to happen and to make > sure they did. > > As the subject states, this is for "ftracetest" which is the selftests > for ftrace. > > The usleep is basically a "do something to trigger events", and we > don't want to wait long in doing it. Right. AFAIK what ftracetest expects is a scheduler event so it doesn't need to be the [u]sleep. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sound: pci: asihpi: hpifunc.c: Remove some unused functions
On 23/12/14 10:41, Rickard Strandqvist wrote: > Hi Eliot! > > This is one of the largest remove patches I made. > Is it just one function you disagree with? Yes. If you generate the patch against for-next branch I guess that function will not be removed because it is used by the new code. > > Then I obviously send a new Patch! > Will be busy few days, but then I send a new one. > > Kind regards > Rickard Strandqvist > > > 2014-12-21 23:32 GMT+01:00 Eliot Blennerhassett : >> On 22/12/14 05:50, Rickard Strandqvist wrote: >>> Removes some functions that are not used anywhere: >> >> NAK - because hpi_adapter_set_property() is now used in for-next branch >> of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git >> >> Otherwise I have no problem with the patch. -- Eliot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: missing merge fix for the access_once tree
On Mon, Dec 22, 2014 at 6:17 PM, Stephen Rothwell wrote: > > I have been carrying this merge fix patch for some time. It should > have gone into the merge of the access_once tree. No, you had a different tree that got merged into linux-next, that made it an error to do ACCESS_ONCE() on a structure. The thing I merged didn't actually have that final commit, exactly so that things wouldn't break from missing conversions. So that patch isn't wrong, but it also isn't exactly a required fix until the next merge window.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] usb: chipidea: add one errata for revision 2.40a
On 12/23/2014 05:39 AM, Peter Chen wrote: > On Mon, Dec 22, 2014 at 06:39:42PM +0530, Sanchayan Maity wrote: >> On 12/22/2014 06:48 AM, Peter Chen wrote: >>> On Fri, Dec 19, 2014 at 03:25:26PM +0530, Sanchayan Maity wrote: The first two patches add identification register API's. These can be used to get controller's revision. The third patch implements an errata for revision 2.40a. Not sure which other SOCs implement this version of the Chipidea core but this fixes the usb client issue observed on Vybrids. The patch was tested on a Toradex Colibri VF61 module with the 3.18 kernel. iperf tests ran for three hours plus, with these patches applied have found the USB client connection to be now reliable. >>> >>> Would you help do a overnight test? It is passed, I will queue them, >>> thanks. >> >> Yes definitely I can help with the testing. Are you looking for iperf >> tests only or something else? iperf tests running for 12 or 24 hours >> will do? I will need a bit of time to set things up here, as I am away >> from work, but, ya I will do them. >> > > iperf for g_ncm or g_ether and bonnie++ for g_mass_storage if you can > run, thanks. Will run 12 hour iperf test for CDC ECM. I am not aware of bonnie++, but, will look into it. Will get back once I have the results. Thanks. Regards, Sanchayan. > > Peter > >> -Regards, >> Sanchayan. >>> >>> Peter This patchset is based off on Shawn Guo's for-next branch https://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/tree/?h=for-next The credit for the patches and fix goes to Matthieu Castet and Peter Chen. First two patches are by Peter Chen and the third patch which fixed the bug we observed was reported by Matthieu Castet. The discussion of the problem and the relevant testing details can be found at this link: http://www.spinics.net/lists/linux-usb/msg118544.html The first version of this patchset originally send by Peter Chen can be found at this link: http://www.spinics.net/lists/linux-usb/msg118753.html Comments for review are welcome :). Note: I am going on a vacation so will not be able to reply or do any further tests till Monday. Will attend and take care of any comments/requests for further changes/testing from Tuesday. Apologize for the delay in advance. Sanchayan Maity (3): usb: chipidea: Add identification registers access APIs usb: chipidea: Add chipidea revision information usb: chipidea: Add errata for revision 2.40a drivers/usb/chipidea/bits.h | 10 drivers/usb/chipidea/ci.h | 53 +++ drivers/usb/chipidea/core.c | 23 +-- drivers/usb/chipidea/udc.c | 20 4 files changed, 104 insertions(+), 2 deletions(-) -- 1.7.9.5 >>> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/7] perf diff: Fix to sort by baseline field by default
On Mon, Dec 22, 2014 at 11:45:13AM -0300, Arnaldo Carvalho de Melo wrote: > Looks better, here I tried running 'perf record usleep 1' in quick > succession to then run 'perf diff' before and after this patch, got: > > Before: > > [ssdandy ~]$ cat /tmp/before > # Event 'cycles' > # > # BaselineDelta Shared Object Symbol > # ... .. > # > +36.29% [kernel.vmlinux] [k] __split_vma.isra.31 > 34.55% [kernel.vmlinux] [k] copy_user_generic_unrolled > +2.45% [kernel.vmlinux] [k] local_clock > 0.11% +0.02% [kernel.vmlinux] [k] native_write_msr_safe > 2.12% [kernel.vmlinux] [k] perf_event_comm_output > +61.13% [kernel.vmlinux] [k] unmap_page_range > 63.22% libc-2.17.so [.] 0x0007c3e0 > [acme@ssdandy ~]$ > > After: > > [acme@ssdandy linux]$ perf diff > # Event 'cycles' > # > # BaselineDelta Shared Object Symbol > # ... .. > # > 63.22% libc-2.17.so [.] 0x0007c3e0 > 34.55% [kernel.vmlinux] [k] copy_user_generic_unrolled > 2.12% [kernel.vmlinux] [k] perf_event_comm_output > 0.11% +0.02% [kernel.vmlinux] [k] native_write_msr_safe > +36.29% [kernel.vmlinux] [k] __split_vma.isra.31 > +2.45% [kernel.vmlinux] [k] local_clock > +61.13% [kernel.vmlinux] [k] unmap_page_range > [acme@ssdandy linux]$ > > Which was ok up to the point where symbols that only appeared on the > second run were not sorted by delta, can you fix that? I'll do that later. > > Please let me know if it is better to apply this one then a followup to > sort the deltas or if a combined patch to achieve both is best. I prefer applying this for now and then improve sorting later.. > > I.e.: > > [acme@ssdandy linux]$ perf diff > # Event 'cycles' > # > # BaselineDelta Shared Object Symbol > # ... .. > # > 63.22% libc-2.17.so [.] 0x0007c3e0 > 34.55% [kernel.vmlinux] [k] copy_user_generic_unrolled > 2.12% [kernel.vmlinux] [k] perf_event_comm_output > 0.11% +0.02% [kernel.vmlinux] [k] native_write_msr_safe > +61.13% [kernel.vmlinux] [k] unmap_page_range > +36.29% [kernel.vmlinux] [k] __split_vma.isra.31 > +2.45% [kernel.vmlinux] [k] local_clock > > [acme@ssdandy linux]$ > > Humm, but then wouldn't we be more interested in sorting _everything_ by > delta? I don't understand whay you said.. what do you mean by 'everything be delta'? Is that something other than perf diff -o 1 ? Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: missing merge fix patch for the merge of the xen-tip tree with the arm-soc tree
On Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell wrote: > Hi Linus, > > I have been carrying this merge fix patch for some time that is now > needed in your tree: No, it's not. Look more closely. My merge put the dev->archdata.dma_coherent = coherent; line at the top of the function, like the way it was in the original commit. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] perf tools: Set attr.task bit for a tracking event
On Mon, Dec 22, 2014 at 11:49:19AM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 22, 2014 at 01:44:15PM +0900, Namhyung Kim escreveu: > > The perf_event_attr.task bit is to track task (fork and exit) events > > but it missed to be set by perf_evsel__config(). While it was not a > > problem in practice since setting other bits (comm/mmap) ended up > > being in same result, it'd be good to set it explicitly anyway. > > I didn't understand, so this isn't strictly needed? I.e. what is the > point of the attr->task bit then? Yes, it's not strictly needed for this case. The attr->task is to track task related events (fork/exit) only but other meta events like comm and mmap[2] also needs the task events. So setting attr->comm and/or attr->mmap causes the kernel emits the task events anyway. So the attr->task is only meaningful when other bits are off but I'd like to set it for completeness. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 00/18] Add support for i.MX MIPI DSI DRM driver
Hi, This series addresses comments from Philipp Zabel and Andy Yan on v2. The i.MX MIPI DSI is a Synopsys DesignWare MIPI DSI host controller IP. This series adds support for a Synopsys DesignWare MIPI DSI host controller DRM bridge driver and a i.MX MIPI DSI specific DRM driver. Currently, the MIPI DSI drivers only support the burst with sync pulse mode. This series also includes a DRM panel driver for the Truly TFT480800-16-E panel which is driven by the Himax HX8369A driver IC. The driver IC data sheet could be found at [1]. As mentioned by the data sheet, the driver IC supports several interface modes. Currently, the DRM panel driver only supports the MIPI DSI video mode. New interface modes could be added later(perhaps, just like the way the DRM simple panel driver supports both MIPI DSI interface panels and simple(parallel) interface panels). The MIPI DSI feature is tested on i.MX6Q SabreSD board and i.MX6DL SabreSD board. The MIPI DSI display could be enabled directly on i.MX6Q SabreSD board after applying this series, because the 26.4MHz pixel clock the panel requires could be derived from the IPU HSP clock(264MHz) with an integer divider. On i.MX6DL SabreSD board, we need to manually disable the LVDS and HDMI displays in the device tree blob, since the i.MX6DL IPU HSP clock is 198MHz at present, which makes the pixel clock share the PLL5 video clock source with the LVDS and HDMI, thus, the panel cannot get the pixel clock rate it wants. Patch 01/18 is needed to get a precise pixel clock rate(26.4MHz) from the PLL5 video clock. If we don't have this patch, the pixel clock rate is about 20MHz, which causes a horitonal shift on the display image. This series can be applied on the drm-next branch. [1] http://www.allshore.com/pdf/Himax_HX8369-A.pdf Liu Ying (18): clk: divider: Correct parent clk round rate if no bestdiv is normally found of: Add vendor prefix for Himax Technologies Inc. of: Add vendor prefix for Truly Semiconductors Limited ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition ARM: imx6q: clk: Add the video_27m clock ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver drm: imx: Support Synopsys DesignWare MIPI DSI host controller drm: panel: Add support for Himax HX8369A MIPI DSI panel ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 72 ++ .../devicetree/bindings/drm/imx/mipi_dsi.txt | 75 ++ .../devicetree/bindings/panel/himax,hx8369a.txt| 41 + .../devicetree/bindings/vendor-prefixes.txt| 2 + arch/arm/boot/dts/imx6q.dtsi | 20 +- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 20 + arch/arm/boot/dts/imx6qdl.dtsi | 29 +- arch/arm/configs/imx_v6_v7_defconfig | 17 +- arch/arm/mach-imx/clk-imx6q.c | 7 +- drivers/clk/clk-divider.c | 3 +- drivers/gpu/drm/bridge/Kconfig | 5 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/dw_mipi_dsi.c | 998 + drivers/gpu/drm/imx/Kconfig| 7 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 226 + drivers/gpu/drm/panel/Kconfig | 5 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-himax-hx8369a.c| 573 include/drm/bridge/dw_mipi_dsi.h | 27 + include/drm/drm_mipi_dsi.h | 14 + include/dt-bindings/clock/imx6qdl-clock.h | 4 +- include/linux/mfd/syscon/imx6q-iomuxc-gpr.h| 1 + 23 files changed, 2119 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c create mode 100644 drivers/gpu/drm/panel/panel-himax-hx8369a.c create mode 100644
[PATCH RFC v3 06/18] ARM: imx6q: clk: Change hdmi_isfr clock's parent to be video_27m clock
According to the table 33-1 in the i.MX6Q reference manual, the hdmi_isfr
clock's parent should be the video_27m clock. The i.MX6DL reference manual
has the same statement. This patch changes the hdmi_isfr clock's parent
from the pll3_pfd1_540m clock to the video_27m clock.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 9470df3..f19472a 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -401,7 +401,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_GPU2D_CORE] = imx_clk_gate2("gpu2d_core",
"gpu2d_core_podf", base + 0x6c, 24);
clk[IMX6QDL_CLK_GPU3D_CORE] = imx_clk_gate2("gpu3d_core",
"gpu3d_core_podf", base + 0x6c, 26);
clk[IMX6QDL_CLK_HDMI_IAHB]= imx_clk_gate2("hdmi_iahb", "ahb",
base + 0x70, 0);
- clk[IMX6QDL_CLK_HDMI_ISFR]= imx_clk_gate2("hdmi_isfr",
"pll3_pfd1_540m",base + 0x70, 4);
+ clk[IMX6QDL_CLK_HDMI_ISFR]= imx_clk_gate2("hdmi_isfr",
"video_27m", base + 0x70, 4);
clk[IMX6QDL_CLK_I2C1] = imx_clk_gate2("i2c1",
"ipg_per", base + 0x70, 6);
clk[IMX6QDL_CLK_I2C2] = imx_clk_gate2("i2c2",
"ipg_per", base + 0x70, 8);
clk[IMX6QDL_CLK_I2C3] = imx_clk_gate2("i2c3",
"ipg_per", base + 0x70, 10);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 04/18] ARM: imx6q: Add GPR3 MIPI muxing control register field shift bits definition
This patch adds a macro to define the GPR3 MIPI muxing control register field shift bits. Signed-off-by: Liu Ying --- v2->v3: * None. v1->v2: * None. include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h index ff44374..3b0bed4 100644 --- a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h +++ b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h @@ -207,6 +207,7 @@ #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU1_DI1 (0x1 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI0 (0x2 << 6) #define IMX6Q_GPR3_LVDS0_MUX_CTL_IPU2_DI1 (0x3 << 6) +#define IMX6Q_GPR3_MIPI_MUX_CTL_SHIFT 4 #define IMX6Q_GPR3_MIPI_MUX_CTL_MASK (0x3 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI0 (0x0 << 4) #define IMX6Q_GPR3_MIPI_MUX_CTL_IPU1_DI1 (0x1 << 4) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 08/18] ARM: imx6q: clk: Add support for mipi_core_cfg clock as a shared clock gate
The CG8 field of the CCM CCGR3 register is named as 'mipi_core_cfg' clock,
according to the i.MX6q/sdl reference manuals. This clock is actually the
gate for several clocks, including the hsi_tx_sel clock's output and the
video_27m clock's output. The MIPI DSI host controller embedded in the
i.MX6q/sdl SoCs uses the video_27m clock to generate PLL reference clock and
MIPI core configuration clock. In order to gate/ungate the two MIPI DSI
host controller relevant clocks, this patch adds the mipi_core_cfg clock as
a shared clock gate.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 080d5b7..9815d8d 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -418,6 +418,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_LDB_DI1] = imx_clk_gate2("ldb_di1",
"ldb_di1_podf", base + 0x74, 14);
clk[IMX6QDL_CLK_IPU2_DI1] = imx_clk_gate2("ipu2_di1",
"ipu2_di1_sel", base + 0x74, 10);
clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2_shared("hsi_tx",
"hsi_tx_podf", base + 0x74, 16, _count_mipi_core_cfg);
+ clk[IMX6QDL_CLK_MIPI_CORE_CFG]=
imx_clk_gate2_shared("mipi_core_cfg","video_27m", base + 0x74, 16,
_count_mipi_core_cfg);
if (cpu_is_imx6dl())
/*
* The multiplexer and divider of the imx6q clock gpu2d get
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h
b/include/dt-bindings/clock/imx6qdl-clock.h
index 25625bf..dbc828c 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -249,6 +249,7 @@
#define IMX6QDL_PLL7_BYPASS236
#define IMX6QDL_CLK_GPT_3M 237
#define IMX6QDL_CLK_VIDEO_27M 238
-#define IMX6QDL_CLK_END239
+#define IMX6QDL_CLK_MIPI_CORE_CFG 239
+#define IMX6QDL_CLK_END240
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 12/18] drm: imx: Support Synopsys DesignWare MIPI DSI host controller
This patch adds support for Synopsys DesignWare MIPI DSI host controller
which is embedded in the i.MX6q/sdl SoCs.
Signed-off-by: Liu Ying
---
v2->v3:
* To address Andy Yan's comments, move the common Synopsys DesignWare MIPI DSI
host controller logic into it's drm/bridge driver and leave the i.MX specific
logic only.
v1->v2:
* Address almost all comments from Thierry Reding and Russell.
* Update the DT documentation to remove the display-timings node in the panel
node.
* Update the DT documentation to state that the nodes which represent the
possible
DRM CRTCs the controller may connect with should be placed in the node
"ports".
* Remove the flag 'enabled' from the struct imx_mipi_dsi.
* Move the format_to_bpp() function in v1 to the common DRM MIPI DSI driver.
* Improve the way we wait for check status for DPHY and command packet
transfer.
* Improve the DPMS support for the encoder.
* Split the functions of ->host_attach() and ->mode_valid() clearly as
suggested by
Thierry Reding.
* Improve the logics in imx_mipi_dsi_dcs_long_write().
* Enable/disable the pllref_clk and pllref_gate_clk at the component
binding/unbinding
stages to help remove the flag 'enabled'.
* Update the module license to be "GPL".
* Other minor changes, such as coding style issues and macro naming issues.
.../devicetree/bindings/drm/imx/mipi_dsi.txt | 75 +++
drivers/gpu/drm/imx/Kconfig| 7 +
drivers/gpu/drm/imx/Makefile | 1 +
drivers/gpu/drm/imx/dw_mipi_dsi-imx.c | 226 +
4 files changed, 309 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
create mode 100644 drivers/gpu/drm/imx/dw_mipi_dsi-imx.c
diff --git a/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
new file mode 100644
index 000..93cc4ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/imx/mipi_dsi.txt
@@ -0,0 +1,75 @@
+i.MX specific Device-Tree bindings for Synopsys DesignWare MIPI DSI host
controller
+
+MIPI DSI host controller
+
+
+The MIPI DSI host controller is a Synopsys DesignWare IP.
+The common device tree documentation for this controller can be found
+at [1].
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The compatible string should be "fsl,imx6q-mipi-dsi"
+ for i.MX6q/sdl SoCs.
+ - reg: Physical base address of the controller and length of memory
+ mapped region.
+ - interrupts: The controller's interrupt number to the CPU(s).
+ - gpr: Should be <>.
+ The phandle points to the iomuxc-gpr region containing the
+ multiplexer control register for the controller.
+ - clocks, clock-names: Phandles to the controller pllref, pllref_gate
+ and core_cfg clocks, as described in [2] and [3].
+
+Required sub-nodes:
+ - ports: This node may contain up to four port nodes with endpoint
+ definitions as defined in [4], corresponding to the four inputs to
+ the controller multiplexer.
+ - A node to represent a DSI peripheral as described in [5].
+
+[1] Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt.
+[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[3] Documentation/devicetree/bindings/clock/imx6q-clock.txt
+[4] Documentation/devicetree/bindings/media/video-interfaces.txt
+[5] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_mux_0: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ mipi_mux_1: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
+ };
+ };
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ /* ... */
+ };
+ };
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 82fb758..c576f6b 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -51,3 +51,10 @@ config
[PATCH RFC v3 09/18] ARM: dts: imx6qdl: Move existing MIPI DSI ports into a new 'ports' node
The MIPI DSI node contains some ports which represent possible DRM CRTCs
it can connect with. Each port has a 'reg' property embedded. This
property will be wrongly interpretted by the MIPI DSI bus driver, because
the driver will take each subnode which contains a 'reg' property as a
DSI peripheral device. This patch moves the existing MIPI DSI ports into
a new 'ports' node so that the MIPI DSI bus driver may distinguish its
DSI peripheral device(s) from the existing ports.
Acked-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v2->v3:
* Add Philipp's Ack.
v1->v2:
* Newly added, as suggested by Thierry Reding.
arch/arm/boot/dts/imx6q.dtsi | 20 +++-
arch/arm/boot/dts/imx6qdl.dtsi | 23 ++-
2 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index e9f3646..9c0990b 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -292,19 +292,21 @@
};
_dsi {
- port@2 {
- reg = <2>;
+ ports {
+ port@2 {
+ reg = <2>;
- mipi_mux_2: endpoint {
- remote-endpoint = <_di0_mipi>;
+ mipi_mux_2: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
};
- };
- port@3 {
- reg = <3>;
+ port@3 {
+ reg = <3>;
- mipi_mux_3: endpoint {
- remote-endpoint = <_di1_mipi>;
+ mipi_mux_3: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 9596ed5..96bf2a0 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1009,19 +1009,24 @@
reg = <0x021e 0x4000>;
status = "disabled";
- port@0 {
- reg = <0>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
- mipi_mux_0: endpoint {
- remote-endpoint =
<_di0_mipi>;
+ mipi_mux_0: endpoint {
+ remote-endpoint =
<_di0_mipi>;
+ };
};
- };
- port@1 {
- reg = <1>;
+ port@1 {
+ reg = <1>;
- mipi_mux_1: endpoint {
- remote-endpoint =
<_di1_mipi>;
+ mipi_mux_1: endpoint {
+ remote-endpoint =
<_di1_mipi>;
+ };
};
};
};
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 14/18] ARM: dtsi: imx6qdl: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller.
Signed-off-by: Liu Ying
---
v2->v3:
* As suggested by Phillip Zabel, change the clocks and the clock-names
properties to use the pllref and core_cfg clocks only.
v1->v2:
* None.
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 96bf2a0..7b1c313 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1006,7 +1006,13 @@
mipi_dsi: mipi@021e {
#address-cells = <1>;
#size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
status = "disabled";
ports {
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 13/18] drm: panel: Add support for Himax HX8369A MIPI DSI panel
This patch adds support for Himax HX8369A MIPI DSI panel.
Signed-off-by: Liu Ying
---
v2->v3:
* Sort the included header files alphabetically.
v1->v2:
* Address almost all comments from Thierry Reding.
* Remove several DT properties as they can be implied by the compatible string.
* Add the HIMAX/himax prefixes to the driver's Kconfig name and driver name.
* Move the driver's Makefile entry place to sort the entries alphabetically.
* Reuse several standard DCS functions instead of inventing wheels.
* Move the panel resetting and power logics to the driver probe/remove stages.
This may simplify panel prepare/unprepare hooks. The power consumption should
not change a lot at DPMS since the panel enters sleep mode at that time.
* Add the module author.
* Other minor changes, such as coding style issues.
.../devicetree/bindings/panel/himax,hx8369a.txt| 41 ++
drivers/gpu/drm/panel/Kconfig | 5 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-himax-hx8369a.c| 573 +
4 files changed, 620 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/himax,hx8369a.txt
create mode 100644 drivers/gpu/drm/panel/panel-himax-hx8369a.c
diff --git a/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
new file mode 100644
index 000..36a2f11
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/himax,hx8369a.txt
@@ -0,0 +1,41 @@
+Himax HX8369A WVGA 16.7M color TFT single chip driver with internal GRAM
+
+Himax HX8369A is a WVGA resolution driving controller.
+It is designed to provide a single chip solution that combines a source
+driver and power supply circuits to drive a TFT dot matrix LCD with
+480RGBx864 dots at the maximum.
+
+The HX8369A supports several interface modes, including MPU MIPI DBI Type
+A/B mode, MIPI DPI/DBI Type C mode, MIPI DSI video mode, MIPI DSI command
+mode and MDDI mode. The interface mode is selected by the external hardware
+pins BS[3:0].
+
+Currently, only the MIPI DSI video mode is supported.
+
+Required properties:
+ - compatible: should be a panel's compatible string
+ - reg: the virtual channel number of a DSI peripheral as described in [1]
+ - reset-gpios: a GPIO spec for the reset pin
+
+Optional properties:
+ - vdd1-supply: I/O and interface power supply
+ - vdd2-supply: analog power supply
+ - vdd3-supply: logic power supply
+ - dsi-vcc-supply: DSI and MDDI power supply
+ - vpp-supply: OTP programming voltage
+ - bs0-gpios: a GPIO spec for the pin BS0
+ - bs1-gpios: a GPIO spec for the pin BS1
+ - bs2-gpios: a GPIO spec for the pin BS2
+ - bs3-gpios: a GPIO spec for the pin BS3
+
+[1] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+Example:
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_mipi_panel>;
+ reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+ bs2-gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 024e98e..81b0bf0 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -16,6 +16,11 @@ config DRM_PANEL_SIMPLE
that it can be automatically turned off when the panel goes into a
low power state.
+config DRM_PANEL_HIMAX_HX8369A
+ tristate "Himax HX8369A panel"
+ depends on OF
+ select DRM_MIPI_DSI
+
config DRM_PANEL_LD9040
tristate "LD9040 RGB/SPI panel"
depends on OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 4b2a043..d5dbe06 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
+obj-$(CONFIG_DRM_PANEL_HIMAX_HX8369A) += panel-himax-hx8369a.o
obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
diff --git a/drivers/gpu/drm/panel/panel-himax-hx8369a.c
b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
new file mode 100644
index 000..6efce8e
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-himax-hx8369a.c
@@ -0,0 +1,573 @@
+/*
+ * Himax HX8369A panel driver.
+ *
+ * Copyright (C) 2011-2014 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This driver is based on Samsung s6e8aa0 panel driver.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define WRDISBV0x51
+#define WRCTRLD0x53
+#define WRCABC 0x55
+#define SETPOWER
[PATCH RFC v3 18/18] ARM: imx_v6_v7_defconfig: Add support for Himax HX8369A panel
This patch adds support for Himax HX8369A panel. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the Himax HX8369A panel driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v2->v3: * None. v1->v2: * Add the HIMAX prefix in the Kconfig name. arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 3e0e589..27db91b 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,6 +192,7 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y +CONFIG_DRM_PANEL_HIMAX_HX8369A=y CONFIG_DRM_IMX=y CONFIG_DRM_IMX_FB_HELPER=y CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 15/18] ARM: dts: imx6qdl-sabresd: Add support for TRULY TFT480800-16-E MIPI DSI panel
The TRULY TFT480800-16-E panel is driven by the Himax HX8369A driver IC.
The driver IC supports several display/control interface modes, including
the MIPI DSI video mode and command mode.
Signed-off-by: Liu Ying
---
v2->v3:
* None.
v1->v2:
* To address Thierry Reding's comments, remove several unnecessary
properties as they can be implied by the compatible string.
* Fix the compatible string.
* Remove the display-timings node from the panel node as it can be
implied by the compatible string as well.
* Remove the status property as it is unneeded.
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index baf2f00..658bde9 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -482,6 +482,13 @@
MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>;
};
+
+ pinctrl_mipi_panel: mipipanelgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x1b0b0
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
+ >;
+ };
};
gpio_leds {
@@ -518,6 +525,19 @@
};
};
+_dsi {
+ status = "okay";
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_mipi_panel>;
+ reset-gpios = < 11 GPIO_ACTIVE_LOW>;
+ bs2-gpios = < 14 GPIO_ACTIVE_HIGH>;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pcie>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 11/18] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
This patch adds Synopsys DesignWare MIPI DSI host controller driver support.
Currently, the driver supports the burst with sync pulses mode only.
Signed-off-by: Liu Ying
---
v2->v3:
* Newly introduced in v3 to address Andy Yan's comment. This is based on
the i.MX MIPI DSI driver in v2. To make the Synopsys DesignWare MIPI DSI
host controller driver less platform-dependant, this patch places it at
the drm/bridge directory as a DRM bridge driver.
.../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 72 ++
drivers/gpu/drm/bridge/Kconfig | 5 +
drivers/gpu/drm/bridge/Makefile| 1 +
drivers/gpu/drm/bridge/dw_mipi_dsi.c | 998 +
include/drm/bridge/dw_mipi_dsi.h | 27 +
5 files changed, 1103 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
create mode 100644 include/drm/bridge/dw_mipi_dsi.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..5dcbd9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,72 @@
+Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
+
+The controller is a digital core that implements all protocol functions
+defined in the MIPI DSI specification, providing an interface between
+the system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The compatible string should be "fsl,imx6q-mipi-dsi" for
+ i.MX6q/sdl SoCs. For other SoCs, please refer to their specific
+ device tree binding documentations.
+ - reg: Represent the physical address range of the controller.
+ - interrupts: Represent the controller's interrupt to the CPU(s).
+ - clocks, clock-names: Phandles to the controller pll reference and
+ core configuration clocks, as described in [1].
+
+For more required properties, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+Required sub-nodes:
+ - A node to represent a DSI peripheral as described in [2].
+
+For more required sub-nodes, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
+
+example:
+ gpr: iomuxc-gpr@020e {
+ /* ... */
+ };
+
+ mipi_dsi: mipi@021e {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx6q-mipi-dsi";
+ reg = <0x021e 0x4000>;
+ interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+ gpr = <>;
+ clocks = < IMX6QDL_CLK_MIPI_CORE_CFG>,
+< IMX6QDL_CLK_MIPI_CORE_CFG>;
+ clock-names = "pllref", "core_cfg";
+
+ ports {
+ port@0 {
+ reg = <0>;
+ input-port;
+
+ mipi_mux_0: endpoint {
+ remote-endpoint = <_di0_mipi>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ input-port;
+
+ mipi_mux_1: endpoint {
+ remote-endpoint = <_di1_mipi>;
+ };
+ };
+ };
+
+ panel {
+ compatible = "truly,tft480800-16-e-dsi";
+ reg = <0>;
+ /* ... */
+ };
+ };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 884923f..8180477 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -1,3 +1,8 @@
+config DRM_DW_MIPI_DSI
+ bool "Synopsys DesignWare MIPI DSI host controller bridge"
+ depends on DRM
+ select DRM_KMS_HELPER
+
config DRM_PTN3460
tristate "PTN3460 DP/LVDS bridge"
depends on DRM
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..b326ad5 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_DW_MIPI_DSI) += dw_mipi_dsi.o
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/dw_mipi_dsi.c
b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
new file mode 100644
index 000..341cd6f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw_mipi_dsi.c
@@ -0,0 +1,998 @@
[PATCH RFC v3 16/18] ARM: imx_v6_v7_defconfig: Cleanup for imx drm being moved out of staging
The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v2->v3: * None. v1->v2: * None. arch/arm/configs/imx_v6_v7_defconfig | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 6790f1b..0dbd0c3 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -192,7 +192,13 @@ CONFIG_SOC_CAMERA_OV2640=y CONFIG_IMX_IPUV3_CORE=y CONFIG_DRM=y CONFIG_DRM_PANEL_SIMPLE=y -CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_DRM_IMX=y +CONFIG_DRM_IMX_FB_HELPER=y +CONFIG_DRM_IMX_PARALLEL_DISPLAY=y +CONFIG_DRM_IMX_TVE=y +CONFIG_DRM_IMX_LDB=y +CONFIG_DRM_IMX_IPUV3=y +CONFIG_DRM_IMX_HDMI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y @@ -249,13 +255,6 @@ CONFIG_IMX_SDMA=y CONFIG_MXS_DMA=y CONFIG_FSL_EDMA=y CONFIG_STAGING=y -CONFIG_DRM_IMX=y -CONFIG_DRM_IMX_FB_HELPER=y -CONFIG_DRM_IMX_PARALLEL_DISPLAY=y -CONFIG_DRM_IMX_TVE=y -CONFIG_DRM_IMX_LDB=y -CONFIG_DRM_IMX_IPUV3=y -CONFIG_DRM_IMX_HDMI=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_PWM=y CONFIG_PWM_IMX=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 17/18] ARM: imx_v6_v7_defconfig: Add support for MIPI DSI host controller
This patch adds support for MIPI DSI host controller. The new imx_v6_v7_defconfig is generated in this way: * make ARCH=arm imx_v6_v7_defconfig * make ARCH=arm menuconfig and manually choose to build in the MIPI DSI host controller driver * make ARCH=arm savedefconfig * cp defconfig arch/arm/configs/imx_v6_v7_defconfig Signed-off-by: Liu Ying --- v2->v3: * None. v1->v2: * None. arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 0dbd0c3..3e0e589 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -199,6 +199,7 @@ CONFIG_DRM_IMX_TVE=y CONFIG_DRM_IMX_LDB=y CONFIG_DRM_IMX_IPUV3=y CONFIG_DRM_IMX_HDMI=y +CONFIG_DRM_IMX_MIPI_DSI=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_LCD_L4F00242T03=y CONFIG_LCD_PLATFORM=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 03/18] of: Add vendor prefix for Truly Semiconductors Limited
Signed-off-by: Liu Ying --- v2->v3: * None. v1->v2: * None. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 3cee528..8257f3a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -158,6 +158,7 @@ tlm Trusted Logic Mobility toradexToradex AG toshibaToshiba Corporation toumaz Toumaz +truly Truly Semiconductors Limited usiUniversal Scientific Industrial Co., Ltd. v3 V3 Semiconductor variscite Variscite Ltd. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 10/18] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
Signed-off-by: Liu Ying
---
v2->v3:
* None.
v1->v2:
* Thierry Reding suggested that the mipi_dsi_pixel_format_to_bpp() function
could be placed at the common DRM MIPI DSI driver.
This patch is newly added.
include/drm/drm_mipi_dsi.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..0f5210c 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -163,6 +163,20 @@ static inline struct mipi_dsi_device
*to_mipi_dsi_device(struct device *dev)
return container_of(dev, struct mipi_dsi_device, dev);
}
+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format
format)
+{
+ switch (format) {
+ case MIPI_DSI_FMT_RGB888:
+ case MIPI_DSI_FMT_RGB666:
+ return 24;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ return 18;
+ case MIPI_DSI_FMT_RGB565:
+ return 16;
+ }
+ return -EINVAL;
+}
+
struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node
*np);
int mipi_dsi_attach(struct mipi_dsi_device *dsi);
int mipi_dsi_detach(struct mipi_dsi_device *dsi);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 07/18] ARM: imx6q: clk: Change hsi_tx clock to be a shared clock gate
The CG8 field of the CCM CCGR3 register is named as 'mipi_core_cfg'
clock, according to the i.MX6q/sdl reference manuals. This clock is
actually the gate for several clocks, including the hsi_tx_sel clock's
output and the video_27m clock's output. So, this patch changes the
hsi_tx clock to be a shared clock gate.
Suggested-by: Philipp Zabel
Signed-off-by: Liu Ying
---
v2->v3:
* Newly introduced in v3.
arch/arm/mach-imx/clk-imx6q.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index f19472a..080d5b7 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -119,6 +119,7 @@ static unsigned int share_count_asrc;
static unsigned int share_count_ssi1;
static unsigned int share_count_ssi2;
static unsigned int share_count_ssi3;
+static unsigned int share_count_mipi_core_cfg;
static void __init imx6q_clocks_init(struct device_node *ccm_node)
{
@@ -416,7 +417,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_LDB_DI0] = imx_clk_gate2("ldb_di0",
"ldb_di0_podf", base + 0x74, 12);
clk[IMX6QDL_CLK_LDB_DI1] = imx_clk_gate2("ldb_di1",
"ldb_di1_podf", base + 0x74, 14);
clk[IMX6QDL_CLK_IPU2_DI1] = imx_clk_gate2("ipu2_di1",
"ipu2_di1_sel", base + 0x74, 10);
- clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2("hsi_tx",
"hsi_tx_podf", base + 0x74, 16);
+ clk[IMX6QDL_CLK_HSI_TX] = imx_clk_gate2_shared("hsi_tx",
"hsi_tx_podf", base + 0x74, 16, _count_mipi_core_cfg);
if (cpu_is_imx6dl())
/*
* The multiplexer and divider of the imx6q clock gpu2d get
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 02/18] of: Add vendor prefix for Himax Technologies Inc.
Signed-off-by: Liu Ying --- v2->v3: * None. v1->v2: * None. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 78efebb..3cee528 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -69,6 +69,7 @@ hannstar HannStar Display Corporation haoyu Haoyu Microelectronic Co. Ltd. hisilicon Hisilicon Limited. hitHitachi Ltd. +himax Himax Technologies, Inc. honeywell Honeywell hp Hewlett Packard i2se I2SE GmbH -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 05/18] ARM: imx6q: clk: Add the video_27m clock
This patch supports the video_27m clock which is a fixed factor
clock of the pll3_pfd1_540m clock.
Signed-off-by: Liu Ying
---
v2->v3:
* None.
v1->v2:
* None.
arch/arm/mach-imx/clk-imx6q.c | 1 +
include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 4e79da7..9470df3 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -246,6 +246,7 @@ static void __init imx6q_clocks_init(struct device_node
*ccm_node)
clk[IMX6QDL_CLK_PLL3_60M] = imx_clk_fixed_factor("pll3_60m",
"pll3_usb_otg", 1, 8);
clk[IMX6QDL_CLK_TWD] = imx_clk_fixed_factor("twd", "arm",
1, 2);
clk[IMX6QDL_CLK_GPT_3M]= imx_clk_fixed_factor("gpt_3m","osc",
1, 8);
+ clk[IMX6QDL_CLK_VIDEO_27M] = imx_clk_fixed_factor("video_27m",
"pll3_pfd1_540m", 1, 20);
if (cpu_is_imx6dl()) {
clk[IMX6QDL_CLK_GPU2D_AXI] = imx_clk_fixed_factor("gpu2d_axi",
"mmdc_ch0_axi_podf", 1, 1);
clk[IMX6QDL_CLK_GPU3D_AXI] = imx_clk_fixed_factor("gpu3d_axi",
"mmdc_ch0_axi_podf", 1, 1);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h
b/include/dt-bindings/clock/imx6qdl-clock.h
index b690cdb..25625bf 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -248,6 +248,7 @@
#define IMX6QDL_PLL6_BYPASS235
#define IMX6QDL_PLL7_BYPASS236
#define IMX6QDL_CLK_GPT_3M 237
-#define IMX6QDL_CLK_END238
+#define IMX6QDL_CLK_VIDEO_27M 238
+#define IMX6QDL_CLK_END239
#endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v3 01/18] clk: divider: Correct parent clk round rate if no bestdiv is normally found
If no best divider is normally found, we will try to use the maximum divider.
We should not set the parent clock rate to be 1Hz by force for being rounded.
Instead, we should take the maximum divider as a base and calculate a correct
parent clock rate for being rounded.
Signed-off-by: Liu Ying
---
v2->v3:
* None.
v1->v2:
* None.
drivers/clk/clk-divider.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index c0a842b..f641d4b 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -311,7 +311,8 @@ static int clk_divider_bestdiv(struct clk_hw *hw, unsigned
long rate,
if (!bestdiv) {
bestdiv = _get_maxdiv(divider);
- *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
1);
+ *best_parent_rate = __clk_round_rate(__clk_get_parent(hw->clk),
+ MULT_ROUND_UP(rate, bestdiv));
}
return bestdiv;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 3/9] devfreq: event: Add exynos-ppmu devfreq-event driver
On Tue, Dec 23, 2014 at 8:48 AM, Chanwoo Choi wrote:
> This patch adds exynos-ppmu devfreq-event driver to get performance data
> of each IP for Samsung Exynos SoC. These event from Exynos PPMU provide
> useful information about the behavior of the SoC that you can use when
> analyzing system performance, and made visible and can be counted using
> logic in each IP.
>
> This patch is based on existing drivers/devfreq/exynos/exynos-ppmu.c
>
> Cc: MyungJoo Ham
> Cc: Kyungmin Park
> Signed-off-by: Chanwoo Choi
(...)
> +static int exynos_ppmu_parse_dt(struct exynos_ppmu_data *data)
> +{
> + struct device *dev = data->dev;
> + struct device_node *np = dev->of_node;
> + int ret = 0;
> +
> + if (!np) {
> + dev_err(dev, "failed to find devicetree node\n");
> + return -EINVAL;
> + }
> +
> + /* Maps the memory mapped IO to control PPMU register */
> + data->ppmu.base = of_iomap(np, 0);
> + if (IS_ERR_OR_NULL(data->ppmu.base)) {
> + dev_err(dev, "failed to map memory region\n");
> + return -EINVAL;
-ENOMEM or -ENXIO is the proper error return value..?
> + }
> +
> + data->clk_ppmu = devm_clk_get(dev, "ppmu");
> + if (IS_ERR(data->clk_ppmu)) {
> + data->clk_ppmu = NULL;
> + dev_warn(dev, "failed to get PPMU clock\n");
> + }
If PPMU clk get fails..? return PTR_ERR(data->clk_ppmu)
> +
> + ret = of_get_devfreq_events(np, data);
> + if (ret < 0) {
> + dev_err(dev, "failed to parse exynos ppmu dt node\n");
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + iounmap(data->ppmu.base);
> +
> + return ret;
> +}
> +
> +static int exynos_ppmu_probe(struct platform_device *pdev)
> +{
> + struct exynos_ppmu_data *data;
> + struct devfreq_event_dev **edev;
> + struct devfreq_event_desc *desc;
> + int i, ret = 0, size;
> +
> + data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + mutex_init(>lock);
> + data->dev = >dev;
> +
> + /* Parse dt data to get resource */
> + ret = exynos_ppmu_parse_dt(data);
> + if (ret < 0) {
> + dev_err(>dev,
> + "failed to parse devicetree for resource\n");
> + return ret;
> + }
> + desc = data->desc;
> +
> + size = sizeof(struct devfreq_event_dev *) * data->num_events;
> + data->edev = devm_kzalloc(>dev, size, GFP_KERNEL);
> + if (!data->edev) {
> + dev_err(>dev,
> + "failed to allocate memory devfreq-event devices\n");
> + return -ENOMEM;
> + }
> + edev = data->edev;
> + platform_set_drvdata(pdev, data);
> +
> + for (i = 0; i < data->num_events; i++) {
> + edev[i] = devfreq_event_add_edev(>dev, [i]);
> + if (IS_ERR(edev)) {
> + ret = PTR_ERR(edev);
> + dev_err(>dev,
> + "failed to add devfreq-event device\n");
> + goto err;
> + }
> + }
> +
> + clk_prepare_enable(data->clk_ppmu);
> +
> + return 0;
> +err:
> + iounmap(data->ppmu.base);
> +
> + return ret;
> +}
> +
> +static int exynos_ppmu_remove(struct platform_device *pdev)
> +{
> + struct exynos_ppmu_data *data = platform_get_drvdata(pdev);
> + int i, ret = 0;
> +
> + for (i = 0; i < data->num_events; i++) {
> + ret = devfreq_event_remove_edev(data->edev[i]);
> + if (ret < 0) {
> + dev_err(>dev,
> + "failed to remove devfreq-event device\n");
> + goto err;
> + }
> + }
> +
> +err:
> + clk_disable_unprepare(data->clk_ppmu);
> + iounmap(data->ppmu.base);
> +
> + return ret;
> +}
> +
> +static struct of_device_id exynos_ppmu_id_match[] = {
> + { .compatible = "samsung,exynos-ppmu", },
> + { /* sentinel */ },
> +};
> +
> +static struct platform_driver exynos_ppmu_driver = {
> + .probe = exynos_ppmu_probe,
> + .remove = exynos_ppmu_remove,
> + .driver = {
> + .name = "exynos-ppmu",
> + .owner = THIS_MODULE,
remove owner field. It will be populate by driver core.
> + .of_match_table = exynos_ppmu_id_match,
> + },
> +};
> +module_platform_driver(exynos_ppmu_driver);
> +
> +MODULE_DESCRIPTION("Exynos PPMU(Platform Performance Monitoring Unit)
> driver");
> +MODULE_AUTHOR("Chanwoo Choi ");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:exynos-ppmu");
> --
> 1.8.5.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at
[PATCHv5 3/9] devfreq: event: Add exynos-ppmu devfreq-event driver
This patch adds exynos-ppmu devfreq-event driver to get performance data
of each IP for Samsung Exynos SoC. These event from Exynos PPMU provide
useful information about the behavior of the SoC that you can use when
analyzing system performance, and made visible and can be counted using
logic in each IP.
This patch is based on existing drivers/devfreq/exynos/exynos-ppmu.c
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/event/Kconfig | 9 +
drivers/devfreq/event/Makefile | 1 +
drivers/devfreq/event/exynos-ppmu.c | 397
3 files changed, 407 insertions(+)
create mode 100644 drivers/devfreq/event/exynos-ppmu.c
diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index 1ced42c..a11720a 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -13,4 +13,13 @@ menuconfig PM_DEVFREQ_EVENT
if PM_DEVFREQ_EVENT
+config DEVFREQ_EVENT_EXYNOS_PPMU
+ bool "EXYNOS PPMU (Platform Performance Monitoring Unit) DEVFREQ event
Driver"
+ depends on ARCH_EXYNOS
+ select PM_OPP
+ help
+ This add the devfreq-event driver for Exynos SoC. It provides PPMU
+ (Platform Performance Monitoring Unit) counters to estimate the
+ utilization of each module.
+
endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index dc56005..be146ea 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -1 +1,2 @@
# Exynos DEVFREQ Event Drivers
+obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
diff --git a/drivers/devfreq/event/exynos-ppmu.c
b/drivers/devfreq/event/exynos-ppmu.c
new file mode 100644
index 000..f002425
--- /dev/null
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -0,0 +1,397 @@
+/*
+ * exynos_ppmu.c - EXYNOS PPMU (Platform Performance Monitoring Unit) support
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This driver is based on drivers/devfreq/exynos/exynos_ppmu.c
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PPMU_ENABLE BIT(0)
+#define PPMU_DISABLE0x0
+#define PPMU_CYCLE_RESETBIT(1)
+#define PPMU_COUNTER_RESET BIT(2)
+
+#define PPMU_ENABLE_COUNT0 BIT(0)
+#define PPMU_ENABLE_COUNT1 BIT(1)
+#define PPMU_ENABLE_COUNT2 BIT(2)
+#define PPMU_ENABLE_COUNT3 BIT(3)
+#define PPMU_ENABLE_CYCLE BIT(31)
+
+#define PPMU_CNTENS0x10
+#define PPMU_FLAG 0x50
+#define PPMU_CCNT_OVERFLOW BIT(31)
+#define PPMU_CCNT 0x100
+
+#define PPMU_PMCNT00x110
+#define PPMU_PMCNT_OFFSET 0x10
+#define PMCNT_OFFSET(x)(PPMU_PMCNT0 + (PPMU_PMCNT_OFFSET * x))
+
+#define PPMU_BEVT0SEL 0x1000
+#define PPMU_BEVTSEL_OFFSET0x100
+#define PPMU_BEVTSEL(x)(PPMU_BEVT0SEL + (x *
PPMU_BEVTSEL_OFFSET))
+
+#define RD_DATA_COUNT 0x5
+#define WR_DATA_COUNT 0x6
+#define RDWR_DATA_COUNT0x7
+
+enum ppmu_counter {
+ PPMU_PMNCNT0 = 0,
+ PPMU_PMNCNT1,
+ PPMU_PMNCNT2,
+ PPMU_PMNCNT3,
+
+ PPMU_PMNCNT_MAX,
+};
+
+struct exynos_ppmu_data {
+ struct devfreq_event_dev **edev;
+ struct devfreq_event_desc *desc;
+ unsigned int num_events;
+
+ struct device *dev;
+ struct clk *clk_ppmu;
+ struct mutex lock;
+
+ struct __exynos_ppmu {
+ void __iomem *base;
+ unsigned int event[PPMU_PMNCNT_MAX];
+ unsigned int count[PPMU_PMNCNT_MAX];
+ bool ccnt_overflow;
+ bool count_overflow[PPMU_PMNCNT_MAX];
+ } ppmu;
+};
+
+#define PPMU_EVENT(name) \
+ { "ppmu-event0-"#name, PPMU_PMNCNT0 }, \
+ { "ppmu-event1-"#name, PPMU_PMNCNT1 }, \
+ { "ppmu-event2-"#name, PPMU_PMNCNT2 }, \
+ { "ppmu-event3-"#name, PPMU_PMNCNT3 }
+
+struct __exynos_ppmu_events {
+ char *name;
+ int id;
+} ppmu_events[] = {
+ /* For Exynos3250, Exynos4 and Exynos5260 */
+ PPMU_EVENT(g3d),
+ PPMU_EVENT(fsys),
+
+ /* For Exynos4 SoCs and Exynos3250 */
+ PPMU_EVENT(dmc0),
+ PPMU_EVENT(dmc1),
+ PPMU_EVENT(cpu),
+ PPMU_EVENT(rightbus),
+ PPMU_EVENT(leftbus),
+ PPMU_EVENT(lcd0),
+ PPMU_EVENT(camif),
+
+ /* Only for Exynos3250 and Exynos5260 */
+ PPMU_EVENT(mfc),
+
+ /* Only for Exynos4 SoCs */
+ PPMU_EVENT(mfc-left),
+ PPMU_EVENT(mfc-right),
+
+ /* Only for Exynos5260 SoCs */
+ PPMU_EVENT(drex0-s0),
+ PPMU_EVENT(drex0-s1),
+ PPMU_EVENT(drex1-s0),
+
[PATCHv5 7/9] ARM: dts: Add PPMU dt node for Exynos5260 SoC
This patch adds PPMU (Performance Profiling Monitoring Unit) dt node
Exynos5260 SoC.
Exynos5260 SoC has following PPMU IPs:
- PPMU_DREX0_S0 0x10c6
- PPMU_DREX0_S1 0x10c7
- PPMU_DREX1_S0 0x10c8
- PPMU_DREX1_S1 0x10c9
- PPMU_EAGLE0x10cc
- PPMU_KFC 0x10cd
- PPMU_MFC 0x1104
- PPMU_G3D 0x1188
- PPMU_FSYS 0x1222
- PPMU_ISP 0x1337
- PPMU_FICM 0x13cb
- PPMU_GSCL 0x13e6
- PPMU_MSCL 0x13ee
- PPMU_FIMD0X 0x145b
- PPMU_FIMD1X 0x145c
The drivers/devfreq/exynos/exynos5_bus.c supports the memory bus frequency/
voltage scaling of Exynos5260 SoC with DEVFREQ framework.
Cc: Kukjin Kim
Cc: Abhilash Kesavan
Cc: Jonghwan Choi
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos5260.dtsi | 90 +++
1 file changed, 90 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5260.dtsi
b/arch/arm/boot/dts/exynos5260.dtsi
index 36da38e..26f3074 100644
--- a/arch/arm/boot/dts/exynos5260.dtsi
+++ b/arch/arm/boot/dts/exynos5260.dtsi
@@ -307,6 +307,96 @@
fifo-depth = <64>;
status = "disabled";
};
+
+ ppmu_drex0_s0: ppmu_drex0_s0@10c6 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x10c6 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_drex0_s1: ppmu_drex0_s1@10c7 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x10c7 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_drex1_s0: ppmu_drex1_s0@10c8 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x10c8 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_drex1_s1: ppmu_drex1_s1@10c9 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x10c9 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_eagle: ppmu_eagle@10cc {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x10cc 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_kfc: ppmu_kfc@10cd {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x10cd 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_mfc: ppmu_mfc@1104 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1104 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_g3d: ppmu_g3d@1188 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1188 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_fsys: ppmu_fsys@1222 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1222 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_isp: ppmu_isp@1337 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1337 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_fimc: ppmu_fimc@13cb {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x13cb 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_gscl: ppmu_gscl@13e6 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x13e6 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_mscl: ppmu_gscl@13ee {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x13ee 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_fimd0x: ppmu_fimd0x@145b {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x145b 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_fimd1x: ppmu_fimd1x@145c {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x145c 0x2000>;
+ status = "disabled";
+ };
};
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 1/9] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
This patch add new devfreq_event class for devfreq_event device which provide raw data (e.g., memory bus utilization/GPU utilization). This raw data from devfreq_event data would be used for the governor of devfreq subsystem. - devfreq_event device : Provide raw data for governor of existing devfreq device - devfreq device : Monitor device state and change frequency/voltage of device using the raw data from devfreq_event device The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) for Non-CPU Devices. The devfreq device would dertermine current device state using various governor (e.g., ondemand, performance, powersave). After completed determination of system state, devfreq device would change the frequency/voltage of devfreq device according to the result of governor. But, devfreq governor must need basic data which indicates current device state. Existing devfreq subsystem only consider devfreq device which check current system state and determine proper system state using basic data. There is no subsystem for device providing basic data to devfreq device. The devfreq subsystem must need devfreq_event device(data-provider device) for existing devfreq device. So, this patch add new devfreq_event class for devfreq_event device which read various basic data(e.g, memory bus utilization, GPU utilization) and provide measured data to existing devfreq device through standard APIs of devfreq_event class. The following description explains the feature of two kind of devfreq class: - devfreq class (existing) : devfreq consumer device use raw data from devfreq_event device for determining proper current system state and change voltage/frequency dynamically using various governors. - devfreq_event class (new) : Provide measured raw data to devfreq device for governor Cc: MyungJoo Ham Cc: Kyungmin Park Signed-off-by: Chanwoo Choi --- drivers/devfreq/Kconfig | 2 + drivers/devfreq/Makefile| 6 +- drivers/devfreq/devfreq-event.c | 466 drivers/devfreq/event/Kconfig | 16 ++ drivers/devfreq/event/Makefile | 1 + include/linux/devfreq-event.h | 170 +++ 6 files changed, 660 insertions(+), 1 deletion(-) create mode 100644 drivers/devfreq/devfreq-event.c create mode 100644 drivers/devfreq/event/Kconfig create mode 100644 drivers/devfreq/event/Makefile create mode 100644 include/linux/devfreq-event.h diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index faf4e70..21f8f17 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -87,4 +87,6 @@ config ARM_EXYNOS5_BUS_DEVFREQ It reads PPMU counters of memory controllers and adjusts the operating frequencies and voltages with OPP support. +source "drivers/devfreq/event/Kconfig" + endif # PM_DEVFREQ diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile index 16138c9..c449336 100644 --- a/drivers/devfreq/Makefile +++ b/drivers/devfreq/Makefile @@ -1,4 +1,5 @@ -obj-$(CONFIG_PM_DEVFREQ) += devfreq.o +obj-$(CONFIG_PM_DEVFREQ) += devfreq.o +obj-$(CONFIG_PM_DEVFREQ_EVENT) += devfreq-event.o obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) += governor_simpleondemand.o obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o @@ -7,3 +8,6 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o # DEVFREQ Drivers obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/ obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/ + +# DEVFREQ Event Drivers +obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/ diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c new file mode 100644 index 000..81448ba --- /dev/null +++ b/drivers/devfreq/devfreq-event.c @@ -0,0 +1,466 @@ +/* + * devfreq-event: a framework to provide raw data and events of devfreq devices + * + * Copyright (C) 2014 Samsung Electronics + * Author: Chanwoo Choi + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This driver is based on drivers/devfreq/devfreq.c. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +static struct class *devfreq_event_class; + +/* The list of all devfreq event list */ +static LIST_HEAD(devfreq_event_list); +static DEFINE_MUTEX(devfreq_event_list_lock); + +#define to_devfreq_event(DEV) container_of(DEV, struct devfreq_event_dev, dev) + +/** + * devfreq_event_enable_edev() - Enable the devfreq-event dev and increase + * the enable_count of devfreq-event dev. + * @edev : the devfreq-event device + * + * Note that this function increase the enable_count and enable the + * devfreq-event device. The devfreq-event device should be enabled
[PATCHv5 0/9] devfreq: Add devfreq-event class to provide raw data for devfreq device
This patchset add new devfreq_event class to provide raw data to determine current utilization of device which is used for devfreq governor. [Description of devfreq-event class] This patchset add new devfreq_event class for devfreq_event device which provide raw data (e.g., memory bus utilization/GPU utilization). This raw data from devfreq_event data would be used for the governor of devfreq subsystem. - devfreq_event device : Provide raw data for governor of existing devfreq device - devfreq device : Monitor device state and change frequency/voltage of device using the raw data from devfreq_event device The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling) for Non-CPU Devices. The devfreq device would dertermine current device state using various governor (e.g., ondemand, performance, powersave). After completed determination of system state, devfreq device would change the frequency/voltage of devfreq device according to the result of governor. But, devfreq governor must need basic data which indicates current device state. Existing devfreq subsystem only consider devfreq device which check current system state and determine proper system state using basic data. There is no subsystem for device providing basic data to devfreq device. The devfreq subsystem must need devfreq_event device(data-provider device) for existing devfreq device. So, this patch add new devfreq_event class for devfreq_event device which read various basic data(e.g, memory bus utilization, GPU utilization) and provide measured data to existing devfreq device through standard APIs of devfreq_event class. The following description explains the feature of two kind of devfreq class: - devfreq class (existing) : devfreq consumer device use raw data from devfreq_event device for determining proper current system state and change voltage/frequency dynamically using various governors. - devfreq_event class (new) : Provide measured raw data to devfreq device for governor Also, the devfreq-event device would support various type event as following: : DEVFREQ_EVENT_TYPE_RAW_DATA : DEVFREQ_EVENT_TYPE_UTILIZATION : DEVFREQ_EVENT_TYPE_BANDWIDTH : DEVFREQ_EVENT_TYPE_LATENCY [For example] If board dts includes PPMU_DMC0/DMC1/LEFTBUS/RIGHTBUS event node, would show following sysfs entry. Also devfreq driver(e.g., exynos4_bus.c) can get the instance of devfreq-event device by using provided API and then get raw data which reflect the current state of device. -sh-3.2# cd /sys/class/devfreq-event/ -sh-3.2# ls -al total 0 drwxr-xr-x 2 root root 0 Jan 9 16:47 . drwxr-xr-x 37 root root 0 Jan 9 16:47 .. lrwxrwxrwx 1 root root 0 Jan 9 16:47 event.0 -> ../../devices/soc/106a.ppmu_dmc0/devfreq-event/event.0 lrwxrwxrwx 1 root root 0 Jan 9 16:47 event.1 -> ../../devices/soc/106b.ppmu_dmc1/devfreq-event/event.1 lrwxrwxrwx 1 root root 0 Jan 9 16:47 event.2 -> ../../devices/soc/112a.ppmu_rightbus/devfreq-event/event.2 lrwxrwxrwx 1 root root 0 Jan 9 16:47 event.3 -> ../../devices/soc/116a.ppmu_leftbus0/devfreq-event/event.3 Changes from v4: 1. devfreq-event class driver - Add devfreq_event_get_edev_count() function - Modify the simple description of devfreq-event framework in devfreq-event.c - Minimize the usage range of global lock usage in devfreq_event_add_edev() - Remove '_is_enabled()' function pointer in devfreq_event_ops structure - Add separte CONFIG_PM_DEVFREQ_EVENT configuration - Add new devfreq-event.h header file including devfreq-event helper functions 2. exynos dts file - Add new patch to support PPMU with DEVFREQ-event on Exynos4412-based TRATS2 Changes from v3: 1. devfreq-event class driver - Fix return value of devfreq_event_get_event() - Add new structure devfreq_event_data for devfreq_event_get_event() - Modify the prototype of devfreq_event_get_event() function - Call of_node_put after calling of_parse_phandle() to decrement refcount 2. exynos-ppmu driver - Modify usage of devfreq_event_get_event() function according to new prototype of this funciton - Add the additional description to exynos-ppmu.txt how to add PPMU node in board dts file - Use 'PPMU_EVENT' macro to remove duplicate codes - Add the support of PPMU for Exynos5260 3. exynos dts file - Add missing PPMU_FSYS node to exynos3250.dtsi - Fix 'ppmu_mfc_l' node name as 'ppmu_mfc' because exynos3250 has only one MFC IP. - Add missing PPMU_ACP/G3D to exynos4.dtsi 4. etc - Fix wrong abbreviation of PPMU (PPMU :Platform Performance Monitoring Unit) - Add new patch to support the PPMU of Exynos5260 SoC Changes from v2: 1. devfreq-event class driver - Rename all the helper functions of devfreq-event device - Add devfreq_event_remove_edev() instead of devfreq_put_event_dev() - Add devfreq_event_release_edev() to initialize it before put device - Add the detailed description of devfreq-event API - Add the attributes of devfreq-event class (enable_count) - Check the overflow
[PATCHv5 8/9] ARM: dts: exynos: Add PPMU node to Exynos3250-based Rinato board
This patch add PPMU dt node to Exynos3250-base Rinato board. The PPMU dt node
is used to get the utilization of DMC0/DMC1/LEFTBUS/RIGHTBUS Block.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250-rinato.dts | 40 +
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 7789442..11942b0 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -542,6 +542,46 @@
status = "okay";
};
+_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
+_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+};
+
+_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+};
+
{
clock-frequency = <2400>;
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 5/9] ARM: dts: Add PPMU dt node for Exynos3250 SoC
This patch add PPMU (Platform Performance Monitoring Unit) dt node
to estimate the utilization of each IP in Exynos SoC throught DEVFREQ Event
subsystem.
This patch adds following PPMU dt nodes:
- PPMU_DMC0 0x106a
- PPMU_DMC1 0x106b
- PPMU_RIGHTBUS 0x112A
- PPMU_LEFTBUS 0x116A
- PPMU_CAMIF0x11AC
- PPMU_LCD0 0x11E4
- PPMU_FSYS 0x1263
- PPMU_3D 0x1322
- PPMU_MFC 0x1366
- PPMU_CPU 0x106c
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
---
arch/arm/boot/dts/exynos3250.dtsi | 72 +++
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index c743f60..f0322f2 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -529,6 +529,78 @@
compatible = "arm,cortex-a7-pmu";
interrupts = <0 18 0>, <0 19 0>;
};
+
+ ppmu_dmc0: ppmu_dmc0@106a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106a 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_dmc1: ppmu_dmc1@106b {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106b 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_cpu: ppmu_cpu@106c {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106c 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_rightbus: ppmu_rightbus@112a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x112a 0x2000>;
+ clocks = < CLK_PPMURIGHT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_leftbus: ppmu_leftbus0@116a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x116a 0x2000>;
+ clocks = < CLK_PPMULEFT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_camif: ppmu_camif@11ac {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11ac 0x2000>;
+ clocks = < CLK_PPMUCAMIF>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_lcd0: ppmu_lcd0@11e4 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11e4 0x2000>;
+ clocks = < CLK_PPMULCD0>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_fsys: ppmu_fsys@1263 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1263 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_g3d: ppmu_g3d@1322 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1322 0x2000>;
+ clocks = < CLK_PPMUG3D>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_mfc: ppmu_mfc@1366 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1366 0x2000>;
+ clocks = < CLK_PPMUMFC_L>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
};
};
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 9/9] ARM: dts: exynos: Add PPMU_CPU/DMC0/DMC1 node for Exynos4412-based TRATS2 board
This patch add dt node for PPMU_CPU/DMC0/DMC1 for exynos4412-trats2 board.
Each PPMU dt node includes one event of 'PPMU Count 3'
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4412-trats2.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index dd9ac66..9b98258 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -811,6 +811,36 @@
};
};
+_cpu {
+ status = "okay";
+
+ events {
+ ppmu_cpu_3: ppmu-event3-cpu {
+ event-name = "ppmu-event3-cpu";
+ };
+ };
+};
+
+_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
_0 {
pinctrl-names = "default";
pinctrl-0 = <>;
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 2/9] devfreq: event: Add the list of supported devfreq-event type
This patch adds the list of supported devfreq-event type as following.
Each devfreq-event device driver would support the various devfreq-event type
for devfreq governor at the same time.
- DEVFREQ_EVENT_TYPE_RAW_DATA
- DEVFREQ_EVENT_TYPE_UTILIZATION
- DEVFREQ_EVENT_TYPE_BANDWIDTH
- DEVFREQ_EVENT_TYPE_LATENCY
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/devfreq-event.c | 58 -
include/linux/devfreq-event.h | 25 +++---
2 files changed, 73 insertions(+), 10 deletions(-)
diff --git a/drivers/devfreq/devfreq-event.c b/drivers/devfreq/devfreq-event.c
index 81448ba..64c1764 100644
--- a/drivers/devfreq/devfreq-event.c
+++ b/drivers/devfreq/devfreq-event.c
@@ -20,6 +20,9 @@
#include
#include
+#define EVENT_TYPE_RAW_DATA_MAXULONG_MAX
+#define EVENT_TYPE_UTILIZATION_MAX 100
+
static struct class *devfreq_event_class;
/* The list of all devfreq event list */
@@ -132,7 +135,8 @@ EXPORT_SYMBOL_GPL(devfreq_event_is_enabled);
* Note that this function set the event to the devfreq-event device to start
* for getting the event data which could be various event type.
*/
-int devfreq_event_set_event(struct devfreq_event_dev *edev)
+int devfreq_event_set_event(struct devfreq_event_dev *edev,
+ enum devfreq_event_type type)
{
int ret;
@@ -146,7 +150,15 @@ int devfreq_event_set_event(struct devfreq_event_dev *edev)
return -EPERM;
mutex_lock(>lock);
- ret = edev->desc->ops->set_event(edev);
+
+ if ((edev->desc->type & type) == 0) {
+ dev_err(>dev, "unsupported devfreq-event type\n");
+ mutex_unlock(>lock);
+ return -EINVAL;
+ }
+
+ ret = edev->desc->ops->set_event(edev, type);
+
mutex_unlock(>lock);
return ret;
@@ -162,6 +174,7 @@ EXPORT_SYMBOL_GPL(devfreq_event_set_event);
* after stoping the progress of whole sequence of devfreq-event dev.
*/
int devfreq_event_get_event(struct devfreq_event_dev *edev,
+ enum devfreq_event_type type,
struct devfreq_event_data *edata)
{
int ret;
@@ -175,18 +188,49 @@ int devfreq_event_get_event(struct devfreq_event_dev
*edev,
if (!devfreq_event_is_enabled(edev))
return -EINVAL;
+ mutex_lock(>lock);
+
+ if ((edev->desc->type & type) == 0) {
+ dev_err(>dev, "unsupported devfreq-event type\n");
+ return -EINVAL;
+ }
+
edata->event = edata->total_event = 0;
+ ret = edev->desc->ops->get_event(edev, type, edata);
+ if (ret < 0
+ || edata->total_event <= 0
+ || edata->event > edata->total_event) {
+ edata->event = edata->total_event = 0;
+ mutex_unlock(>lock);
+ return -EINVAL;
+ }
- mutex_lock(>lock);
- ret = edev->desc->ops->get_event(edev, edata);
- mutex_unlock(>lock);
+ switch (type) {
+ case DEVFREQ_EVENT_TYPE_RAW_DATA:
+ case DEVFREQ_EVENT_TYPE_BANDWIDTH:
+ case DEVFREQ_EVENT_TYPE_LATENCY:
+ if ((edata->event > EVENT_TYPE_RAW_DATA_MAX) ||
+ (edata->total_event > EVENT_TYPE_RAW_DATA_MAX)) {
+ edata->event = edata->total_event = 0;
+ ret = -EINVAL;
+ }
+ break;
+ case DEVFREQ_EVENT_TYPE_UTILIZATION:
+ edata->total_event = EVENT_TYPE_UTILIZATION_MAX;
- if ((edata->total_event <= 0)
- || (edata->event > edata->total_event)) {
+ if (edata->event > EVENT_TYPE_UTILIZATION_MAX) {
+ edata->event = edata->total_event = 0;
+ ret = -EINVAL;
+ }
+ break;
+ default:
edata->event = edata->total_event = 0;
ret = -EINVAL;
+ break;
}
+ mutex_unlock(>lock);
+
return ret;
}
EXPORT_SYMBOL_GPL(devfreq_event_get_event);
diff --git a/include/linux/devfreq-event.h b/include/linux/devfreq-event.h
index ac426d5..1a87a16 100644
--- a/include/linux/devfreq-event.h
+++ b/include/linux/devfreq-event.h
@@ -36,6 +36,14 @@ struct devfreq_event_dev {
const struct devfreq_event_desc *desc;
};
+/* The supported type by devfreq-event device */
+enum devfreq_event_type {
+ DEVFREQ_EVENT_TYPE_RAW_DATA = BIT(0),
+ DEVFREQ_EVENT_TYPE_UTILIZATION = BIT(1),
+ DEVFREQ_EVENT_TYPE_BANDWIDTH= BIT(2),
+ DEVFREQ_EVENT_TYPE_LATENCY = BIT(3),
+};
+
/**
* struct devfreq_event_data - the devfreq-event data
*
@@ -69,8 +77,10 @@ struct devfreq_event_ops {
int (*reset)(struct devfreq_event_dev *edev);
/* Mandatory functions */
- int (*set_event)(struct devfreq_event_dev *edev);
+ int (*set_event)(struct
[PATCHv5 4/9] devfreq: event: Add documentation for exynos-ppmu devfreq-event driver
This patch adds the documentation for Exynos PPMU (Platform Performance
Monitoring Unit) devfreq-event driver.
Cc: MyungJoo Ham
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
.../bindings/devfreq/event/exynos-ppmu.txt | 110 +
1 file changed, 110 insertions(+)
create mode 100644
Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
new file mode 100644
index 000..e665d30
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -0,0 +1,110 @@
+
+* Samsung Exynos PPMU (Performance Profiling Monitoring Unit) device
+
+The Samsung Exynos SoC have PPMU (Performance Profiling Monitoring Unit) for
+each IPs. PPMU provides the primitive values to get performance data. These
+events provide useful information about the behavior of the SoC that you can
+use when analyzing system performance, and made visible and can be counted
+using login in each IP (DMC, CPU, RIGHTBUS, LEFTBUS, CAM interface, LCD, G3D,
+MFC). The Exynos PPMU driver use the devfreq-event class to provide event data
+to various devfreq device. The devfreq device would use the event data when
+derterming the current state of each IP.
+
+Required properties:
+- compatible: Should be "samsung,exynos-ppmu".
+- reg: physical base address of each PPMU and length of memory mapped region.
+
+Optional properties:
+- clock-names : the name of clock used by the PPMU, "ppmu"
+- clocks : phandles for clock specified in "clock-names" property
+- #clock-cells: should be 1.
+
+Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+
+ ppmu_dmc0: ppmu_dmc0@106a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106a 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_dmc1: ppmu_dmc1@106b {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106b 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_cpu: ppmu_cpu@106c {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106c 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_rightbus: ppmu_rightbus@112a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x112a 0x2000>;
+ clocks = < CLK_PPMURIGHT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_leftbus: ppmu_leftbus0@116a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x116a 0x2000>;
+ clocks = < CLK_PPMULEFT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below.
+
+ _dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+
+ ppmu_dmc0_2: ppmu-event2-dmc0 {
+ event-name = "ppmu-event2-dmc0";
+ };
+
+ ppmu_dmc0_1: ppmu-event1-dmc0 {
+ event-name = "ppmu-event1-dmc0";
+ };
+
+ ppmu_dmc0_0: ppmu-event0-dmc0 {
+ event-name = "ppmu-event0-dmc0";
+ };
+ };
+ };
+
+ _dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+ };
+
+ _leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+ };
+
+ _rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+ };
+ };
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 6/9] ARM: dts: Add PPMU dt node for Exynos4 SoCs
This patch add PPMU (Platform Performance Monitoring Unit) dt node for Exynos4
(Exynos4210/4212/4412) SoC. PPMU dt node is used to monitor the utilization of
each IP.
The Exynos4210/Exynos4212/Exynos4412 SoC includes following PPMUs:
- PPMU_DMC0 0x106A_
- PPMU_DMC1 0x106B_
- PPMU_CPU 0x106C_
- PPMU_ACP 0x10AE_
- PPMU_RIGHT_BUS 0x112A_
- PPMU_LEFT_BUS 0x116A_
- PPMU_FSYS 0x1263_
- PPMU_LCD0 0x11E4_
- PPMU_CAMIF 0x11AC_
- PPMU_IMAGE 0x12AA_
- PPMU_TV0x12E4_
- PPMU_3D0x1322_
- PPMU_MFC_LEFT 0x1366_
- PPMU_MFC_RIGHT 0x1367_
Additionally, the Exynos4210 SoC includes following PPMUs:
- PPMU_LCD1 0x1224_
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4.dtsi| 108 ++
arch/arm/boot/dts/exynos4210.dtsi | 8 +++
2 files changed, 116 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e0278ec..5a5e3ab 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -645,4 +645,112 @@
samsung,sysreg = <_reg>;
status = "disabled";
};
+
+ ppmu_dmc0: ppmu_dmc0@106a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106a 0x2000>;
+ clocks = < CLK_PPMUDMC0>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_dmc1: ppmu_dmc1@106b {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106b 0x2000>;
+ clocks = < CLK_PPMUDMC1>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_cpu: ppmu_cpu@106c {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106c 0x2000>;
+ clocks = < CLK_PPMUCPU>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_acp: ppmu_acp@10ae {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x106e 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_rightbus: ppmu_rightbus@112a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x112a 0x2000>;
+ clocks = < CLK_PPMURIGHT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_leftbus: ppmu_leftbus0@116a {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x116a 0x2000>;
+ clocks = < CLK_PPMULEFT>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_camif: ppmu_camif@11ac {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11ac 0x2000>;
+ clocks = < CLK_PPMUCAMIF>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_lcd0: ppmu_lcd0@11e4 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x11e4 0x2000>;
+ clocks = < CLK_PPMULCD0>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_fsys: ppmu_g3d@1263 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1263 0x2000>;
+ status = "disabled";
+ };
+
+ ppmu_image: ppmu_image@12aa {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x12aa 0x2000>;
+ clocks = < CLK_PPMUIMAGE>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_tv: ppmu_tv@12e4 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x12e4 0x2000>;
+ clocks = < CLK_PPMUTV>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_g3d: ppmu_g3d@1322 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1322 0x2000>;
+ clocks = < CLK_PPMUG3D>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_mfc_left: ppmu_mfc_left@1366 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1366 0x2000>;
+ clocks = < CLK_PPMUMFC_L>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
+
+ ppmu_mfc_right: ppmu_mfc_right@1367 {
+ compatible = "samsung,exynos-ppmu";
+ reg = <0x1367 0x2000>;
+ clocks = < CLK_PPMUMFC_R>;
+ clock-names = "ppmu";
+ status = "disabled";
+ };
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index bcc9e63..b2598de 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++
Re: [Gta04-owner] [PATCH 2/2] misc: add a driver to power on/off UART attached devices.
On Sat, 20 Dec 2014 17:02:04 +0100 Christ van Willegen wrote: > Hi, > > One remark: > > +config SERIAL_POWER_MANAGER > + tristate "Power Management controller for serial-attached devices" > + depends on TTY && OF > + default n > + help > + Some devices permanently attached via a UART can benefit from > + being power-managed when the tty device is openned or closed. > + This driver can support several such devices with simple > + power requirements such as enabling a regulator. > + > + If in doubt, say 'N' > + > > There's a typo: openned. Thanks - I've fix that now. NeilBrown pgpTAIvFNJyBF.pgp Description: OpenPGP digital signature
Re: [PATCH] tools: lib: traceevent: event-parse.c: Remove some unused functions
Hi Arnaldo and Rickard, On Mon, Dec 22, 2014 at 12:52:10PM -0200, Arnaldo Carvalho de Melo wrote: > Em Sat, Dec 20, 2014 at 01:45:41PM +0100, Rickard Strandqvist escreveu: > > Removes some functions that are not used anywhere: > > pevent_get_any_field_val() pevent_get_common_field_val() > > pevent_event_fields() pevent_event_common_fields() pevent_list_events() > > pevent_print_event() pevent_data_event_from_type() > > pevent_register_trace_clock() pevent_pid_is_registered() > > > > This was partially found by using a static code analysis program called > > cppcheck. > > Steven, Namhyung, Jiri: > > Are you ok with me applying this patch? I'm all for it, dead code better > be removed, but I don't know what are your plans wrt synchronization > with the trace-cmd repo. They're used by trace-cmd.. Currently Steve backports changes in libtraceevent to trace-cmd repo occasionally but it eventually will be a generic standalone library so I'd like to keep the APIs. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[hwrng] WARNING: CPU: 0 PID: 1 at include/linux/kref.h:47 set_current_rng()
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master commit 3a2c0ba5ad00c018c0bef39a2224aca950aa33f2 Author: Rusty Russell AuthorDate: Mon Dec 8 16:50:37 2014 +0800 Commit: Herbert Xu CommitDate: Mon Dec 22 23:02:39 2014 +1100 hwrng: use reference counts on each struct hwrng. current_rng holds one reference, and we bump it every time we want to do a read from it. This means we only hold the rng_mutex to grab or drop a reference, so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't block on read of /dev/hwrng. Using a kref is overkill (we're always under the rng_mutex), but a standard pattern. This also solves the problem that the hwrng_fillfn thread was accessing current_rng without a lock, which could change (eg. to NULL) underneath it. Signed-off-by: Rusty Russell Signed-off-by: Amos Kong Signed-off-by: Herbert Xu +++++ || 1dacb395d6 | 3a2c0ba5ad | 02e375a39e | +++++ | boot_successes | 60 | 0 | 0 | | boot_failures | 0 | 20 | 12 | | WARNING:at_include/linux/kref.h:#set_current_rng() | 0 | 20 | 12 | | backtrace:hwrng_register | 0 | 20 | 12 | | backtrace:rng_init | 0 | 20 | 12 | | backtrace:kernel_init_freeable | 0 | 20 | 12 | | Out_of_memory:Kill_process | 0 | 0 | 1 | +++++ [0.408729] Initializing Nozomi driver 2.1d [0.410251] Non-volatile memory driver v1.3 [0.411671] [ cut here ] [0.413180] WARNING: CPU: 0 PID: 1 at include/linux/kref.h:47 set_current_rng+0x62/0x70() [0.416125] Modules linked in: [0.417407] CPU: 0 PID: 1 Comm: swapper Not tainted 3.19.0-rc1-g3a2c0ba #38 [0.419428] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [0.421136] 81a21a30 880013857de8 816f758d 880013857e28 [0.424127] 8107ce9a 880013857e38 81c661c0 880011caae10 [0.426581] 81c661c0 81d129f1 880013857e38 [0.429174] Call Trace: [0.430154] [] dump_stack+0x19/0x1b [0.431748] [] warn_slowpath_common+0x7a/0xb0 [0.433367] [] ? mod_init+0x12b/0x12b [0.434353] [] warn_slowpath_null+0x15/0x20 [0.435558] [] set_current_rng+0x62/0x70 [0.436957] [] hwrng_register+0x1c7/0x290 [0.437944] [] rng_init+0x10/0x12 [0.439449] [] do_one_initcall+0x84/0x1c0 [0.440413] [] kernel_init_freeable+0xfd/0x185 [0.441653] [] ? rest_init+0x80/0x80 [0.442925] [] kernel_init+0x9/0xf0 [0.444286] [] ret_from_fork+0x7a/0xb0 [0.445536] [] ? rest_init+0x80/0x80 [0.446958] ---[ end trace 34fb80111662e761 ]--- [0.447923] Linux agpgart interface v0.103 git bisect start 02e375a39e183e3f08e12de435a1970b78c4174c 97bf6af1f928216fd6c5a66e8a57bfa95a659672 -- git bisect good 8a29ac1839a7d7d6f680617f870045ce58be3712 # 06:41 20+ 0 Merge 'asoc/topic/omap' into devel-lkp-nhm1-smoke-201412230619 git bisect good 5d49b0ab0d9968efbf70afe11f9fffe7d86e21d1 # 06:49 20+ 0 Merge 'perf/perf/core' into devel-lkp-nhm1-smoke-201412230619 git bisect good 04b5f77135fd1646b65d9e73733e61859cf72add # 06:56 20+ 0 Merge 'ard.biesheuvel/efi-for-3.20' into devel-lkp-nhm1-smoke-201412230619 git bisect bad c50aef250e8f1ff63132fd1d1a919b6774ff8635 # 06:59 0- 1 Merge 'asoc/topic/wm8750' into devel-lkp-nhm1-smoke-201412230619 git bisect good 8505c1fd22b13ebe27a4f76ab0db8dba9b10260a # 07:07 20+ 0 Merge 'hid/for-next' into devel-lkp-nhm1-smoke-201412230619 git bisect bad f1954fab801041ec34f97557b8482bb3f2ea2a8d # 07:15 0- 13 Merge 'cryptodev/master' into devel-lkp-nhm1-smoke-201412230619 git bisect good 9372b35e11149c5314f56f939775e67d83057604 # 07:23 20+ 0 hwrng: place mutex around read functions and buffers. git bisect bad 2d2ec0642a85966b6a299bbcd94707982327ace8 # 07:26 0- 20 hwrng: don't init list element we're about to add to list. git bisect bad 3a2c0ba5ad00c018c0bef39a2224aca950aa33f2 # 07:31 0- 20 hwrng: use reference counts on each struct hwrng. git bisect good 1dacb395d68a14825ee48c0843335e3181aea675 # 07:38 20+ 0 hwrng: move some code out mutex_lock for
[LKP] [ftrace] fef5aeeee9e: -27.2% boot-slabinfo.num_objs
FYI, we noticed the below changes on
commit fef5a9e3717e7aea991a7ae9ff6a7a2d4c85 ("ftrace: Replace tramp_hash
with old_*_hash to save space")
testbox/testcase/testparams: vm-kbuild-4G/boot/1
e1effa0144a1ddf5 fef5a9e3717e7aea991a7a
--
%stddev %change %stddev
\ |\
437752 ± 0% -27.2% 318545 ± 0% boot-slabinfo.num_objs
vm-kbuild-4G: qemu-system-x86_64 -enable-kvm
Memory: 4G
boot-slabinfo.num_objs
44 *+*--*-*-*--**-*-*--**-*--*-*-*--*-+
| *.* *. *.*..* |
42 ++ |
| |
40 ++ |
| |
38 ++ |
| |
36 ++ |
| |
34 ++ |
| |
32 O+O O O O O O O O O O O OO O OO O O O O O O O O O O
| OO O|
30 ++-+
[*] bisect-good sample
[O] bisect-bad sample
To reproduce:
apt-get install ruby ruby-oj
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/setup-local job.yaml # the job file attached in this email
bin/run-local job.yaml
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Huang, Ying
---
testcase: boot
default_monitors:
boottime:
kernel-size:
default_watchdogs:
watch-oom:
watchdog:
cpufreq_governor:
model: qemu-system-x86_64 -enable-kvm
nr_vm: 8
nr_cpu: 4
memory: 4G
rootfs: debian-x86_64.cgz
hdd_partitions: "/dev/vda /dev/vdb /dev/vdc /dev/vdd"
swap_partitions: "/dev/vde"
boot-meminfo:
boot-slabinfo:
boot-memory:
memmap:
bootmem:
sleep: 1
branch: linus/master
commit: b2776bf7149bddd1f4161f14f79520f17fc1d71d
testbox: vm-kbuild-4G-1
tbox_group: vm-kbuild-4G
kconfig: x86_64-allyesdebian
enqueue_time: 2014-12-15 07:00:22.267392531 +08:00
kernel:
"/kernel/x86_64-allyesdebian/b2776bf7149bddd1f4161f14f79520f17fc1d71d/vmlinuz-3.18.0"
user: lkp
queue: rand
result_root:
"/result/vm-kbuild-4G/boot/1/debian-x86_64.cgz/x86_64-allyesdebian/b2776bf7149bddd1f4161f14f79520f17fc1d71d/0"
job_file:
"/lkp/scheduled/vm-kbuild-4G-1/rand_boot-1-debian-x86_64.cgz-x86_64-allyesdebian-b2776bf7149bddd1f4161f14f79520f17fc1d71d-0.yaml"
dequeue_time: 2014-12-15 07:01:52.92900 +08:00
job_state: finished
loadavg: 2.54 1.47 0.58 2/196 5734
start_time: '1418598302'
end_time: '1418598303'
version: "/lkp/lkp/.src-20141214-133531"
___
LKP mailing list
l...@linux.intel.com
RE: [RFC PATCH] f2fs: add extent cache base on rb-tree
Hi Jaegeuk, > -Original Message- > From: Jaegeuk Kim [mailto:jaeg...@kernel.org] > Sent: Tuesday, December 23, 2014 7:16 AM > To: Chao Yu > Cc: 'Changman Lee'; linux-f2fs-de...@lists.sourceforge.net; > linux-kernel@vger.kernel.org > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > Hi Chao, > > On Mon, Dec 22, 2014 at 03:10:30PM +0800, Chao Yu wrote: > > Hi Changman, > > > > > -Original Message- > > > From: Changman Lee [mailto:cm224@samsung.com] > > > Sent: Monday, December 22, 2014 10:03 AM > > > To: Chao Yu > > > Cc: Jaegeuk Kim; linux-f2fs-de...@lists.sourceforge.net; > > > linux-kernel@vger.kernel.org > > > Subject: Re: [RFC PATCH] f2fs: add extent cache base on rb-tree > > > > > > Hi Yu, > > > > > > Good approach. > > > > Thank you. :) > > > > > As you know, however, f2fs breaks extent itself due to COW. > > > > Yes, and sometimes f2fs use IPU when override writing, in this condition, > > by using this approach we can cache more contiguous mapping extent for > > better > > performance. > > Hmm. When f2fs faces with this case, there is no chance to make an extent > itself > at all. With new implementation of this patch f2fs will build extent cache when readpage/readpages. > > > > > > Unlike other filesystem like btrfs, minimum extent of f2fs could have 4KB > > > granularity. > > > So we would have lots of extents per inode and it could lead to overhead > > > to manage extents. > > > > Agree, the more number of extents are growing in one inode, the more memory > > pressure and longer latency operating in rb-tree we are facing. > > IMO, to solve this problem, we'd better to add limitation or shrink ability > > into > > extent cache: > > 1.limit extent number per inode with the value set from sysfs and discard > > extent > > from inode's extent lru list if we touch the limitation; (e.g. in FAT, max > > number > > of mapping extent per inode is fixed: 8) > > 2.add all extents of inodes into a global lru list, we will try to shrink > > this list > > if we're facing memory pressure. > > > > How do you think? or any better ideas are welcome. :) > > Historically, the reason that I added only one small extent cache is that I > wanted to avoid additional data structures having any overhead in critical > data > write path. Thank you for telling me the history of original extent cache. > Instead, I intended to use a well operating node page cache. > > We need to consider what would be the benefit when using extent cache rather > than existing node page cache. IMO, node page cache belongs to system level cache, filesystem sub system can not control it completely, cached uptodate node page will be invalidated by using drop_caches from sysfs, or reclaimer of mm, result in more IO when we need these node page next time. New extent cache belongs to filesystem level cache, it is completely controlled by filesystem itself. What we can profit is: on the one hand, it is used as first level cache above the node page cache, which can also increase the cache hit ratio. On the other hand, it is more instable and controllable than node page cache. Thanks, Yu > > Thanks, > > > > > > > > > Anyway, mount option could be alternative for this patch. > > > > Yes, will do. > > > > Thanks, > > Yu > > > > > > > > On Fri, Dec 19, 2014 at 06:49:29PM +0800, Chao Yu wrote: > > > > Now f2fs have page-block mapping cache which can cache only one extent > > > > mapping > > > > between contiguous logical address and physical address. > > > > Normally, this design will work well because f2fs will expand coverage > > > > area of > > > > the mapping extent when we write forward sequentially. But when we > > > > write data > > > > randomly in Out-Place-Update mode, the extent will be shorten and > > > > hardly be > > > > expanded for most time as following reasons: > > > > 1.The short part of extent will be discarded if we break contiguous > > > > mapping in > > > > the middle of extent. > > > > 2.The new mapping will be added into mapping cache only at head or tail > > > > of the > > > > extent. > > > > 3.We will drop the extent cache when the extent became very fragmented. > > > > 4.We will not update the extent with mapping which we get from > > > > readpages or > > > > readpage. > > > > > > > > To solve above problems, this patch adds extent cache base on rb-tree > > > > like other > > > > filesystems (e.g.: ext4/btrfs) in f2fs. By this way, f2fs can support > > > > another > > > > more effective cache between dnode page cache and disk. It will supply > > > > high hit > > > > ratio in the cache with fewer memory when dnode page cache are > > > > reclaimed in > > > > environment of low memory. > > > > > > > > Todo: > > > > *introduce mount option for extent cache. > > > > *add shrink ability for extent cache. > > > > > > > > Signed-off-by: Chao Yu > > > > --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
[PATCH V2] vfio-pci: Fix the check on pci device type in vfio_pci_probe()
Current vfio-pci just supports normal pci device, so vfio_pci_probe() will
return if the pci device is not a normal device. While current code makes a
mistake. PCI_HEADER_TYPE is the offset in configuration space of the device
type, but we use this value to mask the type value.
This patch fixs this by do the check directly on the pci_dev->hdr_type.
Signed-off-by: Wei Yang
V2:
* Fix the problem by checking pci_dev->hdr_type
---
drivers/vfio/pci/vfio_pci.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 9558da3..2f8a055 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -839,13 +839,11 @@ static const struct vfio_device_ops vfio_pci_ops = {
static int vfio_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
- u8 type;
struct vfio_pci_device *vdev;
struct iommu_group *group;
int ret;
- pci_read_config_byte(pdev, PCI_HEADER_TYPE, );
- if ((type & PCI_HEADER_TYPE) != PCI_HEADER_TYPE_NORMAL)
+ if (pdev->hdr_type != PCI_HEADER_TYPE_NORMAL)
return -EINVAL;
group = iommu_group_get(>dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4 v3] scsi:stex.c Add reboot support
On 12/18/2014 11:41 AM, Charles Chiou wrote: On 12/17/2014 05:30 PM, Christoph Hellwig wrote: I'm not going to add a new reboot notifier for a driver. If you can convince the driver model / PM people to pass this information to ->shutdown we can add support for this difference, but not in this way. Can you send me a series that just adds the hardware support for now, so we can dash this PM issue out separately? Hi, we need to provide this information to our device. We face the HW signal issue on various motherboards. We experiment on many motherboards, and we observe that the restart signal is different on different motherboard. If device misses the signal, PCI loss or volume disappearance might happen. To make power management easier, driver provide the shutdown or reboot information to the device. Sorry, I'm not understand what is meaning of "series". Could you specify what you what me to send you? Thank you BRS Charles Hi, after our internal discussion, we can use shutdown flow for reboot temporarily. Some signal issue will happen (depend on MB), and it can be fixed by plug in and plug out manually. We will add reboot feature after PM can pass reboot information to ->shutdown. BRS Charles -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tick/powerclamp: Remove tick_nohz_idle abuse
On Sat, 20 Dec 2014 07:01:12 +0530 Preeti U Murthy wrote: > On 12/20/2014 01:26 AM, Thomas Gleixner wrote: > > On Fri, 19 Dec 2014, Jacob Pan wrote: > > > >> On Thu, 18 Dec 2014 22:12:57 +0100 (CET) > >> Thomas Gleixner wrote: > >> > >>> On Thu, 18 Dec 2014, Jacob Pan wrote: > OK I agree, also as I mentioned earlier, Peter already has a > patch for consolidated idle loop and remove > tick_nohz_idle_enter/exit call from powerclamp driver. I have > been working on a few tweaks to maintain the functionality and > efficiency with the consolidated idle loop. We can apply the > patches on top of yours. > >>> > >>> No. This is equally wrong as I pointed out before. The 'unified' > >>> idle loop is still fake and just pretending to be idle. > >>> > >> In terms of efficiency, the consolidated idle loop will allow > >> turning off sched tick during idle injection period. If we just > >> take out the tick_nohz_idle_xxx call, the effectiveness of > >> powerclamp is going down significantly. I am not arguing the > >> design but from fixing regression perspective or short term > >> solution. > > > > There is no perspective. Period. > > > > Its violates every rightful assumption of the nohz_IDLE_* code and > > just ever worked by chance. There is so much subtle wreckage lurking > > there that the only sane solution is to forbid it. End of story. > > > > Thanks, > > > > tglx > > > Hi Jacob, > > Like Thomas pointed out, we can design a sane solution for powerclamp. > Idle injection is nothing but throttling of runqueue. If the runqueue > is throttled, no fair tasks will be selected and the natural choice > in the absence of tasks from any other sched class is the idle task. > > The idle loop will automatically be called and the nohz state will > also fall in place. The cpu is really idle now: the runqueue has no > tasks and the task running on the cpu is the idle thread. The > throttled tasks are on a separate list. > > When the period of idle injection is over, we unthrottle the runqueue. > All this being taken care of my a non-deferrable timer. This design > ensures that the intention of powerclamp is not hampered while at the > same time maintaining a sane state for nohz; you will get the > efficiency you want. > > Of course there may be corner cases and challenges around > synchronization of package idle, which I am sure we can work around > with a better design such as the above. I am working on that patchset > and will post out in a day. You can take a look and let us know the > pieces we are missing. > > I find that implementing the above design is not too hard. > Hi Preeti, Yeah, it seems to be a good approach. looking forward to work with you on this. Timer may scale better for larger systems. One question, will timer irq gets unpredictable delays if run by ksoftirqd? BTW, I may not be able to respond quickly during the holidays. If things workout, it may benefit ACPI PAD driver as well. Thanks, Jacob > Regards > Preeti U Murthy > [Jacob Pan] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: atomic_inc and spin_lock_irq
On 18 Dec 2014 at 21:07, Rogelio M. Serrano Jr. wrote: > whats the difference between: > > atomic_inc(>count); > > and > > spin_lock_irq(>lock); > ++port->count; > spin_unlock_irq(>lock); in PaX this kind of change brings the ->count accesses under the coverage of the REFCOUNT feature. if the kernel had a non-atomic refcount type and corresponding accessors, they'd be used here instead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/6] zsmalloc support compaction
On Fri, Dec 19, 2014 at 09:46:48AM +0900, Minchan Kim wrote: > Hey Seth, > > On Wed, Dec 17, 2014 at 05:19:30PM -0600, Seth Jennings wrote: > > On Tue, Dec 02, 2014 at 11:49:41AM +0900, Minchan Kim wrote: > > > Recently, there was issue about zsmalloc fragmentation and > > > I got a report from Juno that new fork failed although there > > > are plenty of free pages in the system. > > > His investigation revealed zram is one of the culprit to make > > > heavy fragmentation so there was no more contiguous 16K page > > > for pgd to fork in the ARM. > > > > > > This patchset implement *basic* zsmalloc compaction support > > > and zram utilizes it so admin can do > > > "echo 1 > /sys/block/zram0/compact" > > > > > > Actually, ideal is that mm migrate code is aware of zram pages and > > > migrate them out automatically without admin's manual opeartion > > > when system is out of contiguous page. Howver, we need more thinking > > > before adding more hooks to migrate.c. Even though we implement it, > > > we need manual trigger mode, too so I hope we could enhance > > > zram migration stuff based on this primitive functions in future. > > > > > > I just tested it on only x86 so need more testing on other arches. > > > Additionally, I should have a number for zsmalloc regression > > > caused by indirect layering. Unfortunately, I don't have any > > > ARM test machine on my desk. I will get it soon and test it. > > > Anyway, before further work, I'd like to hear opinion. > > > > > > Pathset is based on v3.18-rc6-mmotm-2014-11-26-15-45. > > > > Hey Minchan, sorry it has taken a while for me to look at this. > > It's better than forever silence. Thanks, Seth. > > > > > I have prototyped this for zbud to and I see you face some of the same > > issues, some of them much worse for zsmalloc like large number of > > objects to move to reclaim a page (with zbud, the max is 1). > > > > I see you are using zsmalloc itself for allocating the handles. Why not > > kmalloc()? Then you wouldn't need to track the handle_class stuff and > > adjust the class sizes (just in the interest of changing only what is > > need to achieve the functionality). > > 1. kmalloc minimum size : 8 byte but 4byte is enough to keep the handle > 2. handle can pin lots of slab pages in memory > 3. it's inaccurate for accouting memory usage of zsmalloc > 4. Creating handle class in zsmalloc is simple. > > > > > I used kmalloc() but that is not without issue as the handles can be > > allocated from many slabs and any slab that contains a handle can't be > > freed, basically resulting in the handles themselves needing to be > > compacted, which they can't be because the user handle is a pointer to > > them. > > Sure. One thing for good with slab is that it could remove unnecessary operations to translate handle to handle's position(page, idx) so that it would be faster although we waste 50% on 32 bit machine. Okay, I will check it. Thanks, Seth. > > > > > One way to fix this, but it would be some amount of work, is to have the > > user (zswap/zbud) provide the space for the handle to zbud/zsmalloc. > zram? > > The zswap/zbud layer knows the size of the device (i.e. handle space) > zram? > > and could allocate a statically sized vmalloc area for holding handles > > so they don't get spread all over memory. I haven't fully explored this > > idea yet. > > Hmm, I don't think it's a good idea. > > Don't make an assumption that user of allocator know the size in advance. > In addition, you want to populate all of pages to keep handle in vmalloc > area statiscally? It wouldn't be huge but it depends on the user's setup > of disksize. More question: How do you search empty slot for new handle? > At last, we need caching logic and small allocator for that. > IMHO, it has cons than pros compared current my approach. > > > > > It is pretty limiting having the user trigger the compaction. Can we > > Yeb, As I said, we need more policy but in this step, I want to introduce > primitive functions to enhance our policy as next step. > > > have a work item that periodically does some amount of compaction? > > I'm not sure periodic cleanup is good idea. I'd like to pass the decision > to the user, rather than allocator itself. It's enough for allocator > to expose current status to the user. > > > > Maybe also have something analogous to direct reclaim that, when > > zs_malloc fails to secure a new page, it will try to compact to get one? > > I understand this is a first step. Maybe too much. > > Yeb, I want to separate enhance as another patchset. > > > > > Also worth pointing out that the fullness groups are very coarse. > > Combining the objects from a ZS_ALMOST_EMPTY zspage and ZS_ALMOST_FULL > > zspage, might not result in very tight packing. In the worst case, the > > destination zspage would be slightly over 1/4 full (see > > fullness_threshold_frac) > > Good point. Actually, I had noticed that. >
Re: [PATCH] arch: powerpc: platforms: ps3: repository.c: Remove unused function
Hi Michael, On Tue, 2014-12-23 at 11:26 +1100, Michael Ellerman wrote: > On Mon, 2014-12-22 at 09:26 -0800, Geoff Levand wrote: > > ps3_repository_write_highmem_info() is needed by otheros++. What we > > need is a kernel patch to add the highmem info to the repository once it > > is known. > > OK so where's that patch? I put one in my ps3-linux repo. I'll post it after I do some more testing. -Geoff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/zsmalloc: add statistics support
Hi Ganesh, On Tue, Dec 23, 2014 at 10:26:12AM +0800, Ganesh Mahendran wrote: > Hello Minchan > > 2014-12-20 10:25 GMT+08:00 Minchan Kim : > > Hey Ganesh, > > > > On Sat, Dec 20, 2014 at 09:43:34AM +0800, Ganesh Mahendran wrote: > >> 2014-12-20 8:23 GMT+08:00 Minchan Kim : > >> > On Fri, Dec 19, 2014 at 04:17:56PM -0800, Andrew Morton wrote: > >> >> On Sat, 20 Dec 2014 09:10:43 +0900 Minchan Kim > >> >> wrote: > >> >> > >> >> > > It involves rehashing a lengthy argument with Greg. > >> >> > > >> >> > Okay. Then, Ganesh, > >> >> > please add warn message about duplicaed name possibility althoug > >> >> > it's unlikely as it is. > >> >> > >> >> Oh, getting EEXIST is easy with this patch. Just create and destroy a > >> >> pool 2^32 times and the counter wraps ;) It's hardly a serious issue > >> >> for a debugging patch. > >> > > >> > I meant that I wanted to change from index to name passed from caller > >> > like this > >> > > >> > zram: > >> > zs_create_pool(GFP_NOIO | __GFP_HIGHMEM, > >> > zram->disk->first_minor); > >> > > >> > So, duplication should be rare. :) > >> > >> We still can not know whether the name is duplicated if we do not > >> change the debugfs API. > >> The API does not return the errno to us. > >> > >> How about just zsmalloc decides the name of the pool-id, like pool-x. > >> When the pool-id reaches > >> 0x., we print warn message about duplicated name, and stop > >> creating the debugfs entry > >> for the user. > > > > The idea is from the developer point of view to implement thing easy > > but my point is we should take care of user(ie, admin) rather than > > developer(ie, we). > > Yes. I got it. > > > > > For user, /sys/kernel/debug/zsmalloc/zram0 would be more > > straightforward and even it doesn't need zram to export > > /sys/block/zram0/pool-id. > > BTW, If we add a new argument in zs_create_pool(). It seems we also need to > add argument in zs_zpool_create(). So, zpool/zswap/zbud will be > modified to support > the new API. > Is that acceptable? I think it's doable. The zpool_create_pool has already zswap_zpool_type. Ccing maintainers for double check. Many thanks. > > Thanks. > > > > > Thanks. > > > >> > >> Thanks. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majord...@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: mailto:"d...@kvack.org;> em...@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH] extcon: otg_gpio: add driver for USB OTG port controlled by GPIO(s)
On Mon, Dec 22, 2014 at 02:43:37PM -0800, David Cohen wrote:
> Some platforms have an USB OTG port fully (or partially) controlled by
> GPIOs:
>
> (1) USB ID is connected directly to GPIO
>
> Optionally:
> (2) VBUS is enabled by a GPIO (when ID is grounded)
> (3) Platform has 2 USB controllers connected to same port: one for
> device and one for host role. D+/- are switched between phys
> by GPIO.
Would you explain how it works? Choosing controller runtime?
>
> As per initial version, this driver has the duty to control whether
> USB-Host cable is plugged in or not:
You mean Micro-AB cable, right?
> - If yes, OTG port is configured for host role
> - If no, by standard, the OTG port is configured for device role
>
> Signed-off-by: David Cohen
> ---
>
> Hi,
>
> Some Intel Bay Trail boards have an unusual way to handle the USB OTG port:
> - The USB ID pin is connected directly to GPIO on SoC
> - When in host role, VBUS is provided by enabling a GPIO
> - Device and host roles are supported by 2 independent controllers with D+/-
>pins from port switched between different phys according a GPIO level.
>
> The ACPI table describes this USB port as a (virtual) device with all the
> necessary GPIOs. This driver implements support to this virtual device as an
> extcon class driver. All drivers that depend on the USB OTG port state (USB
> phy,
> PMIC, charge detection) will listen to extcon events.
>
> Comments are welcome.
>
> Br, David
> ---
>
> drivers/extcon/Kconfig | 8 ++
> drivers/extcon/Makefile | 1 +
> drivers/extcon/extcon-otg_gpio.c | 200
> +++
> 3 files changed, 209 insertions(+)
> create mode 100644 drivers/extcon/extcon-otg_gpio.c
>
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 6a1f7de6fa54..e8010cda4642 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -93,4 +93,12 @@ config EXTCON_SM5502
> Silicon Mitus SM5502. The SM5502 is a USB port accessory
> detector and switch.
>
> +config EXTCON_OTG_GPIO
> + tristate "VIRTUAL USB OTG PORT support"
> + depends on GPIOLIB
> + help
> + Say Y here to enable support for virtual USB OTG port device
> + controlled by GPIOs. This driver can be used when at least USB ID pin
> + is connected directly to GPIO.
> +
> endif # MULTISTATE_SWITCH
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 0370b42e5a27..9e81088c6584 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
> obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
> obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
> obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
> +obj-$(CONFIG_EXTCON_OTG_GPIO) += extcon-otg_gpio.o
> diff --git a/drivers/extcon/extcon-otg_gpio.c
> b/drivers/extcon/extcon-otg_gpio.c
> new file mode 100644
> index ..c5ee765a5f4f
> --- /dev/null
> +++ b/drivers/extcon/extcon-otg_gpio.c
> @@ -0,0 +1,200 @@
> +/*
> + * Virtual USB OTG Port driver controlled by gpios
> + *
> + * Copyright (c) 2014, Intel Corporation.
> + * Author: David Cohen
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "usb_otg_port"
> +
> +struct vuport {
> + struct device *dev;
> + struct gpio_desc *gpio_vbus_en;
> + struct gpio_desc *gpio_usb_id;
> + struct gpio_desc *gpio_usb_mux;
> +
> + struct extcon_dev edev;
> +};
> +
> +static const char *const vuport_extcon_cable[] = {
> + [0] = "USB-Host",
> + NULL,
> +};
> +
> +/*
> + * If id == 1, USB port should be set to peripheral
> + * if id == 0, USB port should be set to host
> + *
> + * Peripheral: set USB mux to peripheral and disable VBUS
> + * Host: set USB mux to host and enable VBUS
> + */
> +static void vuport_set_port(struct vuport *vup, int id)
> +{
> + int mux_val = id;
> + int vbus_val = !id;
> +
> + if (!IS_ERR(vup->gpio_usb_mux))
> + gpiod_direction_output(vup->gpio_usb_mux, mux_val);
> +
> + if (!IS_ERR(vup->gpio_vbus_en))
> + gpiod_direction_output(vup->gpio_vbus_en, vbus_val);
> +}
> +
> +static void vuport_do_usb_id(struct vuport *vup)
> +{
> + int id = gpiod_get_value(vup->gpio_usb_id);
> +
> + dev_info(vup->dev, "USB PORT ID: %s\n", id ? "PERIPHERAL" : "HOST");
dev_dbg
> +
> + /*
> + * id == 1: PERIPHERAL
> + * id == 0: HOST
> + */
>
Re: [PATCH v2] mm/zsmalloc: add statistics support
Hello Minchan 2014-12-20 10:25 GMT+08:00 Minchan Kim : > Hey Ganesh, > > On Sat, Dec 20, 2014 at 09:43:34AM +0800, Ganesh Mahendran wrote: >> 2014-12-20 8:23 GMT+08:00 Minchan Kim : >> > On Fri, Dec 19, 2014 at 04:17:56PM -0800, Andrew Morton wrote: >> >> On Sat, 20 Dec 2014 09:10:43 +0900 Minchan Kim wrote: >> >> >> >> > > It involves rehashing a lengthy argument with Greg. >> >> > >> >> > Okay. Then, Ganesh, >> >> > please add warn message about duplicaed name possibility althoug >> >> > it's unlikely as it is. >> >> >> >> Oh, getting EEXIST is easy with this patch. Just create and destroy a >> >> pool 2^32 times and the counter wraps ;) It's hardly a serious issue >> >> for a debugging patch. >> > >> > I meant that I wanted to change from index to name passed from caller like >> > this >> > >> > zram: >> > zs_create_pool(GFP_NOIO | __GFP_HIGHMEM, zram->disk->first_minor); >> > >> > So, duplication should be rare. :) >> >> We still can not know whether the name is duplicated if we do not >> change the debugfs API. >> The API does not return the errno to us. >> >> How about just zsmalloc decides the name of the pool-id, like pool-x. >> When the pool-id reaches >> 0x., we print warn message about duplicated name, and stop >> creating the debugfs entry >> for the user. > > The idea is from the developer point of view to implement thing easy > but my point is we should take care of user(ie, admin) rather than > developer(ie, we). Yes. I got it. > > For user, /sys/kernel/debug/zsmalloc/zram0 would be more > straightforward and even it doesn't need zram to export > /sys/block/zram0/pool-id. BTW, If we add a new argument in zs_create_pool(). It seems we also need to add argument in zs_zpool_create(). So, zpool/zswap/zbud will be modified to support the new API. Is that acceptable? Thanks. > > Thanks. > >> >> Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: missing merge fix patch for the merge of the xen-tip tree with the arm-soc tree
Hi Linus,
I have been carrying this merge fix patch for some time that is now
needed in your tree:
From: Stephen Rothwell
Date: Mon, 8 Dec 2014 18:46:59 +1100
Subject: [PATCH] arm: introduce is_device_dma_coherent merge fix
The merge of the (linux-next) xen-tip tree got a conflict in
arch/arm/include/asm/dma-mapping.h between commits a3a60f81ee6f
("dma-mapping: replace set_arch_dma_coherent_ops with
arch_setup_dma_ops") and 4bb25789ed28 ("arm: dma-mapping: plumb our
iommu mapping ops into arch_setup_dma_ops") from the arm-soc tree and
commit 3d5391ac6f5e ("arm: introduce is_device_dma_coherent") from the
xen-tip tree. It was fixed up, but also required this additional fix.
"Looks good to me"-by: Will Deacon
Signed-off-by: Stephen Rothwell
---
arch/arm/mm/dma-mapping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 09645f00bd17..43064cbe58f9 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2058,6 +2058,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base,
u64 size,
else
dma_ops = arm_get_dma_map_ops(coherent);
+ dev->archdata.dma_coherent = coherent;
set_dma_ops(dev, dma_ops);
}
--
2.1.3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpudfbX1ytsa.pgp
Description: OpenPGP digital signature
