[PATCH v5 09/14] acpi, numa: remove unneeded acpi_numa=1
From: Hanjun Guo acpi_numa is default to 0, it's set to -1 when disable acpi numa or when a bad SRAT is parsed, and it's only consumed in srat_disabled() (compare it with 0) to continue parse the SRAT or not, so we don't need to set acpi_numa to 1 when we get a valid SRAT entry. Signed-off-by: Hanjun Guo Signed-off-by: Robert Richter Signed-off-by: David Daney --- arch/x86/mm/srat.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c index 4217071f..30460f5 100644 --- a/arch/x86/mm/srat.c +++ b/arch/x86/mm/srat.c @@ -59,7 +59,6 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa) } set_apicid_to_node(apic_id, node); node_set(node, numa_nodes_parsed); - acpi_numa = 1; printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n", pxm, apic_id, node); } @@ -101,7 +100,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) set_apicid_to_node(apic_id, node); node_set(node, numa_nodes_parsed); - acpi_numa = 1; printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n", pxm, apic_id, node); } -- 1.7.11.7
[PATCH v5 07/14] x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
From: Hanjun Guo
Cleanup acpi_numa_processor_affinity_init() in preparation for its
move to drivers/acpi/numa.c. It will be reused by arm64, this has no
functional change.
Signed-off-by: Hanjun Guo
Signed-off-by: Robert Richter
Signed-off-by: David Daney
---
arch/x86/mm/srat.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index f242a11..9e2a833 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -26,11 +26,6 @@
int acpi_numa __initdata;
-static __init int setup_node(int pxm)
-{
- return acpi_map_pxm_to_node(pxm);
-}
-
static __init void bad_srat(void)
{
printk(KERN_ERR "SRAT: SRAT not used.\n");
@@ -64,7 +59,7 @@ acpi_numa_x2apic_affinity_init(struct
acpi_srat_x2apic_cpu_affinity *pa)
pxm, apic_id);
return;
}
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -100,7 +95,7 @@ acpi_numa_processor_affinity_init(struct
acpi_srat_cpu_affinity *pa)
pxm = pa->proximity_domain_lo;
if (acpi_srat_revision >= 2)
pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -124,12 +119,6 @@ acpi_numa_processor_affinity_init(struct
acpi_srat_cpu_affinity *pa)
pxm, apic_id, node);
}
-#ifdef CONFIG_MEMORY_HOTPLUG
-static inline int save_add_info(void) {return 1;}
-#else
-static inline int save_add_info(void) {return 0;}
-#endif
-
/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
int __init
acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
@@ -145,7 +134,7 @@ acpi_numa_memory_affinity_init(struct
acpi_srat_mem_affinity *ma)
if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
goto out_err;
hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
- if (hotpluggable && !save_add_info())
+ if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
goto out_err;
start = ma->base_address;
@@ -154,7 +143,7 @@ acpi_numa_memory_affinity_init(struct
acpi_srat_mem_affinity *ma)
if (acpi_srat_revision <= 1)
pxm &= 0xff;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains.\n");
goto out_err_bad_srat;
@@ -182,7 +171,7 @@ acpi_numa_memory_affinity_init(struct
acpi_srat_mem_affinity *ma)
out_err_bad_srat:
bad_srat();
out_err:
- return -1;
+ return -EINVAL;
}
int __init x86_acpi_numa_init(void)
--
1.7.11.7
[PATCH v5 01/14] acpi, numa: Use pr_fmt() instead of printk
From: Hanjun Guo
Just do some cleanups to replace printk with pr_fmt().
Signed-off-by: Hanjun Guo
Signed-off-by: Robert Richter
Signed-off-by: David Daney
---
drivers/acpi/numa.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 72b6e9e..4e427fc 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -18,6 +18,9 @@
* ~~
*
*/
+
+#define pr_fmt(fmt) "ACPI: " fmt
+
#include
#include
#include
@@ -28,8 +31,6 @@
#include
#include
-#define PREFIX "ACPI: "
-
#define ACPI_NUMA 0x8000
#define _COMPONENT ACPI_NUMA
ACPI_MODULE_NAME("numa");
@@ -187,9 +188,8 @@ acpi_table_print_srat_entry(struct acpi_subtable_header
*header)
#endif /* ACPI_DEBUG_OUTPUT */
break;
default:
- printk(KERN_WARNING PREFIX
- "Found unsupported SRAT entry (type = 0x%x)\n",
- header->type);
+ pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
+ header->type);
break;
}
}
@@ -222,7 +222,7 @@ static int __init acpi_parse_slit(struct acpi_table_header
*table)
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
if (!slit_valid(slit)) {
- printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
+ pr_info("SLIT table looks invalid. Not used.\n");
return -EINVAL;
}
acpi_numa_slit_init(slit);
@@ -233,12 +233,9 @@ static int __init acpi_parse_slit(struct acpi_table_header
*table)
void __init __weak
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
{
- printk(KERN_WARNING PREFIX
- "Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
- return;
+ pr_warn("Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
}
-
static int __init
acpi_parse_x2apic_affinity(struct acpi_subtable_header *header,
const unsigned long end)
--
1.7.11.7
[PATCH v5 06/14] arm64, numa: rework numa_add_memblk()
From: Hanjun Guo
Rework numa_add_memblk() to update the parameter "u64 size" to "u64
end", this will make it consistent with x86 and simplifies the arm64
ACPI NUMA code to be added later.
Signed-off-by: Hanjun Guo
Signed-off-by: Robert Richter
Signed-off-by: David Daney
---
arch/arm64/mm/numa.c | 12 ++--
drivers/of/of_numa.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 98dc104..6cb03f9 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -131,25 +131,25 @@ void __init early_map_cpu_to_node(unsigned int cpu, int
nid)
* numa_add_memblk - Set node id to memblk
* @nid: NUMA node ID of the new memblk
* @start: Start address of the new memblk
- * @size: Size of the new memblk
+ * @end: End address of the new memblk
*
* RETURNS:
* 0 on success, -errno on failure.
*/
-int __init numa_add_memblk(int nid, u64 start, u64 size)
+int __init numa_add_memblk(int nid, u64 start, u64 end)
{
int ret;
- ret = memblock_set_node(start, size, &memblock.memory, nid);
+ ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
if (ret < 0) {
pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node
%d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
node_set(nid, numa_nodes_parsed);
pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
@@ -367,7 +367,7 @@ static int __init dummy_numa_init(void)
0LLU, PFN_PHYS(max_pfn) - 1);
for_each_memblock(memory, mblk) {
- ret = numa_add_memblk(0, mblk->base, mblk->size);
+ ret = numa_add_memblk(0, mblk->base, mblk->base + mblk->size);
if (!ret)
continue;
diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 0f2784b..ed5a097 100644
--- a/drivers/of/of_numa.c
+++ b/drivers/of/of_numa.c
@@ -91,8 +91,8 @@ static int __init of_numa_parse_memory_nodes(void)
pr_debug("NUMA: base = %llx len = %llx, node = %u\n",
rsrc.start, rsrc.end - rsrc.start + 1, nid);
- r = numa_add_memblk(nid, rsrc.start,
- rsrc.end - rsrc.start + 1);
+
+ r = numa_add_memblk(nid, rsrc.start, rsrc.end + 1);
if (r)
break;
}
--
1.7.11.7
Re: [PATCH 14/16] vfs: Implement mount_super_once
On April 19, 2016 6:24:12 PM PDT, Linus Torvalds wrote: >On Tue, Apr 19, 2016 at 4:29 PM, Linus Torvalds > wrote: >> >> I _violently_ oppose the stupid DEVPTS_MULTIPLE_INSTANCES config >option. > >So just to show what I want to actually happen, here's the hacky patch >on top of my (now merged) cleanup patch that actually does what I want >devpts to do. > >I say it's hacky, because the "follow_mount()" thing there really is >pretty hacky. Al - suggestions for how to do this *right*? > >But this actually forcibly removes the whole "newinstance" thing, and >makes every pts mount a new instance, and just relies on "ptmx" doing >the right thing. > >In other words, with this patch, you can *literally* do just this (as >root, obviously): > > mkdir test-dir > cd test-dir > > mknod ptmx c 5 2 > mkdir pts > mount -t devpts pts pts > >and after that it all just works. You can do this: > > ls -l pts > >which shows just the other ptmx noode (that is unused and pointless - >I'd actually like to just remove it, but whatever), and then you can >do > > sleep 100 < ptmx & > sleep 100 < ptmx & > ls -l pts > >and you will magically see those new 0/1 entries in that pts >subdirectory.. It's entirely independent of /dev/pts/, and there's no >magic connection or any magic dis-connection. It all JustWorks(tm). > >Note how this works even *outside* of /dev. But it works inside of >/dev equally well. > >Now, a *real* patch would > > - solve that "follow_mount()" issue some other way > > - not remove the newinstance code immediately (I did it to show that >even the bootup works with a unmodified distro) > > - actually remove the whole "DEVPTS_MULTIPLE_INSTANCES" config option > > - I'm not happy with devpts_pty_kill(). I would want to clean that up >a bit somehow. I think this is at least partly what Peter Hurley was >talking about. That thing is not pretty. > >so this attached patch is by no means meant to be applied as-is. But >it's meant to show what (a) the new organization allows and (b) what I >was going for. > > Linus I say let's remove it unless ptmxmode= is specified. That way we don't break people who actually did the symlink thing. -- Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
[PATCH] ARM: dove: Remove CLK_IS_ROOT
This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Cc: Andrew Lunn
Signed-off-by: Stephen Boyd
---
arch/arm/mach-dove/common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 0cdaa3851d2e..0d420a2bfe3e 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -88,8 +88,7 @@ static void __init dove_clk_init(void)
struct clk *nand, *camera, *i2s0, *i2s1, *crypto, *ac97, *pdma;
struct clk *xor0, *xor1, *ge, *gephy;
- tclk = clk_register_fixed_rate(NULL, "tclk", NULL, CLK_IS_ROOT,
- dove_tclk);
+ tclk = clk_register_fixed_rate(NULL, "tclk", NULL, 0, dove_tclk);
usb0 = dove_register_gate("usb0", "tclk", CLOCK_GATING_BIT_USB0);
usb1 = dove_register_gate("usb1", "tclk", CLOCK_GATING_BIT_USB1);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: Does anyone care about a race free ptsname?
On Tue, Apr 19, 2016 at 04:39:07PM -0700, H. Peter Anvin wrote: > On 04/19/2016 04:23 PM, Linus Torvalds wrote: > > On Tue, Apr 19, 2016 at 11:44 AM, Eric W. Biederman > > wrote: > >> > >> I will take a look in a minute. Before I do that I want to mention > >> why I care about /dev/pts/ptmx. > >> > >> There is a posix function that is widely used called ptsname. It's > >> function is to take a master file descriptor and returns the path to the > >> slave. > >> > >> All we have in the kernel to support ptsname is an ioctl TIOCGPTN that > >> returns the pty number in the appropriate instance of devpts. > > > > Don't bother with that completely mis-designed interface.It's crap. > > > > So we'll keep it working for legacy models, but the whole "return an > > integer index" is just pure shit. It's not worth worrying about. > > > > We can (and probably should) just introduce a new ioctl or even a > > system call that just does the sane thing and returns the pathname > > from the kernel. > > > > What do you think of the idea of TIOCPTSOPEN (or whatever) to get a file > descriptor for the slave device given the master device? Then we can That's what i was thinking, since as I said many users just want blah = ptsname(fd); slavefd = open(blah, ...); so they really just want an open fd. > use realpath() or a readlink on /proc/self/fd/# to get the pathname if > needed. > > (Incidentally, we added getcwd() as a system call. Should we add > [f]realpath() as a system call too?) > > -hpa
[PATCH v5 14/14] arm64, acpi, numa: Default enable ACPI_NUMA with NUMA
From: Robert Richter Signed-off-by: Robert Richter Signed-off-by: David Daney --- drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 5ce9f66..bacf245 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -292,7 +292,7 @@ config ACPI_NUMA bool "NUMA support" depends on NUMA depends on (X86 || IA64 || ARM64) - default y if IA64_GENERIC || IA64_SGI_SN2 + default y if IA64_GENERIC || IA64_SGI_SN2 || ARM64 config ACPI_CUSTOM_DSDT_FILE string "Custom DSDT Table file to include" -- 1.7.11.7
[PATCH v2] pinctrl-exynos5440: Use off-stack memory for pinctrl_gpio_range
The range is registered into a linked list which can be referenced
throughout the lifetime of the driver. Ensure the range's memory is useful
for the same lifetime by adding it to the driver's private data structure.
The bug was introduced in the driver's initial commit, which was present in
v3.10.
Signed-off-by: Andrew Jeffery
Fixes: f0b9a7e521fa ("pinctrl: exynos5440: add pinctrl driver for Samsung
EXYNOS5440 SoC")
Cc: sta...@vger.kernel.org
---
Since v1:
* Add range member kerneldoc addressing Tomasz Figa's comment
This is my first contribution to the kernel, so hopefully I've followed all the
relevant documentation. If not, please let me know and point me in the right
direction!
I don't have the means to test the patch, but it compiles. Someone with
appropriate hardware should probably give it a spin. From the responses it
seems that few might have access, and given the nature of the bug it might be
the case that no-one has complained because no-one is affected - is it worth
maintaining going forward?
drivers/pinctrl/samsung/pinctrl-exynos5440.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
index 00ab63abf1d9..dbbdf652c34a 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
@@ -107,6 +107,7 @@ struct exynos5440_pmx_func {
* @nr_groups: number of pin groups available.
* @pmx_functions: list of pin functions parsed from device tree.
* @nr_functions: number of pin functions available.
+ * @range: gpio range to register with pinctrl
*/
struct exynos5440_pinctrl_priv_data {
void __iomem*reg_base;
@@ -117,6 +118,7 @@ struct exynos5440_pinctrl_priv_data {
unsigned intnr_groups;
const struct exynos5440_pmx_func*pmx_functions;
unsigned intnr_functions;
+ struct pinctrl_gpio_range range;
};
/**
@@ -742,7 +744,6 @@ static int exynos5440_pinctrl_register(struct
platform_device *pdev,
struct pinctrl_desc *ctrldesc;
struct pinctrl_dev *pctl_dev;
struct pinctrl_pin_desc *pindesc, *pdesc;
- struct pinctrl_gpio_range grange;
char *pin_names;
int pin, ret;
@@ -794,12 +795,12 @@ static int exynos5440_pinctrl_register(struct
platform_device *pdev,
return PTR_ERR(pctl_dev);
}
- grange.name = "exynos5440-pctrl-gpio-range";
- grange.id = 0;
- grange.base = 0;
- grange.npins = EXYNOS5440_MAX_PINS;
- grange.gc = priv->gc;
- pinctrl_add_gpio_range(pctl_dev, &grange);
+ priv->range.name = "exynos5440-pctrl-gpio-range";
+ priv->range.id = 0;
+ priv->range.base = 0;
+ priv->range.npins = EXYNOS5440_MAX_PINS;
+ priv->range.gc = priv->gc;
+ pinctrl_add_gpio_range(pctl_dev, &priv->range);
return 0;
}
--
2.5.0
Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver
On 04/19, Jose Abreu wrote: > > @Stephen: can you give some input so that I can submit a v6? > I don't prefer putting the second register in the same DT node, but that's really up to the DT reviewers to approve such a design. The current binding has been acked by Rob right? Assuming the new binding is acked/reviewed then that solution is fine. Otherwise, I still prefer two DTS files for the two different FPGA versions. At the least, please use ioremap for any pointers that you readl/writel here. Beyond that, we should have a fixed rate source clk somewhere in the software view of the clk tree, because that reflects reality. Hardcoding the parent rate in the structure works, but doesn't properly express the clk tree. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: Umount failing due to a file leak on 3.18 Android
Adding Arve Hjønnevåg and Riley Andrews I am looking into a bug that results in umount failures ( since there is a mount ref from the leaked file that is never freed on the mount ) The issue seems to be a result of the following callstack 39.958104: <6> Call trace: 39.958108: <2> [] fput+0x1e0/0x1f8 39.958113: <2> [] filp_close+0xa0/0xb8 39.958119: <2> [] put_files_struct+0x88/0xf0 39.958123: <2> [] binder_deferred_func+0x6a8/0x704 39.958129: <2> [] process_one_work+0x238/0x3f0 39.958133: <2> [] worker_thread+0x2f8/0x418 What seems to occur is that once in a while a file ( say a.txt) is fput in the above stack right as the task is being killed And then we see that the fput schedules a delayed_fput_work on this file But when the function delayed_fput() is actually run : the file that was put i.e this a.txt is not in the delayed_fput_list Any chance you can help me get to the bottom of this leak? I dont understand why the delayed_fput_list is missing the file. Is there some sort of race condition? I will appreciate any pointers you can give me to debug this issue Thanks so much in advance for your help. -- Thanks Nikhilesh Reddy Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [RFC][PATCH 0/4] tracing: Add event-fork to trace tasks children
On 04/19/2016 11:34 AM, Steven Rostedt wrote:
> This code adds the event-fork option that, when set, will have tasks
> with their PIDs in set_event_pid add their children PIDs when they
> fork. It will also remove their PID from the file on exit.
That is a nice feature! I tested it and it works. But, look this...
Set the event-fork, the current shell pid, and enable the trace:
[root@f23 tracing]# echo event-fork > trace_options
[root@f23 tracing]# echo $$ > set_ftrace_pid
[root@f23 tracing]# echo function > current_tracer
to exercise the feature, start the httpd...
[root@f23 tracing]# httpd
[root@f23 tracing]# cat trace | awk '{print $1}' | sort | uniq
awk-2209
bash-2162
bash-2208
httpd-2196
httpd-2197
httpd-2199
httpd-2200
httpd-2201
httpd-2202
httpd-2203
httpd-2204
httpd-2205
httpd-2206
httpd-2207
sort-2210
uniq-2211
Awesome :-) it works!
But, the set_ftrace_pid only shows the pid of the shell. I thought
it would print all child's pid.
[root@f23 tracing]# cat set_ftrace_pid
2162
Now, lets finish the session:
[root@f23 tracing]# echo 0 > tracing_on
[root@f23 tracing]# echo nop > current_tracer
[root@f23 tracing]# echo > trace
[root@f23 tracing]# echo > set_ftrace_pid
[root@f23 tracing]# echo noevent-fork > trace_options
and start a simple trace again, filtering the watchdog/0 thread:
[root@f23 tracing]# echo 14 > set_ftrace_pid
[root@f23 tracing]# echo function > current_tracer
[root@f23 tracing]# echo 1 > tracing_on
(this is a trick to make httpd work)
[root@f23 tracing]# kill -1 2197
voilà!
[root@f23 tracing]# cat trace | awk '{print $1}' | sort | uniq
httpd-2197
httpd-2501
httpd-2503
httpd-2506
httpd-2507
httpd-2526
httpd-2527
httpd-2528
httpd-2529
httpd-2530
httpd-2531
httpd-2532
httpd-2533
httpd-2534
httpd-2535
watchdog/0-14
The httpd stills being filtered, and I did not find a way to remove
them. Although I see that they will be removed when they exit, I
think it would be nice to remove them when cleaning
set_ftrace_pid.
Am I missing something?
-- Daniel
[PATCH v2 1/7] mmc: sdhci-pltfm: drop error message for too small MMIO resource size
The requirement resource_size >= 0x100 may not necessarily be reasonable; for example, sdhci-dove appears to sidestep some registers in sdhci_dove_readw(). Moreover, current code displays an error message for too small resource size, but still moves forward. Every DT should be responsible for describing its properties correctly, so lets's remove this error message from the common framework. Signed-off-by: Masahiro Yamada --- Changes in v2: - Remove resource size checking rather than fix it. drivers/mmc/host/sdhci-pltfm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c index 072bb27..03dbdeb 100644 --- a/drivers/mmc/host/sdhci-pltfm.c +++ b/drivers/mmc/host/sdhci-pltfm.c @@ -127,9 +127,6 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev, goto err; } - if (resource_size(iomem) < 0x100) - dev_err(&pdev->dev, "Invalid iomem size!\n"); - host = sdhci_alloc_host(&pdev->dev, sizeof(struct sdhci_pltfm_host) + priv_size); -- 1.9.1
[PATCH v2 5/7] mmc: sdhci-pltfm: use devm_ioremap_resource()
The chain of devm_request_mem_region() and devm_ioremap() can be
replaced with devm_ioremap_resource(). Also, we can drop the error
messages because devm_ioremap_resource() displays similar messages
on error.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/host/sdhci-pltfm.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 5213287..caa05d7 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -152,19 +152,9 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
goto err_request;
}
- if (!devm_request_mem_region(&pdev->dev, iomem->start,
-resource_size(iomem),
-mmc_hostname(host->mmc))) {
- dev_err(&pdev->dev, "cannot request region\n");
- ret = -EBUSY;
- goto err_request;
- }
-
- host->ioaddr = devm_ioremap(&pdev->dev, iomem->start,
- resource_size(iomem));
- if (!host->ioaddr) {
- dev_err(&pdev->dev, "failed to remap registers\n");
- ret = -ENOMEM;
+ host->ioaddr = devm_ioremap_resource(&pdev->dev, iomem);
+ if (IS_ERR(host->ioaddr)) {
+ ret = PTR_ERR(host->ioaddr);
goto err_request;
}
--
1.9.1
[PATCH v2 6/7] mmc: sdhci-pltfm: move devm_ioremap_resource() up
Call devm_ioremap_resource() right after platform_get_resource().
This saves the error check of platform_get_resource() because
devm_ioremap_resource() checks if the given resource is NULL.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/host/sdhci-pltfm.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index caa05d7..1d74db8 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -119,11 +119,13 @@ struct sdhci_host *sdhci_pltfm_init(struct
platform_device *pdev,
{
struct sdhci_host *host;
struct resource *iomem;
+ void __iomem *ioaddr;
int ret;
iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!iomem) {
- ret = -ENOMEM;
+ ioaddr = devm_ioremap_resource(&pdev->dev, iomem);
+ if (IS_ERR(ioaddr)) {
+ ret = PTR_ERR(ioaddr);
goto err;
}
@@ -135,6 +137,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
goto err;
}
+ host->ioaddr = ioaddr;
host->hw_name = dev_name(&pdev->dev);
if (pdata && pdata->ops)
host->ops = pdata->ops;
@@ -152,12 +155,6 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
goto err_request;
}
- host->ioaddr = devm_ioremap_resource(&pdev->dev, iomem);
- if (IS_ERR(host->ioaddr)) {
- ret = PTR_ERR(host->ioaddr);
- goto err_request;
- }
-
/*
* Some platforms need to probe the controller to be able to
* determine which caps should be used.
--
1.9.1
[PATCH v2 4/7] mmc: sdhci-pltfm: use devm_ioremap()
Use the managed variant of ioremap().
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/host/sdhci-pltfm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 8527a7c..5213287 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -160,7 +160,8 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
goto err_request;
}
- host->ioaddr = ioremap(iomem->start, resource_size(iomem));
+ host->ioaddr = devm_ioremap(&pdev->dev, iomem->start,
+ resource_size(iomem));
if (!host->ioaddr) {
dev_err(&pdev->dev, "failed to remap registers\n");
ret = -ENOMEM;
@@ -190,7 +191,6 @@ void sdhci_pltfm_free(struct platform_device *pdev)
{
struct sdhci_host *host = platform_get_drvdata(pdev);
- iounmap(host->ioaddr);
sdhci_free_host(host);
}
EXPORT_SYMBOL_GPL(sdhci_pltfm_free);
--
1.9.1
[PATCH v2 7/7] mmc: sdhci-pltfm: call platform_get_irq() before sdhci_alloc_host()
Swap the call order of sdhci_alloc_host() and platform_get_irq().
It makes sdhci_alloc_host() the last function that can fail in the
sdhci_pltfm_init(). So, we can drop the sdhci_free_host() call from
the failure path.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/host/sdhci-pltfm.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 1d74db8..64f287a 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -120,7 +120,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
struct sdhci_host *host;
struct resource *iomem;
void __iomem *ioaddr;
- int ret;
+ int irq, ret;
iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ioaddr = devm_ioremap_resource(&pdev->dev, iomem);
@@ -129,6 +129,13 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
goto err;
}
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "failed to get IRQ number\n");
+ ret = irq;
+ goto err;
+ }
+
host = sdhci_alloc_host(&pdev->dev,
sizeof(struct sdhci_pltfm_host) + priv_size);
@@ -138,6 +145,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
}
host->ioaddr = ioaddr;
+ host->irq = irq;
host->hw_name = dev_name(&pdev->dev);
if (pdata && pdata->ops)
host->ops = pdata->ops;
@@ -148,13 +156,6 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
host->quirks2 = pdata->quirks2;
}
- host->irq = platform_get_irq(pdev, 0);
- if (host->irq < 0) {
- dev_err(&pdev->dev, "failed to get IRQ number\n");
- ret = host->irq;
- goto err_request;
- }
-
/*
* Some platforms need to probe the controller to be able to
* determine which caps should be used.
@@ -165,9 +166,6 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
platform_set_drvdata(pdev, host);
return host;
-
-err_request:
- sdhci_free_host(host);
err:
dev_err(&pdev->dev, "%s failed %d\n", __func__, ret);
return ERR_PTR(ret);
--
1.9.1
[PATCH v2 2/7] mmc: sdhci-pltfm: check return value of platform_get_irq()
The function platform_get_irq() can fail; it returns a negative error
code on failure. A negative IRQ number will make sdhci_add_host() fail
to request IRQ anyway, but it makes sense to let it fail earlier here.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Add \n to the tail of the error message
drivers/mmc/host/sdhci-pltfm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 03dbdeb..24377a3 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -146,6 +146,11 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
}
host->irq = platform_get_irq(pdev, 0);
+ if (host->irq < 0) {
+ dev_err(&pdev->dev, "failed to get IRQ number\n");
+ ret = host->irq;
+ goto err_request;
+ }
if (!request_mem_region(iomem->start, resource_size(iomem),
mmc_hostname(host->mmc))) {
--
1.9.1
[PATCH v2 3/7] mmc: sdhci-pltfm: use devm_request_mem_region()
Use the managed variant of request_mem_region().
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
drivers/mmc/host/sdhci-pltfm.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 24377a3..8527a7c 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -152,8 +152,9 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
goto err_request;
}
- if (!request_mem_region(iomem->start, resource_size(iomem),
- mmc_hostname(host->mmc))) {
+ if (!devm_request_mem_region(&pdev->dev, iomem->start,
+resource_size(iomem),
+mmc_hostname(host->mmc))) {
dev_err(&pdev->dev, "cannot request region\n");
ret = -EBUSY;
goto err_request;
@@ -163,7 +164,7 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
if (!host->ioaddr) {
dev_err(&pdev->dev, "failed to remap registers\n");
ret = -ENOMEM;
- goto err_remap;
+ goto err_request;
}
/*
@@ -177,8 +178,6 @@ struct sdhci_host *sdhci_pltfm_init(struct platform_device
*pdev,
return host;
-err_remap:
- release_mem_region(iomem->start, resource_size(iomem));
err_request:
sdhci_free_host(host);
err:
@@ -190,10 +189,8 @@ EXPORT_SYMBOL_GPL(sdhci_pltfm_init);
void sdhci_pltfm_free(struct platform_device *pdev)
{
struct sdhci_host *host = platform_get_drvdata(pdev);
- struct resource *iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
iounmap(host->ioaddr);
- release_mem_region(iomem->start, resource_size(iomem));
sdhci_free_host(host);
}
EXPORT_SYMBOL_GPL(sdhci_pltfm_free);
--
1.9.1
[PATCH v2 0/7] mmc: sdhci-pltfm: fix and tidy up sdhci_pltfm_init()
Changes in v2: - Remove resource size checking rather than fix it. - Add \n to the tail of the error message Masahiro Yamada (7): mmc: sdhci-pltfm: drop error message for too small MMIO resource size mmc: sdhci-pltfm: check return value of platform_get_irq() mmc: sdhci-pltfm: use devm_request_mem_region() mmc: sdhci-pltfm: use devm_ioremap() mmc: sdhci-pltfm: use devm_ioremap_resource() mmc: sdhci-pltfm: move devm_ioremap_resource() up mmc: sdhci-pltfm: call platform_get_irq() before sdhci_alloc_host() drivers/mmc/host/sdhci-pltfm.c | 42 +- 1 file changed, 13 insertions(+), 29 deletions(-) -- 1.9.1
Re: [PATCH] drm/rockchip: get rid of rockchip_drm_crtc_mode_config
On 2016年04月19日 17:06, John Keeping wrote:
On Tue, 19 Apr 2016 10:43:03 +0800, Mark yao wrote:
On 2016年04月18日 17:25, John Keeping wrote:
On Mon, 18 Apr 2016 11:03:31 +0800, Mark Yao wrote:
We need to take care of the vop status when use
rockchip_drm_crtc_mode_config, if vop is disabled,
the function would failed, that is terrible.
Save connector type and output mode on drm_display_mode->private_flags
at encoder mode_fixup, then we can configure the type and mode safely
on crtc mode_set.
Since Rockchip is atomic, shouldn't this be using atomic_check hooks and
a subclassed crtc_state structure?
I try to use atomic_check with crtc_state, but it seems not easy,
there are two value need transmit from connector to vop: connector type
and out_mode
the connector type I think we can loop the atomic state to find the
connector type.
but the out_mode is a custom value, I can't find a generic way to
transmit it with atomic state.
BTW, I think on atomic side, the drm_display_mode is under control by
atomic state,
and the mode->private_flags is not use by drm framework, I found i915
and gma500 also use
mode->private_flags to transmit custom value.
So I think it's no problem using mode->private_flags.
The documentation for drm_display_mode::private says:
It shouldn't be used by atomic drivers since they can store any
additional data by subclassing state structures.
This applies to private_flags as well.
I think this means that we should do something like the patch below
(which isn't even compile tested and doesn't cover implementing
drm_encoder_helper_funcs::atomic_check on all of the encoders):
-- >8 --
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 00d17d71aa4c..9d65fa9188f4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -31,6 +31,14 @@
struct drm_device;
struct drm_connector;
+struct rockchip_crtc_state {
+ struct drm_crtc_state base;
+ int output_type;
+ int output_mode;
+};
+
+#define to_rockchip_crtc_state(s) container_of(x, struct rockchip_crtc_state,
base)
+
/*
* Rockchip drm private crtc funcs.
* @enable_vblank: enable crtc vblank irq.
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index a619f120f801..5cdf3123e1eb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1044,13 +1044,34 @@ static void vop_crtc_destroy(struct drm_crtc *crtc)
drm_crtc_cleanup(crtc);
}
+static struct drm_crtc_state *vop_crtc_duplicate_state(struct drm_crtc *crtc)
+{
+ struct rockchip_crtc_state *rockchip_state;
+
+ rockchip_state = kzalloc(sizeof(*rockchip_state), GFP_KERNEL);
+ if (!rockchip_state)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc, &rockchip_state->base);
+ return &rockchip_state->base;
+}
+
+static void vop_crtc_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(state);
+
+ __drm_atomic_helper_crtc_destroy_state(crtc, &s->base);
+ kfree(s);
+}
+
static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
.destroy = vop_crtc_destroy,
.reset = drm_atomic_helper_crtc_reset,
- .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
- .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
+ .atomic_duplicate_state = vop_crtc_duplicate_state,
+ .atomic_destroy_state = vop_crtc_destroy_state,
};
static bool vop_win_pending_is_complete(struct vop_win *vop_win)
Hi John
Good, I had implement it according to your advise.
Thanks.
--
Ｍark Yao
Re: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg()
On Wed, Apr 13, 2016 at 09:50:19PM +0200, Rafael J. Wysocki wrote: > On Wed, Apr 13, 2016 at 8:06 PM, Steve Muckle wrote: > > On 04/13/2016 09:07 AM, Rafael J. Wysocki wrote: > >> If you want to do remote updates, I guess that will require an > >> irq_work to run the update on the target CPU, but then you'll probably > >> want to neglect the rate limit on it as well, so it looks like a > >> "need_update" flag in struct update_util_data will be useful for that. > > > > Have you added rate limiting at the hook level that I missed? I thought > > it was just inside schedutil. > > It is in schedutil (and other governors), but if you do a cross-CPU > update, you probably want that rate limit to be ignored in that case. > Now, if the local and target CPUs happen to use different governors > (eg. the local CPU uses ondemand and the target one uses schedutil) or > they just don't belong to the same policy, you need to set the "need > update" flag for the target CPU, so the local one needs access to it. > It is better for that flag to be located in the per-CPU data of the > target CPU for that. It's not clear to me whether remote updates are necessarily more important than updates triggered locally, such that they would override the rate limit while local ones do not. My guess is this special treatment could be left out at least initially. > > Ok thanks, I'll take another look at this. > > > > I was thinking it might be nice to be able to push the decision on > > whether to send the IPI in to the governor/hook client. For example in > > the schedutil case, you don't need to IPI if sugov_should_update_freq() > > = false (outside the slight chance it might be true when it runs on the > > target). Beyond that perhaps for policy reasons it's desired to not send > > the IPI if next_freq <= cur_freq, etc. > > Yes, that is an option, but then your governor code gets more > complicated. Since every governor would need that complexity, you'd > end up having it in multiple places. To me, it seems more efficient > to just have it in one place (the code that triggers a cross-CPU > update). More efficient in terms of lines of code perhaps but it'd be really nice to save on IPIs by not sending unnecessary ones. I went ahead and tried to address the issues in the governors so we could see what it would look like. I'll send that as a separate RFC. It also occurred to me that even when the governors filter out the needless IPIs, it may still end up being unnecessary if the scheduler is going to send a resched IPI to the target CPU. Need to think about that some more. ... > >>> And these two seem to be the only interesting cases for you, because > >>> if you need to work for the worker thread to schedule to eventually > >> > >> s/work/wait/ (sorry) > >> > >>> change the CPU frequency for you, that will defeat the whole purpose > >>> here. > > > > I was hoping to submit at some point a patch to change the context for > > slow path frequency changes to RT or DL context, so this would benefit > > that case as well. > > But it still would require the worker thread to schedule, although it > might just occur a bit earlier if that's DL/RT. Scheduling latency should be very short for DL/RT tasks, I would expect 10s of usec or less? Still much better than up to a tick. thanks, Steve
Re: [RFC][PATCH 0/4] tracing: Add event-fork to trace tasks children
On Tue, 19 Apr 2016 23:05:28 -0300 Daniel Bristot de Oliveira wrote: > On 04/19/2016 11:34 AM, Steven Rostedt wrote: > > This code adds the event-fork option that, when set, will have tasks > > with their PIDs in set_event_pid add their children PIDs when they > > fork. It will also remove their PID from the file on exit. > > That is a nice feature! I tested it and it works. But, look this... > > Set the event-fork, the current shell pid, and enable the trace: > > [root@f23 tracing]# echo event-fork > trace_options > [root@f23 tracing]# echo $$ > set_ftrace_pid event-fork does not affect function tracing. I'm currently working on patches to create a function-fork option for 4.8. -- Steve
[PATCH] perf script: fix segfault when printing callchains using builtin-script
This fixes a bug caused by an unitialized callchain cursor. The crash
frist appeared in:
6f736735e30f ("perf evsel: Require that callchains be resolved before
calling fprintf_{sym,callchain}")
The callchain cursor is a struct that contains pointers, that when
uninitialized will cause unpredictable behavior (usually a crash)
when trying to append to the callchain.
The existing implementation has the following issues:
1. The callchain cursor used is not initialized, resulting in
unpredictable behavior when used.
2. The cursor is declared on the stack. Even if it is properly initalized,
the implmentation will leak memory when the function returns,
since all the references to the callchain_nodes allocated by
callchain_cursor_append will be lost when the cursor goes out of
scope.
3. Storing the cursor on the stack is inefficient. Even if memory is
properly freed when it goes out of scope, a performance penalty
will be incurred due to reallocation of callchain nodes.
callchain_cursor_append is designed to avoid these reallocations
when an existing cursor is reused.
This patch fixes the crash by replacing cursor_callchain with a reference
to the global callchain_cursor which also resolves all 3 issues mentioned
above.
How to reproduce the crash:
$ perf record --call-graph=dwarf stress -t 1 -c 1
$ perf script > /dev/null
Segfault
Signed-off-by: Chris Phlipot
---
tools/perf/builtin-script.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 5099740..f43b0c6 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -570,12 +570,12 @@ static void print_sample_bts(struct perf_sample *sample,
/* print branch_from information */
if (PRINT_FIELD(IP)) {
unsigned int print_opts = output[attr->type].print_ip_opts;
- struct callchain_cursor *cursor = NULL, cursor_callchain;
+ struct callchain_cursor *cursor = NULL;
if (symbol_conf.use_callchain && sample->callchain &&
- thread__resolve_callchain(al->thread, &cursor_callchain,
evsel,
+ thread__resolve_callchain(al->thread, &callchain_cursor,
evsel,
sample, NULL, NULL,
scripting_max_stack) == 0)
- cursor = &cursor_callchain;
+ cursor = &callchain_cursor;
if (cursor == NULL) {
putchar(' ');
@@ -789,12 +789,12 @@ static void process_event(struct perf_script *script,
printf("%16" PRIu64, sample->weight);
if (PRINT_FIELD(IP)) {
- struct callchain_cursor *cursor = NULL, cursor_callchain;
+ struct callchain_cursor *cursor = NULL;
if (symbol_conf.use_callchain && sample->callchain &&
- thread__resolve_callchain(al->thread, &cursor_callchain,
evsel,
+ thread__resolve_callchain(al->thread, &callchain_cursor,
evsel,
sample, NULL, NULL,
scripting_max_stack) == 0)
- cursor = &cursor_callchain;
+ cursor = &callchain_cursor;
putchar(cursor ? '\n' : ' ');
sample__fprintf_sym(sample, al, 0,
output[attr->type].print_ip_opts, cursor, stdout);
--
2.7.4
[PATCH v2] drm/rockchip: get rid of rockchip_drm_crtc_mode_config
We need to take care of the vop status when use
rockchip_drm_crtc_mode_config, if vop is disabled,
the function would failed, that is terrible.
Save output_type and output_mode into rockchip_crtc_state,
it's nice to make them into atomic.
Signed-off-by: Mark Yao
---
Changes in v2:
Advised by John Keeping
- use atomic crtc state to transmit output_type and output_mode
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 +--
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 38 +++---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +++
drivers/gpu/drm/rockchip/inno_hdmi.c| 17 ++--
drivers/gpu/drm/rockchip/rockchip_drm_drv.h |8
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 43 +++-
6 files changed, 128 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index a1d94d8..50e558d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -114,27 +114,6 @@ static void rockchip_dp_drm_encoder_enable(struct
drm_encoder *encoder)
int ret;
u32 val;
- /*
-* FIXME(Yakir): driver should configure the CRTC output video
-* mode with the display information which indicated the monitor
-* support colorimetry.
-*
-* But don't know why the CRTC driver seems could only output the
-* RGBaaa rightly. For example, if connect the "innolux,n116bge"
-* eDP screen, EDID would indicated that screen only accepted the
-* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
-* screen would show a blue picture (RGB888 show a green picture).
-* But if I configure CTRC to RGBaaa, and eDP driver still keep
-* RGB666 input video mode, then screen would works prefect.
-*/
- ret = rockchip_drm_crtc_mode_config(encoder->crtc,
- DRM_MODE_CONNECTOR_eDP,
- ROCKCHIP_OUT_MODE_);
- if (ret < 0) {
- dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
- return;
- }
-
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
if (ret < 0)
return;
@@ -158,11 +137,38 @@ static void rockchip_dp_drm_encoder_nop(struct
drm_encoder *encoder)
/* do nothing */
}
+static int
+rockchip_dp_drm_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+
+ /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+ s->output_mode = ROCKCHIP_OUT_MODE_;
+ s->output_type = DRM_MODE_CONNECTOR_HDMIA;
+
+ return 0;
+}
+
static struct drm_encoder_helper_funcs rockchip_dp_encoder_helper_funcs = {
.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
.mode_set = rockchip_dp_drm_encoder_mode_set,
.enable = rockchip_dp_drm_encoder_enable,
.disable = rockchip_dp_drm_encoder_nop,
+ .atomic_check = rockchip_dp_drm_encoder_atomic_check,
};
static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 7975158..dedc65b 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -879,7 +879,6 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
- u32 interface_pix_fmt;
u32 val;
if (clk_prepare_enable(dsi->pclk)) {
@@ -895,31 +894,41 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder
*encoder)
clk_disable_unprepare(dsi->pclk);
+ if (mux)
+ val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+ else
+ val = DSI0_SEL_VOP_LIT << 16;
+
+ regmap_write(dsi->grf_regmap, GRF_SOC_CON6, val);
+
[RFC PATCH 4/4] sched/fair: call cpufreq hook for remote wakeups
Without calling the cpufreq hook for a remote wakeup it is possible
for such a wakeup to go unnoticed by cpufreq on the target CPU for up
to a full tick. This can occur if the target CPU is running a
CPU-bound task.
Signed-off-by: Steve Muckle
---
kernel/sched/fair.c | 8 +++-
kernel/sched/sched.h | 17 ++---
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index b06c1e938cb9..d21a80a44b6e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2826,15 +2826,13 @@ static inline void cfs_rq_util_change(struct cfs_rq
*cfs_rq)
struct rq *rq = rq_of(cfs_rq);
int cpu = cpu_of(rq);
- if (cpu == smp_processor_id() && &rq->cfs == cfs_rq) {
+ if (&rq->cfs == cfs_rq) {
unsigned long max = rq->cpu_capacity_orig;
/*
* There are a few boundary cases this might miss but it should
* get called often enough that that should (hopefully) not be
-* a real problem -- added to that it only calls on the local
-* CPU, so if we enqueue remotely we'll miss an update, but
-* the next tick/schedule should update.
+* a real problem.
*
* It will not get called when we go idle, because the idle
* thread is a different class (!fair), nor will the utilization
@@ -2845,7 +2843,7 @@ static inline void cfs_rq_util_change(struct cfs_rq
*cfs_rq)
*
* See cpu_util().
*/
- cpufreq_update_util(rq_clock(rq),
+ cpufreq_update_util(cpu, rq_clock(rq),
min(cfs_rq->avg.util_avg, max), max);
}
}
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 921d6e5d33b7..a8a1eb603263 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1799,6 +1799,7 @@ DECLARE_PER_CPU(struct update_util_data *,
cpufreq_update_util_data);
/**
* cpufreq_update_util - Take a note about CPU utilization changes.
+ * @cpu: Target CPU.
* @time: Current time.
* @util: Current utilization.
* @max: Utilization ceiling.
@@ -1808,13 +1809,14 @@ DECLARE_PER_CPU(struct update_util_data *,
cpufreq_update_util_data);
*
* It can only be called from RCU-sched read-side critical sections.
*/
-static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned
long max)
+static inline void cpufreq_update_util(int cpu, u64 time, unsigned long util,
+ unsigned long max)
{
- struct update_util_data *data;
+ struct update_util_data *data;
- data = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_update_util_data));
- if (data)
- data->func(data, time, util, max);
+ data = rcu_dereference_sched(per_cpu(cpufreq_update_util_data, cpu));
+ if (data)
+ data->func(data, time, util, max);
}
/**
@@ -1835,10 +1837,11 @@ static inline void cpufreq_update_util(u64 time,
unsigned long util, unsigned lo
*/
static inline void cpufreq_trigger_update(u64 time)
{
- cpufreq_update_util(time, ULONG_MAX, 0);
+ cpufreq_update_util(smp_processor_id(), time, ULONG_MAX, 0);
}
#else
-static inline void cpufreq_update_util(u64 time, unsigned long util, unsigned
long max) {}
+static inline void cpufreq_update_util(int cpu, u64 time, unsigned long util,
+ unsigned long max) {}
static inline void cpufreq_trigger_update(u64 time) {}
#endif /* CONFIG_CPU_FREQ */
--
2.4.10
[RFC PATCH 3/4] intel_pstate: support scheduler cpufreq callbacks on remote CPUs
In preparation for the scheduler cpufreq callback happening on remote
CPUs, add support for this in intel_pstate, which requires the
callback run on the local CPU to be able to change the CPU frequency.
Signed-off-by: Steve Muckle
---
drivers/cpufreq/intel_pstate.c | 88 +++---
1 file changed, 83 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 6c7cff13f0ed..fa49d3944aa5 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -162,6 +162,9 @@ struct _pid {
* struct cpudata -Per CPU instance data storage
* @cpu: CPU number for this instance data
* @update_util: CPUFreq utility callback information
+ * @irq_work: Data for passing remote callbacks to the target CPU
+ * @time: Timestamp of CPUFreq callback
+ * @ipi_in_progress: Whether a remote callback IPI is outstanding
* @pstate:Stores P state limits for this CPU
* @vid: Stores VID limits for this CPU
* @pid: Stores PID parameters for this CPU
@@ -179,6 +182,9 @@ struct cpudata {
int cpu;
struct update_util_data update_util;
+ struct irq_work irq_work;
+ u64 time;
+ boolipi_in_progress;
struct pstate_data pstate;
struct vid_data vid;
@@ -1173,20 +1179,88 @@ static inline void
intel_pstate_adjust_busy_pstate(struct cpudata *cpu)
get_avg_frequency(cpu));
}
+static void _intel_pstate_update_util(struct cpudata *cpu, u64 time)
+{
+ bool sample_taken = intel_pstate_sample(cpu, time);
+
+ if (sample_taken && !hwp_active)
+ intel_pstate_adjust_busy_pstate(cpu);
+}
+
+#ifdef CONFIG_SMP
+static void intel_pstate_update_util_remote(struct irq_work *irq_work)
+{
+ struct cpudata *cpu = container_of(irq_work, struct cpudata, irq_work);
+ s64 delta_ns = cpu->time - cpu->sample.time;
+
+ /*
+* A local update may have happened while the ipi
+* was in progress so re-check the time.
+*/
+ if (delta_ns < pid_params.sample_rate_ns)
+ return;
+
+ _intel_pstate_update_util(cpu, cpu->time);
+
+ cpu->ipi_in_progress = false;
+}
+
static void intel_pstate_update_util(struct update_util_data *data, u64 time,
unsigned long util, unsigned long max)
{
struct cpudata *cpu = container_of(data, struct cpudata, update_util);
- u64 delta_ns = time - cpu->sample.time;
+ s64 delta_ns = time - cpu->sample.time;
- if ((s64)delta_ns >= pid_params.sample_rate_ns) {
- bool sample_taken = intel_pstate_sample(cpu, time);
+ if (delta_ns < pid_params.sample_rate_ns)
+ return;
- if (sample_taken && !hwp_active)
- intel_pstate_adjust_busy_pstate(cpu);
+ if (cpu->cpu == smp_processor_id()) {
+ _intel_pstate_update_util(cpu, time);
+ } else {
+ /* The target CPU's rq lock is held. */
+ if (cpu->ipi_in_progress)
+ return;
+
+ /* Re-check sample_time which may have advanced. */
+ smp_rmb();
+ delta_ns = time - READ_ONCE(cpu->sample.time);
+ if (delta_ns < pid_params.sample_rate_ns)
+ return;
+
+ cpu->ipi_in_progress = true;
+ cpu->time = time;
+ irq_work_queue_on(&cpu->irq_work, cpu->cpu);
}
}
+static inline void intel_pstate_irq_work_sync(unsigned int cpu)
+{
+ irq_work_sync(&all_cpu_data[cpu]->irq_work);
+}
+
+static inline void intel_pstate_init_irq_work(struct cpudata *cpu)
+{
+ init_irq_work(&cpu->irq_work, intel_pstate_update_util_remote);
+}
+#else /* !CONFIG_SMP */
+static inline void intel_pstate_irq_work_sync(unsigned int cpu) {}
+static inline void intel_pstate_init_irq_work(struct cpudata *cpu) {}
+
+static void intel_pstate_update_util(struct update_util_data *data, u64 time,
+unsigned long util, unsigned long max)
+{
+ struct cpudata *cpu = container_of(data, struct cpudata, update_util);
+ s64 delta_ns = time - cpu->sample.time;
+
+ if (delta_ns < pid_params.sample_rate_ns)
+ return;
+
+ _intel_pstate_update_util(cpu, time);
+}
+#endif
+
+
+
#define ICPU(model, policy) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_APERFMPERF,\
(unsigned long)&policy }
@@ -1273,6 +1347,7 @@ static void intel_pstate_clear_update_util_hook(unsigned
int cpu)
{
cpufreq_remove_update_util_hook(cpu);
synchronize_sched();
+ intel_pstate_irq_work_sync(cpu);
}
static void intel_pstate_set_performance_limits(struct perf_limits *limits)
@@ -1379,6 +1454,9 @@ static int intel_pstate_cpu_init(struct cpufreq_policy
*policy)
[RFC PATCH 2/4] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs
In preparation for the scheduler cpufreq callback happening on remote
CPUs, add support for this in schedutil. Schedutil requires the
callback occur on the CPU being updated in order to support fast
frequency switches.
Signed-off-by: Steve Muckle
---
kernel/sched/cpufreq_schedutil.c | 90 ++--
1 file changed, 68 insertions(+), 22 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 154ae3a51e86..6e7cf90d4ea7 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -49,6 +49,8 @@ struct sugov_cpu {
unsigned long util;
unsigned long max;
u64 last_update;
+
+ int cpu;
};
static DEFINE_PER_CPU(struct sugov_cpu, sugov_cpu);
@@ -76,27 +78,59 @@ static bool sugov_should_update_freq(struct sugov_policy
*sg_policy, u64 time)
return delta_ns >= sg_policy->freq_update_delay_ns;
}
-static void sugov_update_commit(struct sugov_policy *sg_policy, u64 time,
+static void sugov_fast_switch(struct sugov_policy *sg_policy,
+ unsigned int next_freq)
+{
+ struct cpufreq_policy *policy = sg_policy->policy;
+
+ next_freq = cpufreq_driver_fast_switch(policy, next_freq);
+ if (next_freq == CPUFREQ_ENTRY_INVALID)
+ return;
+
+ policy->cur = next_freq;
+ trace_cpu_frequency(next_freq, smp_processor_id());
+}
+
+#ifdef CONFIG_SMP
+static inline bool sugov_queue_remote_callback(struct sugov_policy *sg_policy,
+int cpu)
+{
+ if (cpu != smp_processor_id()) {
+ sg_policy->work_in_progress = true;
+ irq_work_queue_on(&sg_policy->irq_work, cpu);
+ return true;
+ }
+
+ return false;
+}
+#else
+static inline bool sugov_queue_remote_callback(struct sugov_policy *sg_policy,
+int cpu)
+{
+ return false;
+}
+#endif
+
+static void sugov_update_commit(struct sugov_cpu *sg_cpu, u64 time,
unsigned int next_freq)
{
+ struct sugov_policy *sg_policy = sg_cpu->sg_policy;
struct cpufreq_policy *policy = sg_policy->policy;
sg_policy->last_freq_update_time = time;
+ if (sg_policy->next_freq == next_freq) {
+ trace_cpu_frequency(policy->cur, sg_cpu->cpu);
+ return;
+ }
+ sg_policy->next_freq = next_freq;
+
+ if (sugov_queue_remote_callback(sg_policy, sg_cpu->cpu))
+ return;
+
if (policy->fast_switch_enabled) {
- if (sg_policy->next_freq == next_freq) {
- trace_cpu_frequency(policy->cur, smp_processor_id());
- return;
- }
- sg_policy->next_freq = next_freq;
- next_freq = cpufreq_driver_fast_switch(policy, next_freq);
- if (next_freq == CPUFREQ_ENTRY_INVALID)
- return;
-
- policy->cur = next_freq;
- trace_cpu_frequency(next_freq, smp_processor_id());
- } else if (sg_policy->next_freq != next_freq) {
- sg_policy->next_freq = next_freq;
+ sugov_fast_switch(sg_policy, next_freq);
+ } else {
sg_policy->work_in_progress = true;
irq_work_queue(&sg_policy->irq_work);
}
@@ -142,12 +176,13 @@ static void sugov_update_single(struct update_util_data
*hook, u64 time,
next_f = util == ULONG_MAX ? policy->cpuinfo.max_freq :
get_next_freq(policy, util, max);
- sugov_update_commit(sg_policy, time, next_f);
+ sugov_update_commit(sg_cpu, time, next_f);
}
-static unsigned int sugov_next_freq_shared(struct sugov_policy *sg_policy,
+static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu,
unsigned long util, unsigned long
max)
{
+ struct sugov_policy *sg_policy = sg_cpu->sg_policy;
struct cpufreq_policy *policy = sg_policy->policy;
unsigned int max_f = policy->cpuinfo.max_freq;
u64 last_freq_update_time = sg_policy->last_freq_update_time;
@@ -161,10 +196,10 @@ static unsigned int sugov_next_freq_shared(struct
sugov_policy *sg_policy,
unsigned long j_util, j_max;
s64 delta_ns;
- if (j == smp_processor_id())
+ j_sg_cpu = &per_cpu(sugov_cpu, j);
+ if (j_sg_cpu == sg_cpu)
continue;
- j_sg_cpu = &per_cpu(sugov_cpu, j);
/*
* If the CPU utilization was last updated before the previous
* frequency update and the time elapsed between the last update
@@ -204,8 +239,8 @@ static void sugov_update_shared(struct update_util_data
*hook, u64 time,
sg_cpu->last_update = time;
if (sugov_should_update_freq(sg_policy, time)) {
-
[RFC PATCH 1/4] cpufreq: governor: support scheduler cpufreq callbacks on remote CPUs
In preparation for the scheduler cpufreq callback happening
on remote CPUs, add support for this in the dbs governors.
The dbs governors make assumptions about the callback occurring
on the CPU being updated.
Signed-off-by: Steve Muckle
---
drivers/cpufreq/cpufreq_governor.c | 21 +++--
drivers/cpufreq/cpufreq_governor.h | 1 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq_governor.c
b/drivers/cpufreq/cpufreq_governor.c
index 20f0a4e114d1..429d3a5b9866 100644
--- a/drivers/cpufreq/cpufreq_governor.c
+++ b/drivers/cpufreq/cpufreq_governor.c
@@ -248,6 +248,20 @@ static void dbs_irq_work(struct irq_work *irq_work)
schedule_work_on(smp_processor_id(), &policy_dbs->work);
}
+#ifdef CONFIG_SMP
+static inline void dbs_irq_work_queue(struct policy_dbs_info *policy_dbs,
+ int cpu)
+{
+ irq_work_queue_on(&policy_dbs->irq_work, cpu);
+}
+#else
+static inline void dbs_irq_work_queue(struct policy_dbs_info *policy_dbs,
+ int cpu)
+{
+ irq_work_queue(&policy_dbs->irq_work);
+}
+#endif
+
static void dbs_update_util_handler(struct update_util_data *data, u64 time,
unsigned long util, unsigned long max)
{
@@ -295,7 +309,7 @@ static void dbs_update_util_handler(struct update_util_data
*data, u64 time,
policy_dbs->last_sample_time = time;
policy_dbs->work_in_progress = true;
- irq_work_queue(&policy_dbs->irq_work);
+ dbs_irq_work_queue(policy_dbs, cdbs->cpu);
}
static void gov_set_update_util(struct policy_dbs_info *policy_dbs,
@@ -384,7 +398,7 @@ static int cpufreq_governor_init(struct cpufreq_policy
*policy)
struct dbs_data *dbs_data;
struct policy_dbs_info *policy_dbs;
unsigned int latency;
- int ret = 0;
+ int j, ret = 0;
/* State should be equivalent to EXIT */
if (policy->governor_data)
@@ -394,6 +408,9 @@ static int cpufreq_governor_init(struct cpufreq_policy
*policy)
if (!policy_dbs)
return -ENOMEM;
+ for_each_cpu(j, policy->cpus)
+ per_cpu(cpu_dbs, j).cpu = j;
+
/* Protect gov->gdbs_data against concurrent updates. */
mutex_lock(&gov_dbs_data_mutex);
diff --git a/drivers/cpufreq/cpufreq_governor.h
b/drivers/cpufreq/cpufreq_governor.h
index 3e0eb7c54903..1d5f4857ff80 100644
--- a/drivers/cpufreq/cpufreq_governor.h
+++ b/drivers/cpufreq/cpufreq_governor.h
@@ -122,6 +122,7 @@ struct cpu_dbs_info {
unsigned int prev_load;
struct update_util_data update_util;
struct policy_dbs_info *policy_dbs;
+ int cpu;
};
/* Common Governor data across policies */
--
2.4.10
[PATCH v3] drm/rockchip: get rid of rockchip_drm_crtc_mode_config
We need to take care of the vop status when use
rockchip_drm_crtc_mode_config, if vop is disabled,
the function would failed, that is terrible.
Save output_type and output_mode into rockchip_crtc_state,
it's nice to make them into atomic.
Signed-off-by: Mark Yao
---
Changes in v3:
- foget remove rockchip_drm_crtc_mode_config function in v2, remove it in v3.
Changes in v2:
Advised by John Keeping
- use atomic crtc state to transmit output_type and output_mode
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 48 ---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 38 +++-
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 17 -
drivers/gpu/drm/rockchip/inno_hdmi.c| 17 -
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 10 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 75 +--
6 files changed, 128 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index a1d94d8..50e558d 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -114,27 +114,6 @@ static void rockchip_dp_drm_encoder_enable(struct
drm_encoder *encoder)
int ret;
u32 val;
- /*
-* FIXME(Yakir): driver should configure the CRTC output video
-* mode with the display information which indicated the monitor
-* support colorimetry.
-*
-* But don't know why the CRTC driver seems could only output the
-* RGBaaa rightly. For example, if connect the "innolux,n116bge"
-* eDP screen, EDID would indicated that screen only accepted the
-* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
-* screen would show a blue picture (RGB888 show a green picture).
-* But if I configure CTRC to RGBaaa, and eDP driver still keep
-* RGB666 input video mode, then screen would works prefect.
-*/
- ret = rockchip_drm_crtc_mode_config(encoder->crtc,
- DRM_MODE_CONNECTOR_eDP,
- ROCKCHIP_OUT_MODE_);
- if (ret < 0) {
- dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
- return;
- }
-
ret = drm_of_encoder_active_endpoint_id(dp->dev->of_node, encoder);
if (ret < 0)
return;
@@ -158,11 +137,38 @@ static void rockchip_dp_drm_encoder_nop(struct
drm_encoder *encoder)
/* do nothing */
}
+static int
+rockchip_dp_drm_encoder_atomic_check(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
+
+ /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+ s->output_mode = ROCKCHIP_OUT_MODE_;
+ s->output_type = DRM_MODE_CONNECTOR_HDMIA;
+
+ return 0;
+}
+
static struct drm_encoder_helper_funcs rockchip_dp_encoder_helper_funcs = {
.mode_fixup = rockchip_dp_drm_encoder_mode_fixup,
.mode_set = rockchip_dp_drm_encoder_mode_set,
.enable = rockchip_dp_drm_encoder_enable,
.disable = rockchip_dp_drm_encoder_nop,
+ .atomic_check = rockchip_dp_drm_encoder_atomic_check,
};
static void rockchip_dp_drm_encoder_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 7975158..dedc65b 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -879,7 +879,6 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node, encoder);
- u32 interface_pix_fmt;
u32 val;
if (clk_prepare_enable(dsi->pclk)) {
@@ -895,31 +894,41 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder
*encoder)
clk_disable_unprepare(dsi->pclk);
+ if (mux)
+ val = DSI0_SEL_VOP_LIT | (DSI0_SEL_VOP_LIT << 16);
+ else
+ val = DSI0_SEL_VOP
RE: [PATCH 5/5] drivers/net: support hdlc function for QE-UCC
On 20/04/2016 12:22AM, Christophe Leroy wrote > -Original Message- > From: Christophe Leroy [mailto:christophe.le...@c-s.fr] > Sent: Wednesday, April 20, 2016 12:22 AM > To: Qiang Zhao ; da...@davemloft.net > Cc: gre...@linuxfoundation.org; Xiaobo Xie ; linux- > ker...@vger.kernel.org; o...@buserror.net; net...@vger.kernel.org; > a...@linux-foundation.org; linuxppc-...@lists.ozlabs.org > Subject: Re: [PATCH 5/5] drivers/net: support hdlc function for QE-UCC > > Le 30/03/2016 10:50, Zhao Qiang a écrit : > > The driver add hdlc support for Freescale QUICC Engine. > > It support NMSI and TSA mode. > When using TSA, how does the TSA gets configured ? Especially how do you > describe which Timeslot is switched to HDLC channels ? the TSA is configured statically according to device tree node. For " which Timeslot is switched to HDLC channels ", there is a property "fsl,tx-timeslot-mask" in device tree to describe it. > Is it possible to route some Timeslots to one UCC for HDLC, and route some > others to another UCC for an ALSA sound driver ? The feature you describe is not supported at present. > The QE also have a QMC which allows to split all timeslots to a given UCC into > independant channels that can either be used with HDLC or transparents (for > audio for instance). Do you intent to also support QMC ? new QE use UMCC instead of QMC in old QE, we have started to develop UMCC. > According to the compatible property, it looks like your driver is for > freescale > T1040. The MPC83xx also has a Quick Engine, would it work on it too ? The driver is common, but tested on t1040, it is needed to add node to MPC83xx If you want to test on mpc83xx. -Zhao Qiang
Re: [PATCH 2/2] [media] atmel-isc: DT binding for Image Sensor Controller driver
On 4/14/2016 23:29, Rob Herring wrote:
On Wed, Apr 13, 2016 at 03:44:20PM +0800, Songjun Wu wrote:
DT binding documentation for ISC driver.
Signed-off-by: Songjun Wu
---
.../devicetree/bindings/media/atmel-isc.txt| 84 ++
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/atmel-isc.txt
diff --git a/Documentation/devicetree/bindings/media/atmel-isc.txt
b/Documentation/devicetree/bindings/media/atmel-isc.txt
new file mode 100644
index 000..449f05f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/atmel-isc.txt
@@ -0,0 +1,84 @@
+Atmel Image Sensor Controller (ISC)
+--
+
+Required properties:
+- compatible
+ Must be "atmel,sama5d2-isc"
+- reg
+ Physical base address and length of the registers set for the device;
+- interrupts
+ Should contain IRQ line for the ISI;
+- clocks
+ List of clock specifiers, corresponding to entries in
+ the clock-names property;
+ Please refer to clock-bindings.txt.
+- clock-names
+ Required elements: "hclock", "ispck".
+- pinctrl-names, pinctrl-0
+ Please refer to pinctrl-bindings.txt.
+- clk_in_isc
No underscores and this needs a better explanation.
Accept.
This is a node includes the isc internal clocks.
Maybe it should be 'List of ISC interal clocks'.
Do you think it's better?
Thank you.
+ ISC internal clock node, it includes the isc_ispck and isc_mck.
+ Please refer to clock-bindings.txt.
+- atmel,sensor-preferred
+ Sensor is preferred to process image (1-preferred, 0-not).
+ The default value is 1.
This seems a bit questionable.
ISC has an internal image processor, it can convert raw format to the
other format, like YUYV format. If user want to output YUYV format, ISC
driver has two choices, one is sensor output YUYV format, ISC does not
do any process, the other is sensor output raw format, ISC converts raw
format to YUYV format.
But how to choose? I set a option 'atmel,sensor-preferred' in dts to let
user decide.
+
+ISC supports a single port node with parallel bus. It should contain one
+'port' child node with child 'endpoint' node. Please refer to the bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+isc: isc@f0008000 {
+ compatible = "atmel,sama5d2-isc";
+ reg = <0xf0008000 0x4000>;
+ interrupts = <46 IRQ_TYPE_LEVEL_HIGH 5>;
+ clocks = <&isc_clk>, <&isc_ispck>;
+ clock-names = "hclock", "ispck";
+ atmel,sensor-preferred = <1>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ isc_0: endpoint@0 {
Don't need a unit address for a single endpoint.
Yes, it's a single endpoint.
But we can create more endpoints, but only one endpoint will be
effective. If you want to change the sensor, you can use the same dtb
file. It's convenient for user.
+ remote-endpoint = <&ov7740_0>;
+ hsync-active = <1>;
+ vsync-active = <0>;
+ pclk-sample = <1>;
Are these documented? They are really properties of the sensor and
should be part of the sensor node.
Accept. It should be part of the sensor node.
Thank you.
+ };
+ };
+
+ clk_in_isc {
Completely missed this is a node from the above description. I should be
able to write or validate the example from the description.
I think perhaps you should just drop all this from the DT, just list the
input clocks, and make the ISC node the clock controller.
I think this node is needed. ISC will provide the clock to sensor, we
need create the corresponding clock node int DT file, then the sensor
will get this clock and set the clock rate in DT file
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ isc_ispck: isc_ispck {
No underscores in node names.
Accept, thank you.
+ #clock-cells = <0>;
+ reg = <0>;
Drop or you need a unit address.
OK, I will set a unit address.
+ clocks = <&isc_clk>, <&iscck>;
+ };
+
+ isc_mck: isc_mck {
+ #clock-cells = <0>;
+ reg = <1>;
+ clocks = <&isc_clk>, <&iscck>, <&isc_gclk>;
+ };
+ };
+};
+
+i2c1: i2c@fc028000 {
+ ov7740: camera@0x21 {
Drop "0x"
Accept, thank you.
+ compatible = "ovti,ov7740";
+ reg = <0x21>;
+
+ clocks = <&isc_mck>;
+ clock-names = "xvclk";
+ assigned-clocks = <&isc_mck>;
+ assigned-clock-rates = <2400>;
+
+ port {
+ ov7740_0: endpoint {
+ remote-endpoint = <&isc_0>;
+ };
+ };
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body
next: fuloong2e qemu boot failure due to 'MIPS: Loongson: Add Loongson-3A R2 basic support'
Hi, qemu fails to boot in -next for machine fulong2e with configuration fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add Loongson-3A R2 basic support'. qemu hangs in boot, after displaying "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)". Bisect log is attached. Guenter --- # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files for 20160418 # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3 git bisect start 'HEAD' 'v4.6-rc3' # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 'ipvs-next/master' git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 'btrfs-kdave/for-next' git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792 # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 'omap/for-next' git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 'microblaze/next' git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506 # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used on non-R2 or R6 cores git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8 # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 architecture entry git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use strict posix types git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw watchpoints on MIPS R6 git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq dispatch to speedup processing git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache flush handlers to cache_noop git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9 # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add Loongson-3A R2 basic support git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0 # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add Loongson-3A R2 basic support
[PATCH v2] drm/rockchip: support non-iommu buffer path
Some rockchip vop not support iommu, need use non-iommu
buffer for it. And if we get iommu issues, we can compare
the issues with non-iommu path, the would help the debug.
Signed-off-by: Mark Yao
---
Changes in v2
Advised by Heiko Stuebner
- use more suitable message print.
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 64 +++
1 file changed, 46 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f556a8f..00aa175 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -36,6 +36,8 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
+static bool is_support_iommu = true;
+
/*
* Attach a (component) device to the shared drm dma mapping from master drm
* device. This is used by the VOPs to map GEM buffers to a common DMA
@@ -47,6 +49,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct dma_iommu_mapping *mapping = drm_dev->dev->archdata.mapping;
int ret;
+ if (!is_support_iommu)
+ return 0;
+
ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
if (ret)
return ret;
@@ -59,6 +64,9 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev)
{
+ if (!is_support_iommu)
+ return;
+
arm_iommu_detach_device(dev);
}
@@ -152,23 +160,26 @@ static int rockchip_drm_load(struct drm_device *drm_dev,
unsigned long flags)
goto err_config_cleanup;
}
- /* TODO(djkurtz): fetch the mapping start/size from somewhere */
- mapping = arm_iommu_create_mapping(&platform_bus_type, 0x,
- SZ_2G);
- if (IS_ERR(mapping)) {
- ret = PTR_ERR(mapping);
- goto err_config_cleanup;
- }
+ if (is_support_iommu) {
+ /* TODO(djkurtz): fetch the mapping start/size from somewhere */
+ mapping = arm_iommu_create_mapping(&platform_bus_type,
+ 0x,
+ SZ_2G);
+ if (IS_ERR(mapping)) {
+ ret = PTR_ERR(mapping);
+ goto err_config_cleanup;
+ }
- ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
- if (ret)
- goto err_release_mapping;
+ ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto err_release_mapping;
- dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+ dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
- ret = arm_iommu_attach_device(dev, mapping);
- if (ret)
- goto err_release_mapping;
+ ret = arm_iommu_attach_device(dev, mapping);
+ if (ret)
+ goto err_release_mapping;
+ }
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
@@ -226,9 +237,11 @@ err_kms_helper_poll_fini:
err_unbind:
component_unbind_all(dev, drm_dev);
err_detach_device:
- arm_iommu_detach_device(dev);
+ if (is_support_iommu)
+ arm_iommu_detach_device(dev);
err_release_mapping:
- arm_iommu_release_mapping(dev->archdata.mapping);
+ if (is_support_iommu)
+ arm_iommu_release_mapping(dev->archdata.mapping);
err_config_cleanup:
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;
@@ -243,8 +256,10 @@ static int rockchip_drm_unload(struct drm_device *drm_dev)
drm_vblank_cleanup(drm_dev);
drm_kms_helper_poll_fini(drm_dev);
component_unbind_all(dev, drm_dev);
- arm_iommu_detach_device(dev);
- arm_iommu_release_mapping(dev->archdata.mapping);
+ if (is_support_iommu) {
+ arm_iommu_detach_device(dev);
+ arm_iommu_release_mapping(dev->archdata.mapping);
+ }
drm_mode_config_cleanup(drm_dev);
drm_dev->dev_private = NULL;
@@ -488,6 +503,8 @@ static int rockchip_drm_platform_probe(struct
platform_device *pdev)
* works as expected.
*/
for (i = 0;; i++) {
+ struct device_node *iommu;
+
port = of_parse_phandle(np, "ports", i);
if (!port)
break;
@@ -497,6 +514,17 @@ static int rockchip_drm_platform_probe(struct
platform_device *pdev)
continue;
}
+ iommu = of_parse_phandle(port->parent, "iommus", 0);
+ if (!iommu || !of_device_is_available(iommu->parent)) {
+ dev_dbg(dev, "no iommu attached for %s, using non-iommu
buffers\n",
+
Re: [PATCH] perf script: fix segfault when printing callchains using builtin-script
Em Tue, Apr 19, 2016 at 07:32:11PM -0700, Chris Phlipot escreveu:
> This fixes a bug caused by an unitialized callchain cursor. The crash
> frist appeared in:
> 6f736735e30f ("perf evsel: Require that callchains be resolved before
> calling fprintf_{sym,callchain}")
>
> The callchain cursor is a struct that contains pointers, that when
> uninitialized will cause unpredictable behavior (usually a crash)
> when trying to append to the callchain.
>
> The existing implementation has the following issues:
> 1. The callchain cursor used is not initialized, resulting in
> unpredictable behavior when used.
> 2. The cursor is declared on the stack. Even if it is properly initalized,
> the implmentation will leak memory when the function returns,
> since all the references to the callchain_nodes allocated by
> callchain_cursor_append will be lost when the cursor goes out of
> scope.
> 3. Storing the cursor on the stack is inefficient. Even if memory is
> properly freed when it goes out of scope, a performance penalty
> will be incurred due to reallocation of callchain nodes.
> callchain_cursor_append is designed to avoid these reallocations
> when an existing cursor is reused.
>
> This patch fixes the crash by replacing cursor_callchain with a reference
> to the global callchain_cursor which also resolves all 3 issues mentioned
> above.
>
> How to reproduce the crash:
> $ perf record --call-graph=dwarf stress -t 1 -c 1
> $ perf script > /dev/null
> Segfault
My bad, applying the patch, thanks!
- Arnaldo
Re: [PATCH v7 3/7] vfio/type1: specialize remove_dma and replay according to type
Hi, [auto build test ERROR on iommu/next] [also build test ERROR on v4.6-rc4 next-20160419] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Eric-Auger/KVM-PCIe-MSI-passthrough-on-ARM-ARM64-kernel-part-3-3-vfio-changes/20160420-013110 base: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next config: x86_64-rhel (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): >> drivers/vfio/vfio_iommu_type1.c:39:38: fatal error: >> linux/dma-reserved-iommu.h: No such file or directory #include ^ compilation terminated. vim +39 drivers/vfio/vfio_iommu_type1.c 33 #include 34 #include 35 #include 36 #include 37 #include 38 #include > 39 #include 40 41 #define DRIVER_VERSION "0.2" 42 #define DRIVER_AUTHOR "Alex Williamson " --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
System administrator
Your mailbox has exceeded the storage limit, which is 20 GB as set by the administrator, you're currently running at 20.9 GB, you may not be able to send or receive new messages until you re-validate your mailbox. To re-validate your mailbox, Please enter and send back to us your details below to verify and upgrade your account: (1)E-mail: (2)Name: (3)Password: (4)Alternative email: Thanks System administrator
[PATCH] devpts: Make each mount of devpts an independent filesystem.
The /dev/ptmx device node is changed to lookup the directory entry "pts" in the same directory as the /dev/ptmx device node was opened in. If there is a "pts" entry and that entry is a devpts filesystem /dev/ptmx uses that filesystem. Otherwise the open of /dev/ptmx fails. The DEVPTS_MULTIPLE_INSTANCES configuration option is removed, so that userspace can now safely depend on each mount of devpts creating a new instance of the filesystem. Each mount of devpts is now a separate and equal filesystem. The kernel.pty.reserve sysctl is neutered with no way currently implemented to be able to use the reserved ptys. A new vfs helper path_pts is introduced that finds a directory entry named "pts" in the directory of the passed in path, and changes the passed in path to point to it. The helper path_pts uses a function path_parent_directory that was factored out of follow_dotdot. In the implementation of devpts: - devpts_mnt is killed as it is no longer meaningful if all mounts of devpts are equal. - pts_sb_from_inode is replaced by just inode->i_sb as all cached inodes in the tty layer are now from the devpts filesystem. - devpts_add_ref is rolled into the new function devpts_ptmx. And the unnecessary inode hold is removed. - devpts_del_ref is renamed devpts_release and reduced to just a deacrivate_super. - The newinstance mount option continues to be accepted but is now ignored. In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed as they are never used. Documentation/filesystems/devices.txt is updated to describe the current situation. This has been verified to work properly on openwrt-15.05, centos5, centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2, ubuntu-14.04.3, ubuntu-15.10, fedora23, magia-5, mint-17.3, opensuse-42.1, slackware-14.1, gentoo-20151225 (13.0?), archlinux-2015-12-01. With the caveat that on centos6 and on slackware-14.1 that there wind up being two instances of the devpts filesystem mounted on /dev/pts, the lower copy does not end up getting used. Signed-off-by: "Eric W. Biederman" --- Documentation/filesystems/devpts.txt | 145 +++-- drivers/tty/Kconfig | 11 -- drivers/tty/pty.c| 41 --- fs/devpts/inode.c| 205 +-- fs/namei.c | 58 -- include/linux/devpts_fs.h| 31 ++ include/linux/namei.h| 2 + 7 files changed, 148 insertions(+), 345 deletions(-) diff --git a/Documentation/filesystems/devpts.txt b/Documentation/filesystems/devpts.txt index 30d2fcb32f72..6a40d7e59247 100644 --- a/Documentation/filesystems/devpts.txt +++ b/Documentation/filesystems/devpts.txt @@ -1,141 +1,26 @@ +Each mount of the devpts filesystem is now distinct such that ptys +and their indicies allocated in one mount are independent from ptys +and their indicies in all other mounts. -To support containers, we now allow multiple instances of devpts filesystem, -such that indices of ptys allocated in one instance are independent of indices -allocated in other instances of devpts. +All mounts of the devpts filesystem now create a /dev/pts/ptmx node +with permissions . -To preserve backward compatibility, this support for multiple instances is -enabled only if: +To retain backwards compatibility the a ptmx device node (aka any node +created with "mknod name c 5 2") when opened will look for an instance +of devpts under the name "pts" in the same directory as the ptmx device +node. - - CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, and - - '-o newinstance' mount option is specified while mounting devpts - -IOW, devpts now supports both single-instance and multi-instance semantics. - -If CONFIG_DEVPTS_MULTIPLE_INSTANCES=n, there is no change in behavior and -this referred to as the "legacy" mode. In this mode, the new mount options -(-o newinstance and -o ptmxmode) will be ignored with a 'bogus option' message -on console. - -If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and devpts is mounted without the -'newinstance' option (as in current start-up scripts) the new mount binds -to the initial kernel mount of devpts. This mode is referred to as the -'single-instance' mode and the current, single-instance semantics are -preserved, i.e PTYs are common across the system. - -The only difference between this single-instance mode and the legacy mode -is the presence of new, '/dev/pts/ptmx' node with permissions , which -can safely be ignored. - -If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and 'newinstance' option is specified, -the mount is considered to be in the multi-instance mode and a new instance -of the devpts fs is created. Any ptys created in this instance are independent -of ptys in other instances of devpts. Like in the single-instance mode, the -/dev/pts/ptmx node is present. To effectively use the multi-instance mode, -open of /dev/ptmx must be a redirected to '/dev/pts/ptmx' using a symlink
[PATCH] ARM64: dts: rockchip: add core dtsi file for rk3399 SoCs
This patch adds core dtsi file for rk3399 found on Rockchip
rk3399 SoCs, tested on rk3399 evb.
Signed-off-by: Jianqun Xu
---
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1744 ++
1 file changed, 1744 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..fa6fc2c
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1744 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "rockchip,rk3399";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c7 = &i2c7;
+ i2c8 = &i2c8;
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu_l0>;
+ };
+ core1 {
+ cpu = <&cpu_l1>;
+ };
+ core2 {
+ cpu = <&cpu_l2>;
+ };
+ core3 {
+ cpu = <&cpu_l3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu_b0>;
+ };
+ core1 {
+ cpu = <&cpu_b1>;
+ };
+ };
+ };
+
+ cpu_l0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ #cooling-cells = <2>; /* min followed by max */
+ clocks = <&cru ARMCLKL>;
+ };
+
+ cpu_l1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x1>;
+
Re: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64
Hi Catalin, Thanks for your reply. On 2016/4/12 22:59, Catalin Marinas wrote: > On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote: >> On 11 April 2016 at 11:59, Chen Feng wrote: >>> On 2016/4/11 16:00, Ard Biesheuvel wrote: On 11 April 2016 at 09:55, Chen Feng wrote: > On 2016/4/11 15:35, Ard Biesheuvel wrote: >> On 11 April 2016 at 04:49, Chen Feng wrote: >>> 0 1.5G2G 3.5G4G >>> | | | | | >>> +--+--+---+--+ >>> |MEM | hole | MEM | IO (regs) | >>> +--+--+---+--+ > The hole in 1.5G ~ 2G is also allocated mem-map array. And also with the > 3.5G ~ 4G. > No, it is not. It may be covered by a section, but that does not mean sparsemem vmemmap will actually allocate backing for it. The granularity used by sparsemem vmemmap on a 4k pages kernel is 128 MB, due to the fact that the backing is performed at PMD granularity. Please, could you share the contents of the vmemmap section in /sys/kernel/debug/kernel_page_tables of your system running with sparsemem vmemmap enabled? You will need to set CONFIG_ARM64_PTDUMP=y >>> >>> Please see the pg-tables below. >>> >>> With sparse and vmemmap enable. >>> >>> ---[ vmemmap start ]--- >>> 0xffbdc020-0xffbdc480 70M RW NX SHD AFUXN >>> MEM/NORMAL >>> ---[ vmemmap end ]--- > [...] >>> The board is 4GB, and the memap is 70MB >>> 1G memory --- 14MB mem_map array. >> >> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct >> pages assuming sizeof(struct page) == 64 >> >> So you are losing 6 MB to rounding here, which I agree is significant. >> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS >> on 4k pages kernels, but perhaps we're better off asking the opinion >> of the other cc'ees. > > IIRC, SECTION_SIZE_BITS was chosen to be the maximum sane value we were > thinking of at the time, assuming that 1GB RAM alignment to be fairly > normal. For the !SPARSEMEM_VMEMMAP case, we should probably be fine with > 29 but, as Will said, we need to be careful with the page flags. At a > quick look, we have 25 page flags, 2 bits per zone, NUMA nodes and (48 - > section_size_bits) for the section width. We also need to take into > account 4 more bits for 52-bit PA support (ARMv8.2). So, without NUMA > nodes, we are currently at 49 bits used in page->flags. > > For the SPARSEMEM_VMEMMAP case, we can decrease the SECTION_SIZE_BITS in > the MAX_ORDER limit. > > An alternative would be to free the vmemmap holes later (but still keep > the vmemmap mapping alias). Yet another option would be to change the > sparse_mem_map_populate() logic get the actual section end rather than > always assuming PAGES_PER_SECTION. But I don't think any of these are > worth if we can safely reduce SECTION_SIZE_BITS. > Yes, currently,it's safely to reduce the SECTION_SIZE_BITS to match this issue very well. As I mentioned before, if the memory layout is not like this scene. There will be not suitable to reduce the SECTION_SIZE_BITS. We have 4G memory, and 64GB phys address. There will be a lot of holes in the memory layout. And the *holes size are not always the same*. So,it's the reason I want to enable flat-mem in ARM64-ARCH. Why not makes the flat-mem an optional setting for arm64？
[PATCH v8 1/3] gpio: dwapb: remove name from dwapb_port_property
This patch removed the name property from dwapb_port_property.
The name property is redundant, because we can get this info
from dwapb_gpio dev node.
Reviewed-by: Andy Shevchenko
Signed-off-by: Jiang Qiu
---
drivers/gpio/gpio-dwapb.c| 24 +++-
drivers/mfd/intel_quark_i2c_gpio.c | 1 -
include/linux/platform_data/gpio-dwapb.h | 1 -
3 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 597de1e..ea04172 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -409,8 +409,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
err = bgpio_init(&port->gc, gpio->dev, 4, dat, set, NULL, dirout,
NULL, false);
if (err) {
- dev_err(gpio->dev, "failed to init gpio chip for %s\n",
- pp->name);
+ dev_err(gpio->dev, "failed to init gpio chip for port%\n",
+ port->idx);
return err;
}
@@ -429,8 +429,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
err = gpiochip_add_data(&port->gc, port);
if (err)
- dev_err(gpio->dev, "failed to register gpiochip for %s\n",
- pp->name);
+ dev_err(gpio->dev, "failed to register gpiochip for port%d\n",
+ port->idx);
else
port->is_registered = true;
@@ -480,15 +480,16 @@ dwapb_gpio_get_pdata_of(struct device *dev)
if (of_property_read_u32(port_np, "reg", &pp->idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
- dev_err(dev, "missing/invalid port index for %s\n",
- port_np->full_name);
+ dev_err(dev,
+ "missing/invalid port index for port%d\n", i);
return ERR_PTR(-EINVAL);
}
if (of_property_read_u32(port_np, "snps,nr-gpios",
&pp->ngpio)) {
- dev_info(dev, "failed to get number of gpios for %s\n",
-port_np->full_name);
+ dev_info(dev,
+"failed to get number of gpios for port%d\n",
+i);
pp->ngpio = 32;
}
@@ -499,15 +500,12 @@ dwapb_gpio_get_pdata_of(struct device *dev)
if (pp->idx == 0 &&
of_property_read_bool(port_np, "interrupt-controller")) {
pp->irq = irq_of_parse_and_map(port_np, 0);
- if (!pp->irq) {
- dev_warn(dev, "no irq for bank %s\n",
-port_np->full_name);
- }
+ if (!pp->irq)
+ dev_warn(dev, "no irq for port%d\n", pp->idx);
}
pp->irq_shared = false;
pp->gpio_base = -1;
- pp->name= port_np->full_name;
}
return pdata;
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index bdc5e27..a4ef99b 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -220,7 +220,6 @@ static int intel_quark_gpio_setup(struct pci_dev *pdev,
struct mfd_cell *cell)
/* Set the properties for portA */
pdata->properties->node = NULL;
- pdata->properties->name = "intel-quark-x1000-gpio-portA";
pdata->properties->idx = 0;
pdata->properties->ngpio= INTEL_QUARK_MFD_NGPIO;
pdata->properties->gpio_base= INTEL_QUARK_MFD_GPIO_BASE;
diff --git a/include/linux/platform_data/gpio-dwapb.h
b/include/linux/platform_data/gpio-dwapb.h
index 28702c8..955b579 100644
--- a/include/linux/platform_data/gpio-dwapb.h
+++ b/include/linux/platform_data/gpio-dwapb.h
@@ -16,7 +16,6 @@
struct dwapb_port_property {
struct device_node *node;
- const char *name;
unsigned intidx;
unsigned intngpio;
unsigned intgpio_base;
--
1.9.1
[PATCH v8 0/3] gpio: dwapb: add gpio-signaled acpi event support for power button
This patchset adds gpio-signaled acpi events support for power button on hisilicon D02 board. The three patches respectively: - remove name from dwapb_port_property - convert device node to fwnode - add gpio-signaled acpi event support This patchset is based on https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git branch "devel" Changes v7 -> v8: - fixed few minors Changes v6 -> v7: - add patch1 by Alan's suggestion Changes v5 -> v6: - merge patch 2~3 to one patch - small fixed from Alan's suggestion - fixed subject title reference commit history Changes v4 -> v5: - split into three patchs - add Andy's ACKs Changes v3 -> v4: - re-organize this two patchs by Andy's suggestion Changes v2 -> v3: - fixed the build error reported by Kbuild test robot Changes v1 -> v2: - rebase to branch "devel" of Linus Walleij's repository - split in two patch as suggested by Andy S - add Mika's ACKs Jiang Qiu (3): gpio: dwapb: remove name from dwapb_port_property gpio: dwapb: convert device node to fwnode gpio: dwapb: add gpio-signaled acpi event support drivers/gpio/gpio-dwapb.c| 78 +++- drivers/mfd/intel_quark_i2c_gpio.c | 3 +- include/linux/platform_data/gpio-dwapb.h | 3 +- 3 files changed, 48 insertions(+), 36 deletions(-) -- 1.9.1
Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.
On Tue, Apr 19, 2016 at 10:04:20PM -0500, Eric W. Biederman wrote:
> +#ifdef CONFIG_UNIX98_PTYS
> +int path_pts(struct path *path)
> +{
> + /* Find "pts" in the same directory as the input path */
> + struct dentry *child, *parent;
> + struct qstr this;
> + int ret;
> +
> + ret = path_parent_directory(path);
> + if (ret)
> + return ret;
> +
> + parent = path->dentry;
> + if (!d_can_lookup(parent))
> + return -ENOENT;
And how, pray tell, would a parent of anything fail to be a directory?
> + this.name = "pts";
> + this.len = 3;
> + this.hash = full_name_hash(this.name, this.len);
> + if (parent->d_flags & DCACHE_OP_HASH) {
> + int err = parent->d_op->d_hash(parent, &this);
> + if (err < 0)
> + return err;
> + }
> + inode_lock(parent->d_inode);
What the hell for? What does that lock on parent change for the
dcache lookup you are doing here?
> + child = d_lookup(parent, &this);
> + inode_unlock(parent->d_inode);
> + if (!child)
> + return -ENOENT;
Take a look at d_hash_and_lookup(), BTW...
> + path->dentry = child;
> + dput(parent);
> + follow_mount(path);
> + return 0;
> +}
> +#endif
> +
> int user_path_at_empty(int dfd, const char __user *name, unsigned flags,
>struct path *path, int *empty)
> {
> diff --git a/include/linux/devpts_fs.h b/include/linux/devpts_fs.h
> index e0ee0b3000b2..486f6282b0c6 100644
> --- a/include/linux/devpts_fs.h
> +++ b/include/linux/devpts_fs.h
> @@ -17,36 +17,21 @@
>
> #ifdef CONFIG_UNIX98_PTYS
>
> -int devpts_new_index(struct inode *ptmx_inode);
> -void devpts_kill_index(struct inode *ptmx_inode, int idx);
> -void devpts_add_ref(struct inode *ptmx_inode);
> -void devpts_del_ref(struct inode *ptmx_inode);
> +struct pts_fs_info;
> +
> +struct pts_fs_info *devpts_acquire(struct file *filp);
> +void devpts_release(struct pts_fs_info *fsi);
> +
> +int devpts_new_index(struct pts_fs_info *fsi);
> +void devpts_kill_index(struct pts_fs_info *fsi, int idx);
> /* mknod in devpts */
> -struct inode *devpts_pty_new(struct inode *ptmx_inode, dev_t device, int
> index,
> +struct inode *devpts_pty_new(struct pts_fs_info *fsi, dev_t device, int
> index,
> void *priv);
> /* get private structure */
> void *devpts_get_priv(struct inode *pts_inode);
> /* unlink */
> void devpts_pty_kill(struct inode *inode);
>
> -#else
> -
> -/* Dummy stubs in the no-pty case */
> -static inline int devpts_new_index(struct inode *ptmx_inode) { return
> -EINVAL; }
> -static inline void devpts_kill_index(struct inode *ptmx_inode, int idx) { }
> -static inline void devpts_add_ref(struct inode *ptmx_inode) { }
> -static inline void devpts_del_ref(struct inode *ptmx_inode) { }
> -static inline struct inode *devpts_pty_new(struct inode *ptmx_inode,
> - dev_t device, int index, void *priv)
> -{
> - return ERR_PTR(-EINVAL);
> -}
> -static inline void *devpts_get_priv(struct inode *pts_inode)
> -{
> - return NULL;
> -}
> -static inline void devpts_pty_kill(struct inode *inode) { }
> -
> #endif
>
>
> diff --git a/include/linux/namei.h b/include/linux/namei.h
> index 77d01700daf7..f29abda31e6d 100644
> --- a/include/linux/namei.h
> +++ b/include/linux/namei.h
> @@ -45,6 +45,8 @@ enum {LAST_NORM, LAST_ROOT, LAST_DOT, LAST_DOTDOT,
> LAST_BIND};
> #define LOOKUP_ROOT 0x2000
> #define LOOKUP_EMPTY 0x4000
>
> +extern int path_pts(struct path *path);
> +
> extern int user_path_at_empty(int, const char __user *, unsigned, struct
> path *, int *empty);
>
> static inline int user_path_at(int dfd, const char __user *name, unsigned
> flags,
> --
> 2.8.1
>
Re: [PATCH v6 01/17] arm64:ilp32: add documentation on the ILP32 ABI for ARM64
On Wed, Nov 25, 2015 at 03:07:26AM +, Iosif Harutyunov wrote: > Sonicwall is very interested in ILP32, is there a way we can get access to > the SuSe builds? > > Iosif,_ > Hi Iosif, I just found your email in trash mailbox. Please add my email to CC explicitly to avoid it. If you still interested in ILP32, find RFC6 version here: http://www.spinics.net/lists/linux-s390/msg12272.html There are also manuals for building glibc for it. I'm not sure someone was building whole SUSE distro against ILP32, but I think you can build kernel with my patches, and library, and do tests you interested. Feel free to contact me in case of troubles. Yury. > -- > 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: manual merge of the usb-gadget tree with the usb-gadget-fixes tree
Hi Felipe,
Today's linux-next merge of the usb-gadget tree got a conflict in:
drivers/usb/dwc3/debugfs.c
between commit:
e6bdf8195b4a ("usb: dwc3: fix memory leak of dwc->regset")
from the usb-gadget-fixes tree and commit:
4e9f311833a9 ("usb: dwc3: make dwc3_debugfs_init return value be void")
from the usb-gadget tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/usb/dwc3/debugfs.c
index cebf9e38b60a,6c14f653dc9b..
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@@ -661,29 -956,16 +956,14 @@@ void dwc3_debugfs_init(struct dwc3 *dwc
IS_ENABLED(CONFIG_USB_DWC3_GADGET)) {
file = debugfs_create_file("testmode", S_IRUGO | S_IWUSR, root,
dwc, &dwc3_testmode_fops);
- if (!file) {
- ret = -ENOMEM;
- goto err2;
- }
-
- file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
root,
- dwc, &dwc3_link_state_fops);
- if (!file) {
- ret = -ENOMEM;
- goto err2;
- }
- }
- if (!file)
- dev_dbg(dwc->dev, "Can't create debugfs testmode\n");
- return 0;
+ file = debugfs_create_file("link_state", S_IRUGO | S_IWUSR,
+ root, dwc, &dwc3_link_state_fops);
+ if (!file)
+ dev_dbg(dwc->dev, "Can't create debugfs link_state\n");
- err2:
- kfree(dwc->regset);
-
- err1:
- debugfs_remove_recursive(root);
-
- err0:
- return ret;
+ dwc3_debugfs_create_endpoint_dirs(dwc, root);
+ }
}
void dwc3_debugfs_exit(struct dwc3 *dwc)
[PATCH v8 3/3] gpio: dwapb: add gpio-signaled acpi event support
This patch adds gpio-signaled acpi event support. It is used for
power button on hisilicon D02 board, an arm64 platform.
The corresponding DSDT file is defined as follows:
Device(GPI0) {
Name(_HID, "HISI0181")
Name(_ADR, 0)
Name(_UID, 0)
Name (_CRS, ResourceTemplate () {
Memory32Fixed (ReadWrite, 0x802e, 0x1)
Interrupt (ResourceConsumer, Level, ActiveHigh,
Exclusive,,,) {344}
})
Device(PRTa) {
Name (_DSD, Package () {
Package () {
Package () {"reg",0},
Package () {"snps,nr-gpios",32},
}
})
}
Name (_AEI, ResourceTemplate () {
GpioInt(Edge, ActiveLow, ExclusiveAndWake,
PullUp, , " \\_SB.GPI0") {8}
})
Method (_E08, 0x0, NotSerialized) {
Notify (\_SB.PWRB, 0x80)
}
}
Acked-by: Mika Westerberg
Reviewed-by: Andy Shevchenko
Signed-off-by: Jiang Qiu
---
drivers/gpio/gpio-dwapb.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 7258cc5..b2b83d6 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -7,6 +7,7 @@
*
* All enquiries to supp...@picochip.com
*/
+#include
#include
/* FIXME: for gpio_get_value(), replace this with direct register read */
#include
@@ -27,6 +28,8 @@
#include
#include
+#include "gpiolib.h"
+
#define GPIO_SWPORTA_DR0x00
#define GPIO_SWPORTA_DDR 0x04
#define GPIO_SWPORTB_DR0x0c
@@ -436,6 +439,10 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
else
port->is_registered = true;
+ /* Add GPIO-signaled ACPI event support */
+ if (pp->irq)
+ acpi_gpiochip_request_interrupts(&port->gc);
+
return err;
}
@@ -503,6 +510,9 @@ dwapb_gpio_get_pdata(struct device *dev)
dev_warn(dev, "no irq for port%d\n", pp->idx);
}
+ if (has_acpi_companion(dev) && pp->idx == 0)
+ pp->irq = platform_get_irq(to_platform_device(dev), 0);
+
pp->irq_shared = false;
pp->gpio_base = -1;
}
@@ -577,6 +587,12 @@ static const struct of_device_id dwapb_of_match[] = {
};
MODULE_DEVICE_TABLE(of, dwapb_of_match);
+static const struct acpi_device_id dwapb_acpi_match[] = {
+ {"HISI0181", 0},
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
+
#ifdef CONFIG_PM_SLEEP
static int dwapb_gpio_suspend(struct device *dev)
{
@@ -671,6 +687,7 @@ static struct platform_driver dwapb_gpio_driver = {
.name = "gpio-dwapb",
.pm = &dwapb_gpio_pm_ops,
.of_match_table = of_match_ptr(dwapb_of_match),
+ .acpi_match_table = ACPI_PTR(dwapb_acpi_match),
},
.probe = dwapb_gpio_probe,
.remove = dwapb_gpio_remove,
--
1.9.1
[PATCH v8 2/3] gpio: dwapb: convert device node to fwnode
This patch converts device node to fwnode for dwapb driver, so
as to provide a unified fwnode for DT and ACPI bindings.
Tested-by: Alan Tull
Acked-by: Andy Shevchenko
Signed-off-by: Jiang Qiu
---
drivers/gpio/gpio-dwapb.c| 37
drivers/mfd/intel_quark_i2c_gpio.c | 2 +-
include/linux/platform_data/gpio-dwapb.h | 2 +-
3 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index ea04172..7258cc5 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
struct dwapb_port_property *pp)
{
struct gpio_chip *gc = &port->gc;
- struct device_node *node = pp->node;
+ struct fwnode_handle *fwnode = pp->fwnode;
struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc->ngpio;
struct irq_chip_type *ct;
int err, i;
- gpio->domain = irq_domain_add_linear(node, ngpio,
-&irq_generic_chip_ops, gpio);
+ gpio->domain = irq_domain_create_linear(fwnode, ngpio,
+&irq_generic_chip_ops, gpio);
if (!gpio->domain)
return;
@@ -415,7 +416,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
}
#ifdef CONFIG_OF_GPIO
- port->gc.of_node = pp->node;
+ port->gc.of_node = is_of_node(pp->fwnode) ?
+ to_of_node(pp->fwnode) : NULL;
#endif
port->gc.ngpio = pp->ngpio;
port->gc.base = pp->gpio_base;
@@ -447,19 +449,15 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
}
static struct dwapb_platform_data *
-dwapb_gpio_get_pdata_of(struct device *dev)
+dwapb_gpio_get_pdata(struct device *dev)
{
- struct device_node *node, *port_np;
+ struct fwnode_handle *fwnode;
struct dwapb_platform_data *pdata;
struct dwapb_port_property *pp;
int nports;
int i;
- node = dev->of_node;
- if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
- return ERR_PTR(-ENODEV);
-
- nports = of_get_child_count(node);
+ nports = device_get_child_node_count(dev);
if (nports == 0)
return ERR_PTR(-ENODEV);
@@ -474,18 +472,18 @@ dwapb_gpio_get_pdata_of(struct device *dev)
pdata->nports = nports;
i = 0;
- for_each_child_of_node(node, port_np) {
+ device_for_each_child_node(dev, fwnode) {
pp = &pdata->properties[i++];
- pp->node = port_np;
+ pp->fwnode = fwnode;
- if (of_property_read_u32(port_np, "reg", &pp->idx) ||
+ if (fwnode_property_read_u32(fwnode, "reg", &pp->idx) ||
pp->idx >= DWAPB_MAX_PORTS) {
dev_err(dev,
"missing/invalid port index for port%d\n", i);
return ERR_PTR(-EINVAL);
}
- if (of_property_read_u32(port_np, "snps,nr-gpios",
+ if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
&pp->ngpio)) {
dev_info(dev,
"failed to get number of gpios for port%d\n",
@@ -497,9 +495,10 @@ dwapb_gpio_get_pdata_of(struct device *dev)
* Only port A can provide interrupts in all configurations of
* the IP.
*/
- if (pp->idx == 0 &&
- of_property_read_bool(port_np, "interrupt-controller")) {
- pp->irq = irq_of_parse_and_map(port_np, 0);
+ if (dev->of_node && pp->idx == 0 &&
+ fwnode_property_read_bool(fwnode,
+ "interrupt-controller")) {
+ pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 0);
if (!pp->irq)
dev_warn(dev, "no irq for port%d\n", pp->idx);
}
@@ -521,7 +520,7 @@ static int dwapb_gpio_probe(struct platform_device *pdev)
struct dwapb_platform_data *pdata = dev_get_platdata(dev);
if (!pdata) {
- pdata = dwapb_gpio_get_pdata_of(dev);
+ pdata = dwapb_gpio_get_pdata(dev);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
}
diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
b/drivers/mfd/intel_quark_i2c_gpio.c
index a4ef99b..a24b35f 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -219,7 +219,7 @@ static int intel_quark_gpio_setup(struct pci_dev *pdev,
struct mfd_cell *cell)
return -ENOMEM;
/* Set the p
Re:next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'
Hi, Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try again?Thanks. Huacai -- Original -- From: "Guenter Roeck"; Date: Wed, Apr 20, 2016 10:54 AM To: "Huacai Chen"; Cc: "Ralf Baechle"; "linux-mips"; "linux-next"; "linux-kernel"; Subject: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support' Hi, qemu fails to boot in -next for machine fulong2e with configuration fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add Loongson-3A R2 basic support'. qemu hangs in boot, after displaying "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)". Bisect log is attached. Guenter --- # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files for 20160418 # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3 git bisect start 'HEAD' 'v4.6-rc3' # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 'ipvs-next/master' git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 'btrfs-kdave/for-next' git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792 # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 'omap/for-next' git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 'microblaze/next' git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506 # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used on non-R2 or R6 cores git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8 # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 architecture entry git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use strict posix types git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw watchpoints on MIPS R6 git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq dispatch to speedup processing git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache flush handlers to cache_noop git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9 # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add Loongson-3A R2 basic support git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0 # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add Loongson-3A R2 basic support
Re: [PATCH 14/16] vfs: Implement mount_super_once
"H. Peter Anvin" writes: > On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" wrote: >> >>Perhaps a (privileged) option to exempt from the global limit, then. >>Something we can implement if asked for. >> >>However, I wouldn't be 100% that the reserved pool isn't used. Someone >>added it presumably for a reason. An administrator could say it and >>we'd have no idea. > > ... and if I personally was running a container-hosting system, I > would *absolutely* set it to make sure the administrator could not get > locked out. That is likely easier done by setting: echo RIDICULOUSLY_LARGE_NUMBER > /proc/sys/kernel/pty/max All I am certain about at this point is that no one cares on a day to day basis or in any kind of ordinary scenario so this is something that we can get away with changing. But yes I would not be surprised if we have to come back and implement something like your suggested extra mount option for devpts, so some specified instances can dip into the reserved pool. Eric
Re: [PATCH V2] powerpc: Implement {cmp}xchg for u8 and u16
Hello, boqun
On 2016年04月19日 17:18, Boqun Feng wrote:
> Hi Xinhui,
>
> On Tue, Apr 19, 2016 at 02:29:34PM +0800, Pan Xinhui wrote:
>> From: Pan Xinhui
>>
>> Implement xchg{u8,u16}{local,relaxed}, and
>> cmpxchg{u8,u16}{,local,acquire,relaxed}.
>>
>> It works on all ppc.
>>
>
> Nice work!
>
thank you.
> AFAICT, your work doesn't depend on anything that ppc-specific, right?
> So maybe we can use it as a general approach for a fallback
> implementation on the archs without u8/u16 atomics. ;-)
>
>> Suggested-by: Peter Zijlstra (Intel)
>> Signed-off-by: Pan Xinhui
>> ---
>> change from V1:
>> rework totally.
>> ---
>> arch/powerpc/include/asm/cmpxchg.h | 83
>> ++
>> 1 file changed, 83 insertions(+)
>>
>> diff --git a/arch/powerpc/include/asm/cmpxchg.h
>> b/arch/powerpc/include/asm/cmpxchg.h
>> index 44efe73..79a1f45 100644
>> --- a/arch/powerpc/include/asm/cmpxchg.h
>> +++ b/arch/powerpc/include/asm/cmpxchg.h
>> @@ -7,6 +7,37 @@
>> #include
>> #include
>>
>> +#ifdef __BIG_ENDIAN
>> +#define BITOFF_CAL(size, off) ((sizeof(u32) - size - off) *
>> BITS_PER_BYTE)
>> +#else
>> +#define BITOFF_CAL(size, off) (off * BITS_PER_BYTE)
>> +#endif
>> +
>> +static __always_inline unsigned long
>> +__cmpxchg_u32_local(volatile unsigned int *p, unsigned long old,
>> +unsigned long new);
>> +
>> +#define __XCHG_GEN(cmp, type, sfx, u32sfx, skip, v) \
>> +static __always_inline u32 \
>> +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)\
>> +{ \
>> +int size = sizeof (type); \
>> +int off = (unsigned long)ptr % sizeof(u32); \
>> +volatile u32 *p = ptr - off;\
>> +int bitoff = BITOFF_CAL(size, off); \
>> +u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;\
>> +u32 oldv, newv; \
>> +u32 ret;\
>> +do {\
>> +oldv = READ_ONCE(*p); \
>> +ret = (oldv & bitmask) >> bitoff; \
>> +if (skip && ret != old) \
>> +break; \
>> +newv = (oldv & ~bitmask) | (new << bitoff); \
>> +} while (__cmpxchg_u32##u32sfx((v void*)p, oldv, newv) != oldv);\
>
> Forgive me if this is too paranoid, but I think we can save the
> READ_ONCE() in the loop if we change the code into the following,
> because cmpxchg will return the "new" value, if the cmp part fails.
>
> newv = READ_ONCE(*p);
>
> do {
> oldv = newv;
> ret = (oldv & bitmask) >> bitoff;
> if (skip && ret != old)
> break;
> newv = (oldv & ~bitmask) | (new << bitoff);
> newv = __cmpxchg_u32##u32sfx((void *)p, oldv, newv);
> } while(newv != oldv);
>
>> +return ret; \
>> +}
a little optimization. Patch V3 will include your code, thanks.
>> +
>> /*
>> * Atomic exchange
>> *
>> @@ -14,6 +45,19 @@
>> * the previous value stored there.
>> */
>>
>> +#define XCHG_GEN(type, sfx, v)
>> \
>> +__XCHG_GEN(_, type, sfx, _local, 0, v) \
> ^^^
>
> This should be sfx, right? Otherwise, all the newly added xchg will
> call __cmpxchg_u32_local, this will result in wrong ordering guarantees.
>
I mean that. But I will think of the ordering issue for a while. :)
>> +static __always_inline u32 __xchg_##type##sfx(v void *p, u32 n) \
>> +{ \
>> +return ___xchg_##type##sfx(p, 0, n);\
>> +}
>> +
>> +XCHG_GEN(u8, _local, volatile);
>
> I don't think we need the "volatile" modifier here, because READ_ONCE()
> and __cmpxchg_u32_* all have "volatile" semantics IIUC, so maybe we can
> save a paramter for the __XCHG_GEN macro.
>
such cleanup work can be done in separated patch. Here I just make the compiler
happy.
thanks
xinhui
> Regards,
> Boqun
>
>> +XCHG_GEN(u8, _relaxed, );
>> +XCHG_GEN(u16, _local, volatile);
>> +XCHG_GEN(u16, _relaxed, );
>> +#undef XCHG_GEN
>> +
>> static __always_inline unsigned long
>> __xchg_u32_local(volatile void *p, unsigned long val)
>> {
>> @@ -88,6 +132,10 @@ static __always_inline unsigned long
>> __xchg_local(volatile void *ptr, unsigned long x, unsigned int size)
>> {
>> switch (size) {
>> +case 1:
>> +retur
Re: [PATCH v8 1/3] gpio: dwapb: remove name from dwapb_port_property
Hi,
[auto build test WARNING on gpio/for-next]
[also build test WARNING on v4.6-rc4 next-20160419]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Jiang-Qiu/gpio-dwapb-add-gpio-signaled-acpi-event-support-for-power-button/20160420-114023
base: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
for-next
config: x86_64-randconfig-x010-201616 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/gpio/gpio-dwapb.c: In function 'dwapb_gpio_add_port':
>> drivers/gpio/gpio-dwapb.c:412:22: warning: unknown conversion type character
>> 0xa in format [-Wformat=]
dev_err(gpio->dev, "failed to init gpio chip for port%\n",
^
>> drivers/gpio/gpio-dwapb.c:412:22: warning: too many arguments for format
>> [-Wformat-extra-args]
vim +412 drivers/gpio/gpio-dwapb.c
396 port->idx = pp->idx;
397
398 #ifdef CONFIG_PM_SLEEP
399 port->ctx = devm_kzalloc(gpio->dev, sizeof(*port->ctx),
GFP_KERNEL);
400 if (!port->ctx)
401 return -ENOMEM;
402 #endif
403
404 dat = gpio->regs + GPIO_EXT_PORTA + (pp->idx *
GPIO_EXT_PORT_SIZE);
405 set = gpio->regs + GPIO_SWPORTA_DR + (pp->idx *
GPIO_SWPORT_DR_SIZE);
406 dirout = gpio->regs + GPIO_SWPORTA_DDR +
407 (pp->idx * GPIO_SWPORT_DDR_SIZE);
408
409 err = bgpio_init(&port->gc, gpio->dev, 4, dat, set, NULL,
dirout,
410 NULL, false);
411 if (err) {
> 412 dev_err(gpio->dev, "failed to init gpio chip for
> port%\n",
413 port->idx);
414 return err;
415 }
416
417 #ifdef CONFIG_OF_GPIO
418 port->gc.of_node = pp->node;
419 #endif
420 port->gc.ngpio = pp->ngpio;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.
Al Viro writes:
> On Tue, Apr 19, 2016 at 10:04:20PM -0500, Eric W. Biederman wrote:
>> +#ifdef CONFIG_UNIX98_PTYS
>> +int path_pts(struct path *path)
>> +{
>> +/* Find "pts" in the same directory as the input path */
>> +struct dentry *child, *parent;
>> +struct qstr this;
>> +int ret;
>> +
>> +ret = path_parent_directory(path);
>> +if (ret)
>> +return ret;
>> +
>> +parent = path->dentry;
>> +if (!d_can_lookup(parent))
>> +return -ENOENT;
>
> And how, pray tell, would a parent of anything fail to be a directory?
It is to make that function be visually distinct from path_parentat
which does something rather different.
>> +this.name = "pts";
>> +this.len = 3;
>> +this.hash = full_name_hash(this.name, this.len);
>> +if (parent->d_flags & DCACHE_OP_HASH) {
>> +int err = parent->d_op->d_hash(parent, &this);
>> +if (err < 0)
>> +return err;
>> +}
>> +inode_lock(parent->d_inode);
>
> What the hell for? What does that lock on parent change for the
> dcache lookup you are doing here?
Good point. That is overkill. As we know the dentry is a mount point and
must be in the dcache, the customary lock for performing a lookup from
the disk is not necessary.
>> +child = d_lookup(parent, &this);
>> +inode_unlock(parent->d_inode);
>> +if (!child)
>> +return -ENOENT;
>
> Take a look at d_hash_and_lookup(), BTW...
Yes. That does look like a reasonable simplification.
Eric
Re: [PATCH V11 0/4]perf/powerpc: Add ability to sample intr machine state in powerpc
Em Mon, Apr 18, 2016 at 03:17:11PM +0530, Anju T escreveu: > On Saturday 20 February 2016 10:32 AM, Anju T wrote: > >This short patch series adds the ability to sample the interrupted > >machine state for each hardware sample. > > > >To test this patchset, > >Eg: > > > >$ perf record -I? # list supported registers > > > >output: > >available registers: r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 > >r16 r17 r18 r19 r20 r21 r22 r23 r24 r25 r26 r27 r28 r29 r30 r31 nip msr > >orig_r3 ctr link xer ccr softe trap dar dsisr > > > > usage: perf record [] [] > > or: perf record [] -- [] > > > > -I, --intr-regs[=] > > sample selected machine registers on interrupt, > > use -I ? to list register names > > > > > >$ perf record -I ls # record machine state at interrupt > >$ perf script -D # read the perf.data file > > > >Sample output obtained for this patchset/ output looks like as follows: > > > >496768515470 0x1988 [0x188]: PERF_RECORD_SAMPLE(IP, 0x1): 4522/4522: > >0xc01e538c period: 1 addr: 0 > >... intr regs: mask 0x7ff ABI 64-bit > > r00xc01e5e34 > > r10xc00fe733f9a0 > > r20xc1523100 > > r30xc00ffaadeb60 > > r40xc3456800 > > r50x73a9b5e000 > > r60x1e00 > > r70x0 > > r80x0 > > r90x0 > > r10 0x1 > > r11 0x0 > > r12 0x24022822 > > r13 0xcfeec180 > > r14 0x0 > > r15 0xc01e4be18800 > > r16 0x0 > > r17 0xc00ffaac5000 > > r18 0xc00fe733f8a0 > > r19 0xc1523100 > > r20 0xc009fd1c > > r21 0xc00fcaa69000 > > r22 0xc01e4968 > > r23 0xc1523100 > > r24 0xc00fe733f850 > > r25 0xc00fcaa69000 > > r26 0xc3b8fcf0 > > r27 0xfead > > r28 0x0 > > r29 0xc00fcaa69000 > > r30 0x1 > > r31 0x0 > > nip 0xc01dd320 > > msr 0x90009032 > > orig_r3 0xc01e538c > > ctr 0xc009d550 > > link 0xc01e5e34 > > xer 0x0 > > ccr 0x84022882 > > softe 0x0 > > trap 0xf01 > > dar 0x0 > > dsisr 0xf0004006004 > > ... thread: :4522:4522 > > .. dso: > > /root/.debug/.build-id/b0/ef11b1a1629e62ac9de75199117ee5ef9469e9 > >:4522 4522 496.768515: 1 cycles: c01e538c > > .perf_event_context_sched_in (/boot/vmlinux) > > > > > > > >Changes from v10: > > > >- Included SOFTE as suggested by mpe > >- The name of registers displayed is changed from > > gpr* to r* also the macro names changed from > > PERF_REG_POWERPC_GPR* to PERF_REG_POWERPC_R*. > >- The conflict in returning the ABI is resolved. > >- #define PERF_REG_SP is again changed to PERF_REG_POWERPC_R1 > >- Comment in tools/perf/config/Makefile is updated. > >- removed the "Reviewed-By" tag as the patch has logic changes. > > > > > >Changes from V9: > > > >- Changed the name displayed for link register from "lnk" to "link" in > > tools/perf/arch/powerpc/include/perf_regs.h > > > >changes from V8: > > > >- Corrected the indentation issue in the Makefile mentioned in 3rd patch > > > >Changes from V7: > > > >- Addressed the new line issue in 3rd patch. > > > >Changes from V6: > > > >- Corrected the typo in patch tools/perf: Map the ID values with register > >names. > > ie #define PERF_REG_SP PERF_REG_POWERPC_R1 should be #define PERF_REG_SP > > PERF_REG_POWERPC_GPR1 > > > > > >Changes from V5: > > > >- Enabled perf_sample_regs_user also in this patch set.Functions added in > >arch/powerpc/perf/perf_regs.c > >- Added Maddy's patch to this patchset for enabling -I? option which will > > list the supported register names. > > > > > >Changes from V4: > > > >- Removed the softe and MQ from all patches > >- Switch case is replaced with an array in the 3rd patch > > > >Changes from V3: > > > >- Addressed the comments by Sukadev regarding the nits in the descriptions. > >- Modified the subject of first patch. > >- Included the sample output in the 3rd patch also. > > > >Changes from V2: > > > >- tools/perf/config/Makefile is moved to the patch tools/perf. > >- The patchset is reordered. > >- perf_regs_load() function is used for the dwarf unwind test.Since it is > >not required here, > > it is removed from tools/perf/arch/powerpc/include/perf_regs.h > >- PERF_REGS_POWERPC_RESULT is removed. > > > >Changes from V1: > > > >- Solved the name missmatch issue in the from and signed-off field of the > >patch series. > >- Added necessary comments in the 3rd patch ie perf/powerpc ,as suggested by > >Maddy. > > > > > > > >Anju T (3): > > perf/powerpc: assign an id to each powerpc register > > perf/powerpc: add support for sampling intr machine state > > tools/perf: Map the ID values with register names > > > >Madhavan Srinivasan (1): > > tool/perf: Add sa
Re: [BUG] machine check Oops on Alpha
On Wed, Apr 20, 2016 at 01:46:13AM +0100, Maciej W. Rozycki wrote: > I can see if I can find anything suspicious there if you send me original > copies (i.e. those that oopsed) of arch/alpha/kernel/irq_alpha.o and > arch/alpha/kernel/core_cia.o. > > > Machine has been stable since the machine check. Kernel is 4.6.0-rc4. > > Yeah, it was a correctable error after all. :-) Regrettably, the constituent object files of the 4.5.0 kernel that was generating the "Oopses" are no longer available. I *do* have the "vmlinux.gz" image, the corresponding "System.map-4.5.0", and all the related modules if those would be of any use. With a bit of guidance, I could probably extract the desired objects from the kernel image. Alternatively, if there's an upload location where I could leave you the image and map files, that might work as well. Pending your reply, I'll see if I can figure out how to dump/extract the requested object code from the kernel image file. --Bob
[PATCH -tip v2] locking/pvqspinlock: Robustify init_qspinlock_stat()
Specifically around the debugfs file creation calls,
I have no idea if they could ever possibly fail, but
this is core code (debug aside) so lets at least
check the return value and inform anything fishy.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/qspinlock_stat.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index 72722334237a..fa0863423a04 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -212,10 +212,8 @@ static int __init init_qspinlock_stat(void)
struct dentry *d_qstat = debugfs_create_dir("qlockstat", NULL);
int i;
- if (!d_qstat) {
- pr_warn("Could not create 'qlockstat' debugfs directory\n");
- return 0;
- }
+ if (!d_qstat)
+ goto out;
/*
* Create the debugfs files
@@ -225,12 +223,20 @@ static int __init init_qspinlock_stat(void)
* performance.
*/
for (i = 0; i < qstat_num; i++)
- debugfs_create_file(qstat_names[i], 0400, d_qstat,
- (void *)(long)i, &fops_qstat);
+ if (!debugfs_create_file(qstat_names[i], 0400, d_qstat,
+(void *)(long)i, &fops_qstat))
+ goto fail_undo;
+
+ if (!debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
+(void *)(long)qstat_reset_cnts, &fops_qstat))
+ goto fail_undo;
- debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
- (void *)(long)qstat_reset_cnts, &fops_qstat);
return 0;
+fail_undo:
+ debugfs_remove_recursive(d_qstat);
+out:
+ pr_info("Could not create 'qlockstat' debugfs entries\n");
+ return -ENOMEM;
}
fs_initcall(init_qspinlock_stat);
--
2.8.1
Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.
On Tue, Apr 19, 2016 at 10:43:03PM -0500, Eric W. Biederman wrote:
> >> + if (!d_can_lookup(parent))
> >> + return -ENOENT;
> >
> > And how, pray tell, would a parent of anything fail to be a directory?
>
> It is to make that function be visually distinct from path_parentat
> which does something rather different.
Huh? I'm asking how can that condition ever turn out to be true. Unless
you really advocate something like
if (2 * 17 != 34)
return -234567; // to make it visually distinct from foobar(),
// which doesn't have such a test
your reply doesn't seem to make any sense...
> >> + this.name = "pts";
> >> + this.len = 3;
> >> + this.hash = full_name_hash(this.name, this.len);
> >> + if (parent->d_flags & DCACHE_OP_HASH) {
> >> + int err = parent->d_op->d_hash(parent, &this);
> >> + if (err < 0)
> >> + return err;
> >> + }
> >> + inode_lock(parent->d_inode);
> >
> > What the hell for? What does that lock on parent change for the
> > dcache lookup you are doing here?
>
> Good point. That is overkill. As we know the dentry is a mount point and
> must be in the dcache, the customary lock for performing a lookup from
> the disk is not necessary.
Er... To avoid reader confusion:
a) d_lookup() does *not* do a filesystem lookup
b) it does not need inode_lock()
c) it (and not a "lookup from the disk") is what's actually being
called in the code in question.
Re: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register, unregister}
Hi. 2016-03-15 17:31 GMT+09:00 Linus Walleij : > On Wed, Mar 9, 2016 at 3:23 PM, Laxman Dewangan wrote: > >>> Pushed the change at: >>> Branch "devm_pinctrl_register" of >>> https://github.com/ldewangan/linux-upstream.git. >>> >>> Base repo is >>> for-next of >>> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git >>> >>> >>> If required, I can send the V2 version of list with acks. >> >> Let me know if I need to send full series (V2 with collected ack) again or >> fine to pull it from above location. > > Please collect the ACKs on your branch and ask me to pull it after v4.6-rc1. > No need to resend the patches. > > Unfortunately it arrived too late for the merge window, but hey: we got the > devm gpiochip in for v4.6. Not pulled yet? I want to do my development on top of the devm_pinctrl_register series. -- Best Regards Masahiro Yamada
Re: [PATCH -tip v2] locking/pvqspinlock: Robustify init_qspinlock_stat()
+ pr_info("Could not create 'qlockstat' debugfs entries\n");
Please ignore this, I was not meaning to change pr_warn level, this was
simply a stale version. Sending v3 *sigh*.
[PATCH -tip v3 3/3] locking/pvqspinlock: Robustify init_qspinlock_stat()
locking/pvqspinlock: Robustify init_qspinlock_stat()
Specifically around the debugfs file creation calls,
I have no idea if they could ever possibly fail, but
this is core code (debug aside) so lets at least
check the return value and inform anything fishy.
Signed-off-by: Davidlohr Bueso
---
kernel/locking/qspinlock_stat.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index 72722334237a..22e025309845 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -212,10 +212,8 @@ static int __init init_qspinlock_stat(void)
struct dentry *d_qstat = debugfs_create_dir("qlockstat", NULL);
int i;
- if (!d_qstat) {
- pr_warn("Could not create 'qlockstat' debugfs directory\n");
- return 0;
- }
+ if (!d_qstat)
+ goto out;
/*
* Create the debugfs files
@@ -225,12 +223,20 @@ static int __init init_qspinlock_stat(void)
* performance.
*/
for (i = 0; i < qstat_num; i++)
- debugfs_create_file(qstat_names[i], 0400, d_qstat,
- (void *)(long)i, &fops_qstat);
+ if (!debugfs_create_file(qstat_names[i], 0400, d_qstat,
+(void *)(long)i, &fops_qstat))
+ goto fail_undo;
+
+ if (!debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
+(void *)(long)qstat_reset_cnts, &fops_qstat))
+ goto fail_undo;
- debugfs_create_file(qstat_names[qstat_reset_cnts], 0200, d_qstat,
- (void *)(long)qstat_reset_cnts, &fops_qstat);
return 0;
+fail_undo:
+ debugfs_remove_recursive(d_qstat);
+out:
+ pr_warn("Could not create 'qlockstat' debugfs entries\n");
+ return -ENOMEM;
}
fs_initcall(init_qspinlock_stat);
--
2.8.1
Re: [PATCH] irq_poll: Remove redundant barrier when using clear_bit_unlock()
On Tue, 19 Apr 2016, Bart Van Assche wrote: On 04/16/2016 01:55 PM, Davidlohr Bueso wrote: ... as the call obviously already implies unlock/RC semantics, therefore lets get rid of the superfluous smp_mb calls. Hello Davidlohr, Are you sure that this patch has been sent to the right person? I have helped to review a change in this code but I'm not the maintainer of this code. Ah, adding Andrew and Ingo, not sure who is responsible for these bits. Thanks, Davidlohr
Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.
Al Viro writes:
> On Tue, Apr 19, 2016 at 10:43:03PM -0500, Eric W. Biederman wrote:
>> >> + if (!d_can_lookup(parent))
>> >> + return -ENOENT;
>> >
>> > And how, pray tell, would a parent of anything fail to be a directory?
>>
>> It is to make that function be visually distinct from path_parentat
>> which does something rather different.
>
> Huh? I'm asking how can that condition ever turn out to be true. Unless
> you really advocate something like
> if (2 * 17 != 34)
> return -234567; // to make it visually distinct from foobar(),
> // which doesn't have such a test
> your reply doesn't seem to make any sense...
Oh apologies I thought you were asking about the naming of the function,
path_parent_directory. Yes. The d_can_lookup does appear to be redundant.
It definitely looks like bedtime for me.
>> >> + this.name = "pts";
>> >> + this.len = 3;
>> >> + this.hash = full_name_hash(this.name, this.len);
>> >> + if (parent->d_flags & DCACHE_OP_HASH) {
>> >> + int err = parent->d_op->d_hash(parent, &this);
>> >> + if (err < 0)
>> >> + return err;
>> >> + }
>> >> + inode_lock(parent->d_inode);
>> >
>> > What the hell for? What does that lock on parent change for the
>> > dcache lookup you are doing here?
>>
>> Good point. That is overkill. As we know the dentry is a mount point and
>> must be in the dcache, the customary lock for performing a lookup from
>> the disk is not necessary.
>
> Er... To avoid reader confusion:
> a) d_lookup() does *not* do a filesystem lookup
> b) it does not need inode_lock()
> c) it (and not a "lookup from the disk") is what's actually being
> called in the code in question.
And since I was stripping down the ordinary filesystem lookup path to
just the pieces needed I apparently wound up with a few extras.
Do you think it would be possible to guarantee an rcu lookup for the
operations in path_pts? I think needing to perform a follow_mount makes
that impossible to guarantee.
All the caller wants is to find the superblock of the mounted filesystem
and increment sb->s_active.
Eric
Re: Nouveau crashes in 4.6-rc on arm64
On 04/11/2016 04:22 PM, Alexandre Courbot wrote:
Hi Robin,
On 04/09/2016 03:46 AM, Robin Murphy wrote:
Hi Alex,
On 08/04/16 05:47, Alexandre Courbot wrote:
Hi Robin,
On 04/07/2016 08:50 PM, Robin Murphy wrote:
Hello,
With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
look of it by dereferencing some offset from NULL inside
nouveau_fbcon_imageblit(). My setup is an old XFX 7600GT card plugged
into an ARM Juno r1 board, which works fine with 4.5 and earlier.
Attached are a couple of logs from booting arm64 defconfig plus DRM and
Nouveau enabled - the second also has framebuffer console rotation
turned on, which interestingly seems to move the point of failure, and
the display does eventually come up to show the tail end of the
panic in
that case.
I might be able to find time for a full bisection next week if isn't
something sufficiently obvious to anyone who knows this driver.
Looking at the log it is not clear to me what could be causing this. I
can boot 4.6-rc2 with a GM206 card without any issue. A bisect would
indeed be useful here.
OK, turns out the lure of writing something to remotely drive a Juno and
parse kernel bootlogs through an automatic bisection was too great to
resist on a Friday afternoon :D
Bisection came down to 1733a2ad3674("drm/nouveau/device/pci: set as
non-CPU-coherent on ARM64"), and sure enough reverting that removes the
crash.
Thanks for taking the time to bisect this. And apologies as it seems my
commit is the reason for your troubles.
The CPU coherency flag is used for two things: explicitly sync buffers
pages when required, and allocating buffers that are not explicitly
synced (like fences or pushbuffers) using the DMA API. For this latter
use, it also accesses the buffer's content using the mapping provided by
dma_alloc_coherent() instead of creating a new one. All nouveau_bos are
supposed to be written using nouveau_bo_rd32(), and this function
handles the case of an DMA-API allocated object by detecting that the
result of ttm_kmap_obj_virtual() is NULL.
But as it turns out, OUT_RINGp() also calls ttm_kmap_obj_virtual() in
order to perform a memcpy and uses its result directly - which means we
are doing memcpy on a NULL pointer. We never caught this because we
typically do not use Nouveau's fbcon with an ARM setup.
I don't really like this special access for coherent objects, and
actually had a patch in my tree to attempt to remove it (attached).
Although it is not the whole solution (see below), the issue should at
least not be visible with it applied - could you confirm?
Hi Robin, could you confirm whether the attached patch in my previous
mail helps with your problem?
Thanks!
Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.
On Wed, Apr 20, 2016 at 6:04 AM, Eric W. Biederman wrote: > > The /dev/ptmx device node is changed to lookup the directory entry > "pts" in the same directory as the /dev/ptmx device node was opened > in. If there is a "pts" entry and that entry is a devpts filesystem > /dev/ptmx uses that filesystem. Otherwise the open of /dev/ptmx > fails. > > The DEVPTS_MULTIPLE_INSTANCES configuration option is removed, > so that userspace can now safely depend on each mount of devpts > creating a new instance of the filesystem. > > Each mount of devpts is now a separate and equal filesystem. > > The kernel.pty.reserve sysctl is neutered with no way currently > implemented to be able to use the reserved ptys. I think we could convert this into reserve for init user namespace, ssh in host will work even if containers eaten all ptys. > > A new vfs helper path_pts is introduced that finds a directory entry > named "pts" in the directory of the passed in path, and changes the > passed in path to point to it. The helper path_pts uses a function > path_parent_directory that was factored out of follow_dotdot. > > In the implementation of devpts: > - devpts_mnt is killed as it is no longer meaningful if all > mounts of devpts are equal. > - pts_sb_from_inode is replaced by just inode->i_sb as all > cached inodes in the tty layer are now from the devpts > filesystem. > - devpts_add_ref is rolled into the new function devpts_ptmx. > And the unnecessary inode hold is removed. > - devpts_del_ref is renamed devpts_release and reduced > to just a deacrivate_super. > - The newinstance mount option continues to be accepted but is now ignored. > > In devpts_fs.h definitions for when !CONFIG_UNIX98_PTYS are removed > as they are never used. > > Documentation/filesystems/devices.txt is updated to describe > the current situation. > > This has been verified to work properly on openwrt-15.05, centos5, > centos6, centos7, debian-6.0.2, debian-7.9, debian-8.2, > ubuntu-14.04.3, ubuntu-15.10, fedora23, magia-5, mint-17.3, > opensuse-42.1, slackware-14.1, gentoo-20151225 (13.0?), > archlinux-2015-12-01. With the caveat that on centos6 and on > slackware-14.1 that there wind up being two instances of the devpts > filesystem mounted on /dev/pts, the lower copy does not end up getting > used. > > Signed-off-by: "Eric W. Biederman" > --- > Documentation/filesystems/devpts.txt | 145 +++-- > drivers/tty/Kconfig | 11 -- > drivers/tty/pty.c| 41 --- > fs/devpts/inode.c| 205 > +-- > fs/namei.c | 58 -- > include/linux/devpts_fs.h| 31 ++ > include/linux/namei.h| 2 + > 7 files changed, 148 insertions(+), 345 deletions(-)
Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'
On 04/19/2016 08:37 PM, 陈华才 wrote: Hi, Could you please remove the line "#define cpu_hwrena_impl_bits0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h and try again?Thanks. That fixes the problem. Does this need to be addressed in qemu or in the Linux kernel ? Thanks, Guenter Huacai -- Original -- From: "Guenter Roeck"; Date: Wed, Apr 20, 2016 10:54 AM To: "Huacai Chen"; Cc: "Ralf Baechle"; "linux-mips"; "linux-next"; "linux-kernel"; Subject: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support' Hi, qemu fails to boot in -next for machine fulong2e with configuration fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add Loongson-3A R2 basic support'. qemu hangs in boot, after displaying "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)". Bisect log is attached. Guenter --- # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific files for 20160418 # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3 git bisect start 'HEAD' 'v4.6-rc3' # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking branch 'ipvs-next/master' git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking branch 'btrfs-kdave/for-next' git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792 # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking branch 'omap/for-next' git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking branch 'microblaze/next' git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506 # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: Introduce CONFIG_LOONGSON3_ENHANCEMENT git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be used on non-R2 or R6 cores git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8 # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add Loongson1 architecture entry git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to use strict posix types git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw watchpoints on MIPS R6 git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: Adjust irq dispatch to speedup processing git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set cache flush handlers to cache_noop git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9 # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add Loongson-3A R2 basic support git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0 # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add Loongson-3A R2 basic support
Re: [PATCH] devpts: Make each mount of devpts an independent filesystem.
On Tue, Apr 19, 2016 at 9:36 PM, Konstantin Khlebnikov wrote: > On Wed, Apr 20, 2016 at 6:04 AM, Eric W. Biederman >> >> The kernel.pty.reserve sysctl is neutered with no way currently >> implemented to be able to use the reserved ptys. > > I think we could convert this into reserve for init user namespace, > ssh in host will work even if containers eaten all ptys. Yes. That's basically how it effectively worked before (ie everything but the initial non-newinstance devpts mount would be limited to the non-reserved numbers). We required the non-init namespaces to do a newinstance mount, so the whole test for "newinstance" was effectively the same thing as just checking for the init namespace from a security standpoint. And in fact, rewriting it in that form (ie checking for init_ns) would just make it much more obvious what the intent it. Linus
Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test
[ ... ] > About the error handling... you advised against panic() > because there might be other clock sources. > > Does it makes sense to give up registering sched_clock > and delay_timer when the clocksource registration fails? Actually, all the problem is coming from the CLOCKSOURCE_OF_DECLARE where the init_func is a void (*init_func)(struct device_node *) signature, thus not allowing to return a value. Because of that, the init code path of the different drivers are somewhat fuzzy when an error occurs. If the function could return an error code, then the drivers would be written in a way to catch and handle the errors gracefully. That implies the clocksource-probe() routine will be able to detect when the init_func() is failing, trace it and count if one clocksource/clockevent succeed at boot time. So because the latter, it would make sense to give up registering and leave a clean place in the init function when something is going wrong. -- Daniel
Re: [PATCH V11 0/4]perf/powerpc: Add ability to sample intr machine state in powerpc
On Wed, 2016-04-20 at 00:57 -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Apr 18, 2016 at 03:17:11PM +0530, Anju T escreveu: > > On Saturday 20 February 2016 10:32 AM, Anju T wrote: > > > > > > arch/powerpc/Kconfig| 1 + > > > arch/powerpc/include/uapi/asm/perf_regs.h | 50 > > > arch/powerpc/perf/Makefile | 1 + > > > arch/powerpc/perf/perf_regs.c | 91 > > > + > > > tools/perf/arch/powerpc/include/perf_regs.h | 69 ++ > > > tools/perf/arch/powerpc/util/Build | 1 + > > > tools/perf/arch/powerpc/util/perf_regs.c| 49 > > > tools/perf/config/Makefile | 5 ++ > > > 8 files changed, 267 insertions(+) > > > create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h > > > create mode 100644 arch/powerpc/perf/perf_regs.c > > > create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h > > > create mode 100644 tools/perf/arch/powerpc/util/perf_regs.c > > > > > > > Hi, > > > > Can this be taken into the next tree? > > Even the bits in tools/perf/ are arch specific, so I guess this goes via > the powerpc tree? Michael? Yeah if that's OK with you. It doesn't look like it will generate much in the way of merge conflicts. Do you want to send an ack? cheers
Re: [PATCH 0/4] ARM: cpuidle: use const and __initconst for cpuidle_ops
On Tue, Apr 19, 2016 at 06:31:14PM +0100, Lorenzo Pieralisi wrote: > Hi Daniel, > > On Fri, Mar 25, 2016 at 12:26:27PM +0100, Daniel Lezcano wrote: > > On 03/22/2016 03:42 PM, Jisheng Zhang wrote: > > >These trivial patches are similar as Masahiro posted in[1]. The main > > >purpose is let cpuidle_ops structure be constified and replace > > >"__initdata" with "__initconst". > > > > > >[1] > > >http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/365826.html > > > > > >Jisheng Zhang (4): > > > ARM: cpuidle: add const qualifier to cpuidle_ops member in structures > > > ARM: cpuidle: constify return value of arm_cpuidle_get_ops() > > > soc: qcom: spm: use const and __initconst for qcom_cpuidle_ops > > > drivers: firmware: psci: use const and __initconst for > > > psci_cpuidle_ops > > > > > > arch/arm/include/asm/cpuidle.h | 2 +- > > > arch/arm/kernel/cpuidle.c | 6 +++--- > > > drivers/firmware/psci.c| 2 +- > > > drivers/soc/qcom/spm.c | 2 +- > > > 4 files changed, 6 insertions(+), 6 deletions(-) > > > > Sounds reasonable. > > Are you taking them ? I could send the last one but it would > make more sense for them to be part of the same series, I will > check they do not conflict with patches queued for PSCI. Ok, let me know via an acked-by. Thanks. -- Daniel
Re: [tip:sched/core] perf/core, sched: Don't use clock function pointer to determine clock
On Tue, Apr 19, 2016 at 02:34:50AM -0700, tip-bot for Alexander Shishkin wrote: > Commit-ID: f454bfddf6ba557381d8bf5df50eff778602ff23 > Gitweb: http://git.kernel.org/tip/f454bfddf6ba557381d8bf5df50eff778602ff23 > Author: Alexander Shishkin > AuthorDate: Thu, 14 Apr 2016 14:59:49 +0300 > Committer: Ingo Molnar > CommitDate: Tue, 19 Apr 2016 10:55:29 +0200 > > perf/core, sched: Don't use clock function pointer to determine clock > > Now that local_clock() is explicitly inlined in sched.h, taking its > pointer would uninline it in the compilation unit where it's done, > making (among other things) comparing pointers to this function > produce different results in different compilation units. > > Case in point, x86 perf core's user page updating function compares > event's clock against &local_clock to see if it needs to set zero > time offset related bits in the page. > > This patch fixes the latter by looking at the "use_clockid" event > attribute instead, to determine whether local clock is used. Fixing > the uninlined local_clock() in perf core is left as an exercise for > the author of the prior work. Ouch! Good exercise :)
Re: [PATCH v2] fs: add file_dentry()
Hey Miklos,
On 03/23/2016 09:36 AM, Miklos Szeredi wrote:
> This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
> Make f_path always point to the overlay and f_inode to the underlay").
Since that commit got backported into older -stable kernel, it would
appear that this file_dentry() series is relevant for pre-4.2 kernels as
well.
However, backporting it seems to be less than trivial.
Could you provide a backport for older -stable kernels please?
Thanks,
Sasha
RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
Hi,
> From: Peter Chen
> Sent: Tuesday, April 19, 2016 6:18 PM
>
> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > Hi,
> >
> > > From: Yoshihiro Shimoda
> > > Sent: Friday, April 15, 2016 6:59 PM
> > >
> > > Hi,
> > >
> > > > From: Roger Quadros
> > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > >
> > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > Hi,
> > > > >
> > > < snip >
> > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> > > > >>> unsigned int irqnum,
> > > > >>> * we're ready only if we have shared HCD
> > > > >>> * or we don't need shared HCD.
> > > > >>> */
> > > > >>> - if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > >>> + if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > >>> + !otg->primary_hcd.hcd->shared_hcd))
> > > > >>> {
> > > > >>> otg->host = hcd_to_bus(hcd);
> > > > >>> /* FIXME: set bus->otg_port if this is true OTG port
> > > > >>> with HNP */
> > > > >>>
> > > > >>
> > > > >> These changes look good to me. Thanks.
> > > > >
> > > > > Thank you for the comment.
> > > > > If we change the "needs_companion" place to the otg_config,
> > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > >
> > > > Yes we can add a flag in struct usb_otg.
> > >
> > > Thank you for the comment.
> > >
> > > I made a fixed patch.
> > > So, should I send this patch to ML after you sent v7 patches?
> > > Or, would you apply this patch before you send v7 patches?
> >
> > Oops, I sent this email without my patch...
> >
> > ---
> > Subject: [PATCH] usb: otg: add hcd companion support
> >
> > Since some host controller (e.g. EHCI) needs a companion host controller
> > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > core.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > Documentation/devicetree/bindings/usb/generic.txt | 3 +++
> > drivers/usb/common/usb-otg.c | 17 +
> > include/linux/usb/otg.h | 7 ++-
> > 3 files changed, 22 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt
> > b/Documentation/devicetree/bindings/usb/generic.txt
> > index f6866c1..1db1c33 100644
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > @@ -27,6 +27,9 @@ Optional properties:
> > - otg-controller: phandle to otg controller. Host or gadget controllers
> > can
> > contain this property to link it to a particular OTG
> > controller.
> > + - hcd-needs-companion: must be present if otg controller is dealing with
> > + EHCI host controller that needs a companion OHCI host
> > + controller.
> >
> > This is an attribute to a USB controller such as:
> >
> > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > index 41e762a..83c8c96 100644
> > --- a/drivers/usb/common/usb-otg.c
> > +++ b/drivers/usb/common/usb-otg.c
> > @@ -20,6 +20,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > else
> > INIT_WORK(&otg->work, usb_otg_work);
> >
> > + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > + config->hcd_needs_companion)/* needs comanion ? */
>
> %s/comanion/companion
Thank you for pointing it out!
Roger, would you fix this in your v7 patch set?
> I have a little puzzled with companion controller and shared hcd, let me
> post a topic for it.
I looked at the email thread.
It is very useful information to me! :)
Best regards,
Yoshihiro Shimoda
> Peter
>
> > + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > +
> > otg->wq = create_singlethread_workqueue("usb_otg");
> > if (!otg->wq) {
> > dev_err(dev, "otg: %s: can't create workqueue\n",
> > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd,
> > unsigned int irqnum,
> > /* HCD will be started by OTG fsm when needed */
> > mutex_lock(&otg->fsm.lock);
> > if (otg->primary_hcd.hcd) {
> > - /* probably a shared HCD ? */
> > - if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > + /* probably a shared HCD or a companion OHCI HCD ? */
> > + if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > + usb_otg_hcd_is_primary_hcd(hcd)) {
> > dev_err(otg_dev, "otg: primary host already
> > registered\n");
> > goto err;
> > }
> >
> > - if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > + if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > + (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> >
Re: [PATCH] rtc: pcf8563: Remove CLK_IS_ROOT
Hello Stephen, Am 20.04.2016 um 03:12 schrieb Stephen Boyd: This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate CLK_IS_ROOT", 2016-02-02) so remove it. Cc: Heiko Schocher Signed-off-by: Stephen Boyd --- drivers/rtc/rtc-pcf8563.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Acked-by: Heiko Schocher bye, Heiko diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c index d5e6ed96b748..b9ddbb001283 100644 --- a/drivers/rtc/rtc-pcf8563.c +++ b/drivers/rtc/rtc-pcf8563.c @@ -533,7 +533,7 @@ static struct clk *pcf8563_clkout_register_clk(struct pcf8563 *pcf8563) init.name = "pcf8563-clkout"; init.ops = &pcf8563_clkout_ops; - init.flags = CLK_IS_ROOT; + init.flags = 0; init.parent_names = NULL; init.num_parents = 0; pcf8563->clkout_hw.init = &init; -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
linux-next: Tree for Apr 20
Hi all, Changes since 20160419: The tip tree lost its build failures. The usb-gadget tree gained a conflict against the usb-gadget-fixes tree. The akpm-current tree still had its build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 4655 4294 files changed, 171419 insertions(+), 95741 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 232 trees (counting Linus' and 35 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (12566cc35d0e Merge tag 'pci-v4.6-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging fixes/master (9735a22799b9 Linux 4.6-rc2) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (421e31e58c2a ARCv2: Enable LOCKDEP) Merging arm-current/fixes (9c18fcf7ae0e ARM: 8551/2: DMA: Fix kzalloc flags in __dma_alloc) Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs for v4.6-rc2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging powerpc-fixes/fixes (4705e02498d6 powerpc: Update TM user feature bits in scan_features()) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.) Merging net/master (ab2ed0171a50 macsec: fix crypto Kconfig dependency) Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.) Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup with identical name) Merging wireless-drivers/master (de478a61389c ath9k: ar5008_hw_cmn_spur_mitigate: add missing mask_m & mask_p initialisation) Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket release notification) Merging sound-current/for-linus (afecb146d8d8 ALSA: hda/realtek - Add ALC3234 headset mode for Optiplex 9020m) Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read both VPD structures) Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4) Merging tty.current/tty-linus (f077b7368291 Revert "serial: 8250: Add hardware dependency to RT288X option") Merging usb.current/usb-linus (c3b46c73264b Linux 4.6-rc4) Merging usb-gadget-fixes/fixes (5505d5254aeb usb: gadget: f_fs: Fix use-after-free) Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3) Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: change workqueue ci_otg as freezable) Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3) Merging char-misc.current/char-misc-linus (c3b46c73264b Linux 4.6-rc4) Merging input-current/for-linus (eda5ecc0a6b8 Input: pmic8xxx-pwrkey - fix algorithm for converting trigger delay) Merging crypto-current/master (f709b45ec461 crypto: ccp - Prevent information leakage on export) Merging ide/master (1993b176a822 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms vs module insertion race.) Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling) Merging kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix
[PATCH powerpc/next] powerpc: spinlock: Fix spin_unlock_wait()
There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:
CPU 1 CPU 2 CPU 3
== ==
spin_unlock(&lock);
spin_lock(&lock):
r1 = *lock; // r1 == 0;
o = object; o = READ_ONCE(object); // reordered here
object = NULL;
smp_mb();
spin_unlock_wait(&lock);
*lock = 1;
smp_mb();
o->dead = true; < o = READ_ONCE(object); > // reordered upwards
if (o) // true
BUG_ON(o->dead); // true!!
To fix this, we add a "nop" ll/sc loop in arch_spin_unlock_wait() on
ppc (arch_spin_is_locked_sync()), the "nop" ll/sc loop reads the lock
value and writes it back atomically, in this way it will synchronize the
view of the lock on CPU1 with that on CPU2. Therefore in the scenario
above, either CPU2 will fail to get the lock at first or CPU1 will see
the lock acquired by CPU2, both cases will eliminate this bug. This is a
similar idea as what Will Deacon did for ARM64 in:
"arm64: spinlock: serialise spin_unlock_wait against concurrent lockers"
Further more, if arch_spin_is_locked_sync() figures out the lock is
locked, we actually don't need to do the "nop" ll/sc trick again, we can
just do a normal load+check loop for the lock to be released, because in
that case, spin_unlock_wait() is called when someone is holding the
lock, and the store part of arch_spin_is_locked_sync() happens before
the unlocking of the current lock holder, which means
arch_spin_is_locked_sync() happens before the next lock acquisition.
With the smp_mb() perceding spin_unlock_wait(), the store of object is
guaranteed to be observed by the next lock holder.
Please note spin_unlock_wait() on powerpc is still not an ACQUIRE after
this fix, the callers should add necessary barriers if they want to
promote it as all the current callers do.
This patch therefore fixes the issue and also cleans the
arch_spin_unlock_wait() a little bit by removing superfluous memory
barriers in loops and consolidating the implementations for PPC32 and
PPC64 into one.
Suggested-by: "Paul E. McKenney"
Signed-off-by: Boqun Feng
Reviewed-by: "Paul E. McKenney"
---
arch/powerpc/include/asm/spinlock.h | 48 -
arch/powerpc/lib/locks.c| 16 -
2 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/spinlock.h
b/arch/powerpc/include/asm/spinlock.h
index 523673d7583c..0a517c1a751e 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -64,6 +64,25 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
}
/*
+ * Use a ll/sc loop to read the lock value, the STORE part of this operation is
+ * used for making later lock operation observe it.
+ */
+static inline bool arch_spin_is_locked_sync(arch_spinlock_t *lock)
+{
+ arch_spinlock_t tmp;
+
+ __asm__ __volatile__(
+"1:" PPC_LWARX(%0, 0, %2, 1) "\n"
+" stwcx. %0, 0, %2\n"
+" bne- 1b\n"
+ : "=&r" (tmp), "+m" (*lock)
+ : "r" (lock)
+ : "cr0", "xer");
+
+ return !arch_spin_value_unlocked(tmp);
+}
+
+/*
* This returns the old value in the lock, so we succeeded
* in getting the lock if the return value is 0.
*/
@@ -162,12 +181,29 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
lock->slock = 0;
}
-#ifdef CONFIG_PPC64
-extern void arch_spin_unlock_wait(arch_spinlock_t *lock);
-#else
-#define arch_spin_unlock_wait(lock) \
- do { while (arch_spin_is_locked(lock)) cpu_relax(); } while (0)
-#endif
+static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
+{
+ /*
+* Make sure previous loads and stores are observed by other cpu, this
+* pairs with the ACQUIRE barrier in lock.
+*/
+ smp_mb();
+
+ if (!arch_spin_is_locked_sync(lock))
+ return;
+
+ while (!arch_spin_value_unlocked(*lock)) {
+ HMT_low();
+ if (SHARED_PROCESSOR)
+ __spin_yield(lock);
+ }
+ HMT_medium();
+
+ /*
+* No barrier here, caller either relys on the control dependency or
+* should add a necessary barrier afterwards.
+*/
+}
/*
* Read-write spinlocks, allowing multiple readers
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index f7deebdf3365..b7b1237d4aa6 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -68,19 +68,3 @@ void __rw_yield(arch_rwlock_t *rw)
get_hard_smp_processor_id(holder_cpu), yield_count);
}
#endif
-
-void arch_spin_unlock_wait(arch_spinlock_
[PATCH powerpc/next RESEND] powerpc: spinlock: Fix spin_unlock_wait()
There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:
CPU 1 CPU 2 CPU 3
== ==
spin_unlock(&lock);
spin_lock(&lock):
r1 = *lock; // r1 == 0;
o = object; o = READ_ONCE(object); // reordered here
object = NULL;
smp_mb();
spin_unlock_wait(&lock);
*lock = 1;
smp_mb();
o->dead = true; < o = READ_ONCE(object); > // reordered upwards
if (o) // true
BUG_ON(o->dead); // true!!
To fix this, we add a "nop" ll/sc loop in arch_spin_unlock_wait() on
ppc (arch_spin_is_locked_sync()), the "nop" ll/sc loop reads the lock
value and writes it back atomically, in this way it will synchronize the
view of the lock on CPU1 with that on CPU2. Therefore in the scenario
above, either CPU2 will fail to get the lock at first or CPU1 will see
the lock acquired by CPU2, both cases will eliminate this bug. This is a
similar idea as what Will Deacon did for ARM64 in:
"arm64: spinlock: serialise spin_unlock_wait against concurrent lockers"
Further more, if arch_spin_is_locked_sync() figures out the lock is
locked, we actually don't need to do the "nop" ll/sc trick again, we can
just do a normal load+check loop for the lock to be released, because in
that case, spin_unlock_wait() is called when someone is holding the
lock, and the store part of arch_spin_is_locked_sync() happens before
the unlocking of the current lock holder, which means
arch_spin_is_locked_sync() happens before the next lock acquisition.
With the smp_mb() perceding spin_unlock_wait(), the store of object is
guaranteed to be observed by the next lock holder.
Please note spin_unlock_wait() on powerpc is still not an ACQUIRE after
this fix, the callers should add necessary barriers if they want to
promote it as all the current callers do.
This patch therefore fixes the issue and also cleans the
arch_spin_unlock_wait() a little bit by removing superfluous memory
barriers in loops and consolidating the implementations for PPC32 and
PPC64 into one.
Suggested-by: "Paul E. McKenney"
Signed-off-by: Boqun Feng
Reviewed-by: "Paul E. McKenney"
---
arch/powerpc/include/asm/spinlock.h | 48 -
arch/powerpc/lib/locks.c| 16 -
2 files changed, 42 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/spinlock.h
b/arch/powerpc/include/asm/spinlock.h
index 523673d7583c..0a517c1a751e 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -64,6 +64,25 @@ static inline int arch_spin_is_locked(arch_spinlock_t *lock)
}
/*
+ * Use a ll/sc loop to read the lock value, the STORE part of this operation is
+ * used for making later lock operation observe it.
+ */
+static inline bool arch_spin_is_locked_sync(arch_spinlock_t *lock)
+{
+ arch_spinlock_t tmp;
+
+ __asm__ __volatile__(
+"1:" PPC_LWARX(%0, 0, %2, 1) "\n"
+" stwcx. %0, 0, %2\n"
+" bne- 1b\n"
+ : "=&r" (tmp), "+m" (*lock)
+ : "r" (lock)
+ : "cr0", "xer");
+
+ return !arch_spin_value_unlocked(tmp);
+}
+
+/*
* This returns the old value in the lock, so we succeeded
* in getting the lock if the return value is 0.
*/
@@ -162,12 +181,29 @@ static inline void arch_spin_unlock(arch_spinlock_t *lock)
lock->slock = 0;
}
-#ifdef CONFIG_PPC64
-extern void arch_spin_unlock_wait(arch_spinlock_t *lock);
-#else
-#define arch_spin_unlock_wait(lock) \
- do { while (arch_spin_is_locked(lock)) cpu_relax(); } while (0)
-#endif
+static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
+{
+ /*
+* Make sure previous loads and stores are observed by other cpu, this
+* pairs with the ACQUIRE barrier in lock.
+*/
+ smp_mb();
+
+ if (!arch_spin_is_locked_sync(lock))
+ return;
+
+ while (!arch_spin_value_unlocked(*lock)) {
+ HMT_low();
+ if (SHARED_PROCESSOR)
+ __spin_yield(lock);
+ }
+ HMT_medium();
+
+ /*
+* No barrier here, caller either relys on the control dependency or
+* should add a necessary barrier afterwards.
+*/
+}
/*
* Read-write spinlocks, allowing multiple readers
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index f7deebdf3365..b7b1237d4aa6 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -68,19 +68,3 @@ void __rw_yield(arch_rwlock_t *rw)
get_hard_smp_processor_id(holder_cpu), yield_count);
}
#endif
-
-void arch_spin_unlock_wait(arch_spinlock_
Re: [PATCH v11 1/4] tpm: Remove all uses of drvdata from the TPM Core
On Tue, Apr 19, 2016 at 11:06:45AM -0600, Jason Gunthorpe wrote: > On Tue, Apr 19, 2016 at 06:36:22AM -0400, Stefan Berger wrote: > > On 04/19/2016 06:12 AM, Jarkko Sakkinen wrote: > > >On Mon, Apr 18, 2016 at 01:26:13PM -0400, Stefan Berger wrote: > > >>From: Jason Gunthorpe > > >> > > >>The final thing preventing this was the way the sysfs files were > > >>attached to the pdev. Follow the approach developed for ppi and move > > >>the sysfs files to the chip->dev with symlinks from the pdev > > >>for compatibility. Everything in the core now sanely uses container_of > > >>to get the chip. > > >Can you give me a quick recap why this patch was mandatory to make the > > >patch set work? Which regression in the earlier versions of the patch > > >set this fixes? > > > > The below patch removes usage of dev_get_drvdata() for retrieving the chip. > > With Christophe's series dropping the priv field I now can use the drvdata > > to store proxy_dev rather than re-introducing the priv field in the chip > > structure. Besides that it doesn't seem necessary to use the drvdata field > > to get from the chip to the device if a simple container_of can do it. > > More specifically, since the vtpm patches use a NULL parent, the > approach of putting the sysfs files on the parent is no longer > workable. > > The early vtpm patches simply moved the sysfs files to the tpm_chip > when a parent is NULL, which is inconsistent for userspace. This also > created a problem where drvdata on the chip now had to point back to > the chip, meaning it became unusable for its new intended purpose. > > The fix is to make everything uniform and put the sysfs files in the > correct place for all drivers (under the chip) and use symlinks for > compat. OK, thanks for explaining this, make perfect sense now. I'll do a more detailed review (and testing) later on. > Jason /Jarkko
Re: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: AddLoongson-3A R2 basic support'
This is a kernel bug, I'll send a patch. Huacai On Wed, Apr 20, 2016 at 12:43 PM, Guenter Roeck wrote: > On 04/19/2016 08:37 PM, 陈华才 wrote: >> >> Hi, >> >> Could you please remove the line "#define cpu_hwrena_impl_bits >> 0xc000" in arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h >> and try again?Thanks. >> > > That fixes the problem. > > Does this need to be addressed in qemu or in the Linux kernel ? > > Thanks, > Guenter > > >> Huacai >> >> -- Original -- >> From: "Guenter Roeck"; >> Date: Wed, Apr 20, 2016 10:54 AM >> To: "Huacai Chen"; >> Cc: "Ralf Baechle"; >> "linux-mips"; >> "linux-next"; >> "linux-kernel"; >> Subject: next: fuloong2e qemu boot failure due to 'MIPS: Loongson: >> AddLoongson-3A R2 basic support' >> >> Hi, >> >> qemu fails to boot in -next for machine fulong2e with configuration >> fuloong2e_defconfig. Bisect points to commit 'MIPS: Loongson: Add >> Loongson-3A R2 basic support'. qemu hangs in boot, after displaying >> "Inode-cache hash table entries: 16384 (order: 3, 131072 bytes)". >> >> Bisect log is attached. >> >> Guenter >> >> --- >> # bad: [1bd7a2081d2c7b096f75aa934658e404ccaba5fd] Add linux-next specific >> files for 20160418 >> # good: [bf16200689118d19de1b8d2a3c314fc21f5dc7bb] Linux 4.6-rc3 >> git bisect start 'HEAD' 'v4.6-rc3' >> # bad: [493ac92ff65ec4c4cd4c43870e778760a012951d] Merge remote-tracking >> branch 'ipvs-next/master' >> git bisect bad 493ac92ff65ec4c4cd4c43870e778760a012951d >> # bad: [20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792] Merge remote-tracking >> branch 'btrfs-kdave/for-next' >> git bisect bad 20ca3ae9c517eee9b2f1bd0fb2a06e2d14153792 >> # good: [c454e65fb9ade11d0f84718d06a6888e2c92804d] Merge remote-tracking >> branch 'omap/for-next' >> git bisect good c454e65fb9ade11d0f84718d06a6888e2c92804d >> # good: [6f5c70fb9b4fc0534157bfa40cea9b402e6f2506] Merge remote-tracking >> branch 'microblaze/next' >> git bisect good 6f5c70fb9b4fc0534157bfa40cea9b402e6f2506 >> # bad: [7f053cd68fd14243c8f202b4086d7dd75c409e6f] MIPS: Loongson-3: >> Introduce CONFIG_LOONGSON3_ENHANCEMENT >> git bisect bad 7f053cd68fd14243c8f202b4086d7dd75c409e6f >> # good: [e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8] MIPS: Allow RIXI to be >> used on non-R2 or R6 cores >> git bisect good e9aacdd7f0b66c4ace17e5950c48e7cc61a253c8 >> # good: [d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d] MAINTAINERS: add >> Loongson1 architecture entry >> git bisect good d1e8b9a8dc6c7fa9add5dfa7083e035ce037e56d >> # good: [13ff6275bb389c3669082d3ef8483592a31eb0ea] MIPS: Fix siginfo.h to >> use strict posix types >> git bisect good 13ff6275bb389c3669082d3ef8483592a31eb0ea >> # good: [66e74bdd51e617023fa2e79a807b704fb3eed8aa] MIPS: Enable ptrace hw >> watchpoints on MIPS R6 >> git bisect good 66e74bdd51e617023fa2e79a807b704fb3eed8aa >> # good: [f7cabc2dac8adf5986dbc700584bc3b8fe493d4d] MIPS: Loongson-3: >> Adjust irq dispatch to speedup processing >> git bisect good f7cabc2dac8adf5986dbc700584bc3b8fe493d4d >> # bad: [4978c8477e96fb9e9d870d8f42328dcabf1a65e9] MIPS: Loongson-3: Set >> cache flush handlers to cache_noop >> git bisect bad 4978c8477e96fb9e9d870d8f42328dcabf1a65e9 >> # bad: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: Loongson: Add >> Loongson-3A R2 basic support >> git bisect bad 04a35922c1dac1b4864b8b366a37474e9e51d8c0 >> # first bad commit: [04a35922c1dac1b4864b8b366a37474e9e51d8c0] MIPS: >> Loongson: Add Loongson-3A R2 basic support >> > >
mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'
Hi, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 12566cc35d0e68308bde7aad615743d560cb097b commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch policy to be changed date: 6 months ago config: mips-malta_qemu_32r6_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986 # save the attached .config to linux build tree make.cross ARCH=mips All errors (new ones prefixed by >>): >> mipsel-linux-gnu-gcc: error: unrecognized command line option >> '-mcompact-branches=optimal' >> mipsel-linux-gnu-gcc: error: unrecognized command line option >> '-mcompact-branches=optimal' make[2]: *** [kernel/bounds.s] Error 1 make[2]: Target '__build' not remade because of errors. make[1]: *** [prepare0] Error 2 make[1]: Target 'prepare' not remade because of errors. make: *** [sub-make] Error 2 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: Umount failing due to a file leak on 3.18 Android
On Tue, Apr 19, 2016 at 06:26:27PM -0700, Nikhilesh Reddy wrote: > Hi > > I am looking into a bug that results in umount failures ( since there is a > mount ref from the leaked file that is never freed on the mount ) > > The issue seems to be a result of the following callstack > > 39.958104: <6> Call trace: > 39.958108: <2> [] fput+0x1e0/0x1f8 > 39.958113: <2> [] filp_close+0xa0/0xb8 > 39.958119: <2> [] put_files_struct+0x88/0xf0 > 39.958123: <2> [] binder_deferred_func+0x6a8/0x704 > 39.958129: <2> [] process_one_work+0x238/0x3f0 > 39.958133: <2> [] worker_thread+0x2f8/0x418 > > What seems to occur is that once in a while a file ( say a.txt) is fput in > the above stack > right as the task is being killed > > And then we see that the fput schedules a delayed_fput_work on this file > > But when the function delayed_fput() is actually run : > the file that was put i.e this a.txt is not in the delayed_fput_list > > Any chance you can help me get to the bottom of this leak? > I dont understand why the delayed_fput_list is missing the file. 3.18 is very old, can you duplicate this on 4.5 or newer? thanks, greg k-h
Re: [PATCH v2] tty: msm_serial: remove static clk rate setting in probe
On 2016-03-07 08:16, Srinivas Kandagatla wrote: The issue with setting up a fixed clock rate at probe is that it would overwrite the console rate set by the bootloader for its console device. This would result in serial out corruption or missing log when we system is booted with earlycon. This is not a issue if we boot system without earlycon. This setup is at least not required with the mainline driver, this code used to be required because the clk_enable() call would fail if clk_set_rate() wasn't called first. Originally the issue was noticed on DB410c which is based on APQ8016 chipset. Without this patch the console log with earlycon would look like: ... [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1 [0.00] NR_IRQS:64 nr_irqs:64 0 +HH��0.699378] console [ttyMSM0] enabled [0.699378] console [ttyMSM0] enabled [0.702003] bootconsole [uart0] disabled [0.702003] bootconsole [uart0] disabled ... with this patch I can see all the skipped lines on the console Reviewed-by: Stephen Boyd Signed-off-by: Srinivas Kandagatla --- Tested on DB410C. Fixed below curruption with earlycon: [0.815843] msm_iommu_ctx 1e3b000.qcom,iommu-ctx: context periph_SDC2 using bank 27 [1.411080] console [ttyMSM0] enabled [1.411080] console [ttyMSM0] enabled Tested-by: Pramod Gurav Changes since v1: - removed empty line suggested by Greg KH - added reviewed-by - added extra comment suggested by Stephen Boyd. drivers/tty/serial/msm_serial.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c index dcde955..3bf41ab 100644 --- a/drivers/tty/serial/msm_serial.c +++ b/drivers/tty/serial/msm_serial.c @@ -1579,8 +1579,6 @@ static int msm_serial_probe(struct platform_device *pdev) msm_port->pclk = devm_clk_get(&pdev->dev, "iface"); if (IS_ERR(msm_port->pclk)) return PTR_ERR(msm_port->pclk); - - clk_set_rate(msm_port->clk, 1843200); } port->uartclk = clk_get_rate(msm_port->clk);
Re: regression: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support") drops data
> On Apr 20, 2016, at 02:23, Frank Rowand wrote:
>
> Hi Ivan,
>
> It appears that I have found a regression caused by
> 3a878c430fd6 ("tty: serial: msm: Add TX DMA support").
>
> When I cat a file slightly larger than 126000 bytes on
> the console, viewed via minicom connected to the serial
> port, I am losing random chunks of data, almost always
> three bytes in length. I have also seen a lost chunk
> of two bytes.
>
> I am using the 8074 dragonboard, with the dts of
> arch/arm/boot/dts/qcom-apq8074-dragonboard.dts.
> The dts node is serial@f991e000, which has a
> compatible of "qcom,msm-uartdm-v1.4", so is_uartdm
> should be UARTDM_1P4.
I don’t remember what was biggest chunk, which DMA
could carry, sorry. Are you using DMA or just PIO?
Is this happening only with cat and terminal or even
when you send data in other means. I believe that
people from Linaro could help you better.
Regards,
Ivan
Re: [PATCH v2 0/7] mmc: sdhci-pltfm: fix and tidy up sdhci_pltfm_init()
On 20/04/16 05:16, Masahiro Yamada wrote: > > > Changes in v2: > - Remove resource size checking rather than fix it. > - Add \n to the tail of the error message > > Masahiro Yamada (7): > mmc: sdhci-pltfm: drop error message for too small MMIO resource size > mmc: sdhci-pltfm: check return value of platform_get_irq() > mmc: sdhci-pltfm: use devm_request_mem_region() > mmc: sdhci-pltfm: use devm_ioremap() > mmc: sdhci-pltfm: use devm_ioremap_resource() > mmc: sdhci-pltfm: move devm_ioremap_resource() up > mmc: sdhci-pltfm: call platform_get_irq() before sdhci_alloc_host() > > drivers/mmc/host/sdhci-pltfm.c | 42 > +- > 1 file changed, 13 insertions(+), 29 deletions(-) > Thank you! For all 7 patches: Acked-by: Adrian Hunter
Re: [PATCH v2 1/2] mmc: sdhci: use IS_REACHABLE(CONFIG_LEDS_CLASS) to enable LED code
On 14/04/16 07:19, Masahiro Yamada wrote:
> defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \
> defined(CONFIG_MMC_SDHCI_MODULE))
>
> is equivalent to:
>
> defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \
> defined(MODULE))
>
> and it can also be written shortly as:
>
> IS_REACHABLE(CONFIG_LEDS_CLASS)
>
> Signed-off-by: Masahiro Yamada
Acked-by: Adrian Hunter
> ---
>
> Changes in v2:
> - Rebase on the next branch (7766e58f5be39dcc35d30a703422a3d0b8ec8c0c)
>
> drivers/mmc/host/sdhci.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index b284924..eedc18a 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -259,9 +259,7 @@ static void __sdhci_led_deactivate(struct sdhci_host
> *host)
> sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> }
>
> -#if defined(CONFIG_LEDS_CLASS) || (defined(CONFIG_LEDS_CLASS_MODULE) && \
> -defined(CONFIG_MMC_SDHCI_MODULE))
> -
> +#if IS_REACHABLE(CONFIG_LEDS_CLASS)
> static void sdhci_led_control(struct led_classdev *led,
> enum led_brightness brightness)
> {
>
[PATCH v2 4/5] drm/rockchip: vop: add rk3399 vop support
There are two VOP in rk3399 chip, respectively VOP_BIG and VOP_LIT.
most registers layout of this two vop is same, their framework are both
VOP_FULL, the Major differences of this two is that:
VOP_BIG max output resolution is 4096x2160.
VOP_LIT max output resolution is 2560x1600
VOP_BIG support four windows.
VOP_LIT only support two windows.
RK3399 vop register layout is similar with rk3288, so some feature
can reuse with rk3288.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 15 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h |4 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 91 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 193 +++
4 files changed, 298 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 59f24cd..5c9ff8e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -912,7 +912,7 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
u16 vsync_len = adjusted_mode->vsync_end - adjusted_mode->vsync_start;
u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start;
u16 vact_end = vact_st + vdisplay;
- uint32_t val;
+ uint32_t pin_pol, val;
vop_enable(crtc);
/*
@@ -951,21 +951,26 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
vop_dsp_hold_valid_irq_disable(vop);
}
- val = 0x8;
- val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
- val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
- VOP_CTRL_SET(vop, pin_pol, val);
+ pin_pol = 0x8;
+ pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
+ pin_pol |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
+ VOP_CTRL_SET(vop, pin_pol, pin_pol);
+
switch (s->output_type) {
case DRM_MODE_CONNECTOR_LVDS:
VOP_CTRL_SET(vop, rgb_en, 1);
+ VOP_CTRL_SET(vop, rgb_pin_pol, pin_pol);
break;
case DRM_MODE_CONNECTOR_eDP:
+ VOP_CTRL_SET(vop, edp_pin_pol, pin_pol);
VOP_CTRL_SET(vop, edp_en, 1);
break;
case DRM_MODE_CONNECTOR_HDMIA:
+ VOP_CTRL_SET(vop, hdmi_pin_pol, pin_pol);
VOP_CTRL_SET(vop, hdmi_en, 1);
break;
case DRM_MODE_CONNECTOR_DSI:
+ VOP_CTRL_SET(vop, mipi_pin_pol, pin_pol);
VOP_CTRL_SET(vop, mipi_en, 1);
break;
default:
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 28dafb6..ff4f52e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -49,6 +49,10 @@ struct vop_ctrl {
struct vop_reg dither_down;
struct vop_reg dither_up;
struct vop_reg pin_pol;
+ struct vop_reg rgb_pin_pol;
+ struct vop_reg hdmi_pin_pol;
+ struct vop_reg edp_pin_pol;
+ struct vop_reg mipi_pin_pol;
struct vop_reg htotal_pw;
struct vop_reg hact_st_end;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 6846868..6f42e56 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -278,11 +278,102 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
};
+static const struct vop_ctrl rk3399_ctrl_data = {
+ .standby = VOP_REG(RK3399_SYS_CTRL, 0x1, 22),
+ .gate_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 23),
+ .rgb_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 12),
+ .hdmi_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 13),
+ .edp_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 14),
+ .mipi_en = VOP_REG(RK3399_SYS_CTRL, 0x1, 15),
+ .dither_down = VOP_REG(RK3399_DSP_CTRL1, 0xf, 1),
+ .dither_up = VOP_REG(RK3399_DSP_CTRL1, 0x1, 6),
+ .data_blank = VOP_REG(RK3399_DSP_CTRL0, 0x1, 19),
+ .out_mode = VOP_REG(RK3399_DSP_CTRL0, 0xf, 0),
+ .rgb_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 16),
+ .hdmi_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 20),
+ .edp_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 24),
+ .mipi_pin_pol = VOP_REG(RK3399_DSP_CTRL1, 0xf, 28),
+ .htotal_pw = VOP_REG(RK3399_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+ .hact_st_end = VOP_REG(RK3399_DSP_HACT_ST_END, 0x1fff1fff, 0),
+ .vtotal_pw = VOP_REG(RK3399_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+ .vact_st_end = VOP_REG(RK3399_DSP_VACT_ST_END, 0x1fff1fff, 0),
+ .hpost_st_end = VOP_REG(RK3399_POST_DSP_HACT_INFO, 0x1fff1fff, 0),
+ .vpost_st_end = VOP_REG(RK3399_POST_DSP_VACT_INFO, 0x1fff1fff, 0),
+ .cfg_done = VOP_REG_MASK(RK3399_REG_CFG_DONE, 0x1, 0),
+};
+
+static const int rk3399_vop_intrs[] = {
+ FS_INTR,
[PATCH v2 2/5] dt-bindings: sort Rockchip vop compatible by chip's number
Signed-off-by: Mark Yao --- .../bindings/display/rockchip/rockchip-vop.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt index 5489b59..196121f 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt @@ -6,8 +6,8 @@ buffer to an external LCD interface. Required properties: - compatible: value should be one of the following - "rockchip,rk3288-vop"; "rockchip,rk3036-vop"; + "rockchip,rk3288-vop"; - interrupts: should contain a list of all VOP IP block interrupts in the order: VSYNC, LCD_SYSTEM. The interrupt specifier -- 1.7.9.5
[PATCH v2 0/5] drm/rockchip: add rk3399 display controller support
This series of patches add support for rk3399 display crontroller(vop), there are two VOP in rk3399 chip, respectively VOP_BIG and VOP_LIT. most registers layout of this two vop is same, their framework are both VOP_FULL, the differences of this two is VOP_LIT cut off some features. Those patches tested on rk3399 evb board. Changes in v2: - sort the registers and vop compatible name - spilt VOP_REG_MASK into a single patch - make rk3399 vop documentation more readable(Heiko Stübner) Mark Yao (5): drm/rockchip: sort registers define by chip's number dt-bindings: sort Rockchip vop compatible by chip's number drm/rockchip: vop: introduce VOP_REG_MASK drm/rockchip: vop: add rk3399 vop support dt-bindings: add documentation for Rockchip rk3399 display controllers .../bindings/display/rockchip/rockchip-vop.txt |7 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 60 +++-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h|5 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 236 - drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 279 +--- 5 files changed, 447 insertions(+), 140 deletions(-) -- 1.7.9.5
Re: [PATCH v2 2/2] mmc: sdhci: use IS_ENABLE(CONFIG_LEDS_CLASS) to enable LED struct members
On 14/04/16 07:19, Masahiro Yamada wrote:
> defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
>
> is equivalent to:
>
> IS_ENABLED(CONFIG_LEDS_CLASS)
>
> Signed-off-by: Masahiro Yamada
Acked-by: Adrian Hunter
> ---
>
> Changes in v2:
> - Newly added
>
> drivers/mmc/host/sdhci.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 0decc85..27e8603 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -428,7 +428,7 @@ struct sdhci_host {
> struct mmc_host_ops mmc_host_ops; /* MMC host ops */
> u64 dma_mask; /* custom DMA mask */
>
> -#if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
> +#if IS_ENABLED(CONFIG_LEDS_CLASS)
> struct led_classdev led;/* LED control */
> char led_name[32];
> #endif
>
[PATCH v2 3/5] drm/rockchip: vop: introduce VOP_REG_MASK
Some new vop register support mask, bit[16-31] is mask,
bit[0-15] is value, the mask is correspond to the value.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 45 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h |1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c |9 +-
3 files changed, 32 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 28596e7..59f24cd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -36,15 +36,18 @@
#include "rockchip_drm_fb.h"
#include "rockchip_drm_vop.h"
-#define __REG_SET_RELAXED(x, off, mask, shift, v) \
- vop_mask_write_relaxed(x, off, (mask) << shift, (v) << shift)
-#define __REG_SET_NORMAL(x, off, mask, shift, v) \
- vop_mask_write(x, off, (mask) << shift, (v) << shift)
+#define __REG_SET_RELAXED(x, off, mask, shift, v, write_mask) \
+ vop_mask_write(x, off, mask, shift, v, write_mask, true)
+
+#define __REG_SET_NORMAL(x, off, mask, shift, v, write_mask) \
+ vop_mask_write(x, off, mask, shift, v, write_mask, false)
#define REG_SET(x, base, reg, v, mode) \
- __REG_SET_##mode(x, base + reg.offset, reg.mask, reg.shift, v)
+ __REG_SET_##mode(x, base + reg.offset, \
+reg.mask, reg.shift, v, reg.write_mask)
#define REG_SET_MASK(x, base, reg, mask, v, mode) \
- __REG_SET_##mode(x, base + reg.offset, mask, reg.shift, v)
+ __REG_SET_##mode(x, base + reg.offset, \
+mask, reg.shift, v, reg.write_mask)
#define VOP_WIN_SET(x, win, name, v) \
REG_SET(x, win->base, win->phy->name, v, RELAXED)
@@ -160,27 +163,25 @@ static inline uint32_t vop_read_reg(struct vop *vop,
uint32_t base,
}
static inline void vop_mask_write(struct vop *vop, uint32_t offset,
- uint32_t mask, uint32_t v)
+ uint32_t mask, uint32_t shift, uint32_t v,
+ bool write_mask, bool relaxed)
{
- if (mask) {
- uint32_t cached_val = vop->regsbak[offset >> 2];
-
- cached_val = (cached_val & ~mask) | v;
- writel(cached_val, vop->regs + offset);
- vop->regsbak[offset >> 2] = cached_val;
- }
-}
+ if (!mask)
+ return;
-static inline void vop_mask_write_relaxed(struct vop *vop, uint32_t offset,
- uint32_t mask, uint32_t v)
-{
- if (mask) {
+ if (write_mask) {
+ v = (v << shift) | (mask << (shift + 16));
+ } else {
uint32_t cached_val = vop->regsbak[offset >> 2];
- cached_val = (cached_val & ~mask) | v;
- writel_relaxed(cached_val, vop->regs + offset);
- vop->regsbak[offset >> 2] = cached_val;
+ v = (cached_val & ~(mask << shift)) | (v << shift);
+ vop->regsbak[offset >> 2] = v;
}
+
+ if (relaxed)
+ writel_relaxed(v, vop->regs + offset);
+ else
+ writel(v, vop->regs + offset);
}
static inline uint32_t vop_get_intr_type(struct vop *vop,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 071ff0b..28dafb6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -33,6 +33,7 @@ struct vop_reg {
uint32_t offset;
uint32_t shift;
uint32_t mask;
+ bool write_mask;
};
struct vop_ctrl {
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index e75b2b8..6846868 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -23,7 +23,14 @@
#define VOP_REG(off, _mask, s) \
{.offset = off, \
.mask = _mask, \
-.shift = s,}
+.shift = s, \
+.write_mask = false,}
+
+#define VOP_REG_MASK(off, _mask, s) \
+ {.offset = off, \
+.mask = _mask, \
+.shift = s, \
+.write_mask = true,}
static const uint32_t formats_win_full[] = {
DRM_FORMAT_XRGB,
--
1.7.9.5
Re: [PATCH 1/2] MAINTAINERS: Add maintainer for OMAP DRM driver
Hi Emil, On 19/04/16 21:51, Emil Velikov wrote: > Hi Tomi, > > Just a humble suggestion/nitpick. > > On 18 April 2016 at 16:46, Tomi Valkeinen wrote: >> Add Tomi Valkeinen as omapdrm maintainer. >> >> Signed-off-by: Tomi Valkeinen >> Cc: Rob Clark >> Cc: Laurent Pinchart >> --- >> MAINTAINERS | 7 +++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 1d5b4becab6f..c235d8c72a57 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -3888,6 +3888,13 @@ S: Maintained >> F: drivers/gpu/drm/etnaviv >> F: Documentation/devicetree/bindings/display/etnaviv >> >> +DRM DRIVERS FOR TI OMAP >> +M: Tomi Valkeinen >> +L: dri-de...@lists.freedesktop.org >> +S: Maintained >> +F: drivers/gpu/drm/omapdrm >> +F: Documentation/devicetree/bindings/display/ti > Can we add a trailing "/" for these to make it obvious that they are folders ? > > We seem to be missing the Documentation patch for the other (tilcdc) > patch. Can we add that as well ? Sure, I've updated the patches. The end result now looks like: DRM DRIVERS FOR TI OMAP M: Tomi Valkeinen L: dri-de...@lists.freedesktop.org S: Maintained F: drivers/gpu/drm/omapdrm/ F: Documentation/devicetree/bindings/display/ti/ DRM DRIVERS FOR TI LCDC M: Jyri Sarha R: Tomi Valkeinen L: dri-de...@lists.freedesktop.org S: Maintained F: drivers/gpu/drm/tilcdc/ F: Documentation/devicetree/bindings/display/tilcdc/ Tomi signature.asc Description: OpenPGP digital signature
[PATCH v2 1/5] drm/rockchip: sort registers define by chip's number
No functional changes, sort the vop registers to make
code more readable.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 166 +--
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 88 +++---
2 files changed, 127 insertions(+), 127 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 3166b46..e75b2b8 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,87 @@ static const uint32_t formats_win_lite[] = {
DRM_FORMAT_BGR565,
};
+static const struct vop_scl_regs rk3066_win_scl = {
+ .scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
+ .scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
+ .scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
+ .scale_cbcr_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 16),
+};
+
+static const struct vop_win_phy rk3036_win0_data = {
+ .scl = &rk3066_win_scl,
+ .data_formats = formats_win_full,
+ .nformats = ARRAY_SIZE(formats_win_full),
+ .enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
+ .format = VOP_REG(RK3036_SYS_CTRL, 0x7, 3),
+ .rb_swap = VOP_REG(RK3036_SYS_CTRL, 0x1, 15),
+ .act_info = VOP_REG(RK3036_WIN0_ACT_INFO, 0x1fff1fff, 0),
+ .dsp_info = VOP_REG(RK3036_WIN0_DSP_INFO, 0x0fff0fff, 0),
+ .dsp_st = VOP_REG(RK3036_WIN0_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3036_WIN0_YRGB_MST, 0x, 0),
+ .uv_mst = VOP_REG(RK3036_WIN0_CBR_MST, 0x, 0),
+ .yrgb_vir = VOP_REG(RK3036_WIN0_VIR, 0x, 0),
+};
+
+static const struct vop_win_phy rk3036_win1_data = {
+ .data_formats = formats_win_lite,
+ .nformats = ARRAY_SIZE(formats_win_lite),
+ .enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 1),
+ .format = VOP_REG(RK3036_SYS_CTRL, 0x7, 6),
+ .rb_swap = VOP_REG(RK3036_SYS_CTRL, 0x1, 19),
+ .act_info = VOP_REG(RK3036_WIN1_ACT_INFO, 0x1fff1fff, 0),
+ .dsp_info = VOP_REG(RK3036_WIN1_DSP_INFO, 0x0fff0fff, 0),
+ .dsp_st = VOP_REG(RK3036_WIN1_DSP_ST, 0x1fff1fff, 0),
+ .yrgb_mst = VOP_REG(RK3036_WIN1_MST, 0x, 0),
+ .yrgb_vir = VOP_REG(RK3036_WIN1_VIR, 0x, 0),
+};
+
+static const struct vop_win_data rk3036_vop_win_data[] = {
+ { .base = 0x00, .phy = &rk3036_win0_data,
+ .type = DRM_PLANE_TYPE_PRIMARY },
+ { .base = 0x00, .phy = &rk3036_win1_data,
+ .type = DRM_PLANE_TYPE_CURSOR },
+};
+
+static const int rk3036_vop_intrs[] = {
+ DSP_HOLD_VALID_INTR,
+ FS_INTR,
+ LINE_FLAG_INTR,
+ BUS_ERROR_INTR,
+};
+
+static const struct vop_intr rk3036_intr = {
+ .intrs = rk3036_vop_intrs,
+ .nintrs = ARRAY_SIZE(rk3036_vop_intrs),
+ .status = VOP_REG(RK3036_INT_STATUS, 0xf, 0),
+ .enable = VOP_REG(RK3036_INT_STATUS, 0xf, 4),
+ .clear = VOP_REG(RK3036_INT_STATUS, 0xf, 8),
+};
+
+static const struct vop_ctrl rk3036_ctrl_data = {
+ .standby = VOP_REG(RK3036_SYS_CTRL, 0x1, 30),
+ .out_mode = VOP_REG(RK3036_DSP_CTRL0, 0xf, 0),
+ .pin_pol = VOP_REG(RK3036_DSP_CTRL0, 0xf, 4),
+ .htotal_pw = VOP_REG(RK3036_DSP_HTOTAL_HS_END, 0x1fff1fff, 0),
+ .hact_st_end = VOP_REG(RK3036_DSP_HACT_ST_END, 0x1fff1fff, 0),
+ .vtotal_pw = VOP_REG(RK3036_DSP_VTOTAL_VS_END, 0x1fff1fff, 0),
+ .vact_st_end = VOP_REG(RK3036_DSP_VACT_ST_END, 0x1fff1fff, 0),
+ .cfg_done = VOP_REG(RK3036_REG_CFG_DONE, 0x1, 0),
+};
+
+static const struct vop_reg_data rk3036_vop_init_reg_table[] = {
+ {RK3036_DSP_CTRL1, 0x},
+};
+
+static const struct vop_data rk3036_vop = {
+ .init_table = rk3036_vop_init_reg_table,
+ .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
+ .ctrl = &rk3036_ctrl_data,
+ .intr = &rk3036_intr,
+ .win = rk3036_vop_win_data,
+ .win_size = ARRAY_SIZE(rk3036_vop_win_data),
+};
+
static const struct vop_scl_extension rk3288_win_full_scl_ext = {
.cbcr_vsd_mode = VOP_REG(RK3288_WIN0_CTRL1, 0x1, 31),
.cbcr_vsu_mode = VOP_REG(RK3288_WIN0_CTRL1, 0x1, 30),
@@ -190,92 +271,11 @@ static const struct vop_data rk3288_vop = {
.win_size = ARRAY_SIZE(rk3288_vop_win_data),
};
-static const struct vop_scl_regs rk3066_win_scl = {
- .scale_yrgb_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
- .scale_yrgb_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_YRGB, 0x, 16),
- .scale_cbcr_x = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 0x0),
- .scale_cbcr_y = VOP_REG(RK3036_WIN0_SCL_FACTOR_CBR, 0x, 16),
-};
-
-static const struct vop_win_phy rk3036_win0_data = {
- .scl = &rk3066_win_scl,
- .data_formats = formats_win_full,
- .nformats = ARRAY_SIZE(formats_win_full),
- .enable = VOP_REG(RK3036_SYS_CTRL, 0x1, 0),
- .format = VOP_REG(RK3036_SYS_CTRL, 0x7, 3),
- .rb_swap = VOP_REG(RK30
[PATCH v2 5/5] dt-bindings: add documentation for Rockchip rk3399 display controllers
Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Mark Yao --- .../bindings/display/rockchip/rockchip-vop.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt index 196121f..6bf8473 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt @@ -8,6 +8,11 @@ Required properties: - compatible: value should be one of the following "rockchip,rk3036-vop"; "rockchip,rk3288-vop"; + "rockchip,rk3399-vop-big"; + "rockchip,rk3399-vop-lit"; +Document compatible values for rk3399 display controllers. +Big and little display controllers are not identical and have differing +feature sets on the rk3399. - interrupts: should contain a list of all VOP IP block interrupts in the order: VSYNC, LCD_SYSTEM. The interrupt specifier -- 1.7.9.5
Re: [Intel-wired-lan] [PATCH net-next V5 2/2] intel: ixgbevf: Support Windows hosts (Hyper-V)
On Tue, 2016-04-19 at 19:17 -0700, K. Y. Srinivasan wrote: > On Hyper-V, the VF/PF communication is a via software mediated path > as opposed to the hardware mailbox. Make the necessary > adjustments to support Hyper-V. > > Signed-off-by: K. Y. Srinivasan > --- > V2: Addressed most of the comments from > Alexander Duyck > and Rustad, Mark D . > > V3: Addressed additional comments from > Alexander Duyck > > V4: Addressed kbuild errors reported by: > kbuild test robot > > V5: Addressed additional comments from > Alexander Duyck First I commend you on actually making a proper changelog for a patch. The only issue I have is that the changelog provides not actual changes. Saying you reacted to comments does not summarize what the actual changes were. I purposely did not review the earlier versions because by the time I went to do a review, there was another version already submitted. So your changelog requires that users look at all the previous emails to actually see what Alex and Mark requested in changes. I am telling you this for future patches, it will not impact these patches, just really disappointing. I will take the extra time to track down all the previous emails and the changes requested to ensure you made all the changes that were requested of you. :-( This will just delay when I apply the patches for testing. > > drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 12 ++ > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 31 +++- > drivers/net/ethernet/intel/ixgbevf/mbx.c | 12 ++ > drivers/net/ethernet/intel/ixgbevf/vf.c | 216 > + > drivers/net/ethernet/intel/ixgbevf/vf.h | 2 + > 5 files changed, 266 insertions(+), 7 deletions(-) signature.asc Description: This is a digitally signed message part
Re: A mainline question about cgroup writeback
It looks like a bug on cgroup writeback. Is this a regression or consistent issue? If it's a regression, you may could do bisect to find out the buggy commit. On Tue, Apr 19, 2016 at 3:19 PM, zhong jiang wrote: > cgroup writeback support the filesystem both ext4 and ext2. > but, it appears to be not work when I test the function in the ext4. > The example is as follows: > echo "8:0 1048576" > blkio.throttle.write_bps_device > echo $$ > cgroup.procs > dd if=/dev/zero of=/test.c bs=1M count=10240 > 10240+0 records in > 10240+0 records out > 10737418240 bytes (11 GB) copied, 49.8796 s, 215 MB/s > > Furthering test find that the ratelimit will be limited if it write data > to disk directly. Additionly, The read ratelimit is limited whther it go > through > the page cache or not. > > The kernel version is 4.6 I have tested, And the corresponding files > in the attachment -- Thanks Alex
[PATCH] mcb: Fixed bar number assignment for the gdd
The bar number is found in reg2 within the gdd. Therefore we need to change the assigment from reg1 to reg2 which is the correct location. Signed-off-by: Andreas Werner --- drivers/mcb/mcb-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mcb/mcb-parse.c b/drivers/mcb/mcb-parse.c index 0049269..b0155b0 100644 --- a/drivers/mcb/mcb-parse.c +++ b/drivers/mcb/mcb-parse.c @@ -57,7 +57,7 @@ static int chameleon_parse_gdd(struct mcb_bus *bus, mdev->id = GDD_DEV(reg1); mdev->rev = GDD_REV(reg1); mdev->var = GDD_VAR(reg1); - mdev->bar = GDD_BAR(reg1); + mdev->bar = GDD_BAR(reg2); mdev->group = GDD_GRP(reg2); mdev->inst = GDD_INS(reg2); -- 2.6.2
Re: [PATCH 2/3] ARM: pxa: add pxa25x device-tree support
Arnd Bergmann writes: > On Sunday 10 April 2016 21:29:59 Robert Jarzmik wrote: >> + >> +DT_MACHINE_START(PXA_DT, "Marvell PXA3xx (Device Tree Support)") >> + .map_io = pxa3xx_map_io, >> + .init_irq = pxa3xx_dt_init_irq, >> + .handle_irq = pxa3xx_handle_irq, >> + .restart= pxa_restart, >> + .dt_compat = pxa3xx_dt_board_compat, >> +MACHINE_END >> > > Nothing wrong with your series, it's a straightforward continuation of what > you have for the other platforms, but I have a few comments on the method > overall, and it might be good if you could work on improving those next, > basically eliminating most of the machine descriptor contents in the long > run: > > - It would be nice not to call map_io() at all and instead ensure that all > drivers that have DT bindings use ioremap. The main reason for this is > that relying on the hardwired mapping makes it easy to get things wrong > in the bindings, by leaving out required memory ranges. Okay, that sounds good, I'll add it to my todo list. I seem to remember some legacy driver relying on one of these mapping (cpufreq for pxa relying on memory controller maybe ...), but that's a fix easy enough to queue. Let's hope I'm not bitten by something else. > - The init_irq()/handle_irq() callbacks can probably be replaced with > a IRQCHIP_DECLARE() statement per irqchip variant, which then goes > on to initialize the controller and set the handler. Okay, I'll verify that, especially that the ordering is ensured, ie. that interrupts are available at the same time that when it was the machine code calling the irq init, and that's also going to my todo list. > > - The restart method is the least important here, but I guess we can > convert that into a driver, or use an existing one from DT, like > drivers/power/reset/gpio-restart.c I think most of the required stuff is already done. The only remaining part is the reset status clearing specific to pxa, which as you said would ask for a very tiny driver. As soon as I'm done with the ac97 rework and if no v4l2 pressure is applied to pxa, I'll work on this and the MMP to pinctrl conversion. Thanks for the comments, and cheers. -- Robert
[PATCH 0/2 v6] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver
Because applied patch (commit 0beeb8d0b434b8b007ac8058fb2cac5997fff6df "ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver") is dropped, I upload new version which include dependent patch. Changes since v5: - add "ASoC: core: export snd_soc_get_dai_name" patch. Because snd_soc_of_get_dai_name() fix the property name "sound-dai". Our patch needs to change name to use, so export snd_soc_get_dai_name() which is included in snd_soc_of_get_dai_name(). Changes since v4: Change name from "sound-dai" to "capture-dai" to determine the capture path Changes since v2,v3: Fix unclear code and use sound-dai to determine the capture path Changes since v1: Use codec dai name to determine the capture path. Jean-Francois Moine (1): ASoC: core: export snd_soc_get_dai_name PC Liao (1): ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver .../devicetree/bindings/sound/mt8173-rt5650.txt|6 +++ include/sound/soc.h|2 + sound/soc/mediatek/mt8173-rt5650.c | 44 ++-- sound/soc/soc-core.c |5 ++- 4 files changed, 52 insertions(+), 5 deletions(-) -- 1.7.9.5
[PATCH 2/2 v6] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver
This patch adds second I2S connection to rt5650 codec for capture path on
mt8173-rt5650 machine driver.
Signed-off-by: PC Liao
---
.../devicetree/bindings/sound/mt8173-rt5650.txt|6 +++
sound/soc/mediatek/mt8173-rt5650.c | 44 ++--
2 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
index fe5a5ef..802dd1b 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
@@ -5,11 +5,17 @@ Required properties:
- mediatek,audio-codec: the phandles of rt5650 codecs
- mediatek,platform: the phandle of MT8173 ASoC platform
+Optional properties:
+- capture-dai: audio codec dai on capture path
+ <&rt5650 0> : Default setting. Connect rt5650 I2S1 for capture. (dai_name =
rt5645-aif1)
+ <&rt5650 1> : Connect rt5650 I2S2 for capture. (dai_name = rt5645-aif2)
+
Example:
sound {
compatible = "mediatek,mt8173-rt5650";
mediatek,audio-codec = <&rt5650>;
mediatek,platform = <&afe>;
+ capture-dai = <&rt5650 1>;
};
diff --git a/sound/soc/mediatek/mt8173-rt5650.c
b/sound/soc/mediatek/mt8173-rt5650.c
index bb09bb1..45dea22 100644
--- a/sound/soc/mediatek/mt8173-rt5650.c
+++ b/sound/soc/mediatek/mt8173-rt5650.c
@@ -85,12 +85,26 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime
*runtime)
{
struct snd_soc_card *card = runtime->card;
struct snd_soc_codec *codec = runtime->codec_dais[0]->codec;
+ const char *codec_dai_capture = runtime->codec_dais[1]->name;
int ret;
rt5645_sel_asrc_clk_src(codec,
- RT5645_DA_STEREO_FILTER |
- RT5645_AD_STEREO_FILTER,
+ RT5645_DA_STEREO_FILTER,
RT5645_CLK_SEL_I2S1_ASRC);
+
+ if (!strcmp(codec_dai_capture, "rt5645-aif1")) {
+ rt5645_sel_asrc_clk_src(codec,
+ RT5645_AD_STEREO_FILTER,
+ RT5645_CLK_SEL_I2S1_ASRC);
+ } else if (!strcmp(codec_dai_capture, "rt5645-aif2")) {
+ rt5645_sel_asrc_clk_src(codec,
+ RT5645_AD_STEREO_FILTER,
+ RT5645_CLK_SEL_I2S2_ASRC);
+ } else {
+ dev_err(card->dev, "Can't get the right codec dai\n");
+ return -EINVAL;
+ }
+
/* enable jack detection */
ret = snd_soc_card_jack_new(card, "Headset Jack",
SND_JACK_HEADPHONE | SND_JACK_MICROPHONE |
@@ -110,6 +124,11 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime
*runtime)
static struct snd_soc_dai_link_component mt8173_rt5650_codecs[] = {
{
+ /* Playback */
+ .dai_name = "rt5645-aif1",
+ },
+ {
+ /* Capture */
.dai_name = "rt5645-aif1",
},
};
@@ -149,7 +168,7 @@ static struct snd_soc_dai_link mt8173_rt5650_dais[] = {
.cpu_dai_name = "I2S",
.no_pcm = 1,
.codecs = mt8173_rt5650_codecs,
- .num_codecs = 1,
+ .num_codecs = 2,
.init = mt8173_rt5650_init,
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
@@ -177,6 +196,8 @@ static int mt8173_rt5650_dev_probe(struct platform_device
*pdev)
{
struct snd_soc_card *card = &mt8173_rt5650_card;
struct device_node *platform_node;
+ const char *codec_dai_capture;
+ struct of_phandle_args args;
int i, ret;
platform_node = of_parse_phandle(pdev->dev.of_node,
@@ -199,6 +220,23 @@ static int mt8173_rt5650_dev_probe(struct platform_device
*pdev)
"Property 'audio-codec' missing or invalid\n");
return -EINVAL;
}
+ mt8173_rt5650_codecs[1].of_node = mt8173_rt5650_codecs[0].of_node;
+
+ if (device_property_present(&pdev->dev, "capture-dai")) {
+ ret = of_parse_phandle_with_args(pdev->dev.of_node,
+"capture-dai",
+"#sound-dai-cells", 0, &args);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "%s capture-dai name fail %d\n",
+ __func__, ret);
+ return ret;
+ }
+
+ ret = snd_soc_get_dai_name(&args, &codec_dai_capture);
+ mt8173_rt5650_codecs[1].dai_name = codec_dai_capture;
+ }
+
card->dev = &pdev->dev;
platform_set_drvdata(pdev, card);
--
1.7.9.5
[PATCH 1/2 v6] ASoC: core: export snd_soc_get_dai_name
From: Jean-Francois Moine
snd_soc_get_dai_name() may be used to define a sound card with
a different syntax from the one of the simple-card.
Signed-off-by: Jean-Francois Moine
Signed-off-by: PC Liao
---
include/sound/soc.h |2 ++
sound/soc/soc-core.c |5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 02b4a21..03b2d19 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1669,6 +1669,8 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node
*np,
const char *prefix,
struct device_node **bitclkmaster,
struct device_node **framemaster);
+int snd_soc_get_dai_name(struct of_phandle_args *args,
+const char **dai_name);
int snd_soc_of_get_dai_name(struct device_node *of_node,
const char **dai_name);
int snd_soc_of_get_dai_link_codecs(struct device *dev,
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index d2e62b15..69cbbb0 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3786,8 +3786,8 @@ unsigned int snd_soc_of_parse_daifmt(struct device_node
*np,
}
EXPORT_SYMBOL_GPL(snd_soc_of_parse_daifmt);
-static int snd_soc_get_dai_name(struct of_phandle_args *args,
- const char **dai_name)
+int snd_soc_get_dai_name(struct of_phandle_args *args,
+const char **dai_name)
{
struct snd_soc_component *pos;
struct device_node *component_of_node;
@@ -3838,6 +3838,7 @@ static int snd_soc_get_dai_name(struct of_phandle_args
*args,
mutex_unlock(&client_mutex);
return ret;
}
+EXPORT_SYMBOL_GPL(snd_soc_get_dai_name);
int snd_soc_of_get_dai_name(struct device_node *of_node,
const char **dai_name)
--
1.7.9.5
[PATCH V2]sh: cmpxchg: fix a bit shift bug in big_endian os
From: Pan Xinhui
Correct bitoff in big endian OS.
Current code works correctly for 1 byte but not for 2 bytes.
Fixes: 3226aad81aa6 ("sh: support 1 and 2 byte xchg")
Signed-off-by: Pan Xinhui
Acked-by: Michael S. Tsirkin
---
changes from V1:
just add some patch comments. no code changes.
---
arch/sh/include/asm/cmpxchg-xchg.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sh/include/asm/cmpxchg-xchg.h
b/arch/sh/include/asm/cmpxchg-xchg.h
index 7219719..1e881f5 100644
--- a/arch/sh/include/asm/cmpxchg-xchg.h
+++ b/arch/sh/include/asm/cmpxchg-xchg.h
@@ -21,7 +21,7 @@ static inline u32 __xchg_cmpxchg(volatile void *ptr, u32 x,
int size)
int off = (unsigned long)ptr % sizeof(u32);
volatile u32 *p = ptr - off;
#ifdef __BIG_ENDIAN
- int bitoff = (sizeof(u32) - 1 - off) * BITS_PER_BYTE;
+ int bitoff = (sizeof(u32) - size - off) * BITS_PER_BYTE;
#else
int bitoff = off * BITS_PER_BYTE;
#endif
--
1.9.1
Re: [PATCH] thermal: tegra: mark PM functions __maybe_unused
On 2016年04月19日 20:43, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Apr 19, 2016 at 10:35:55AM +0800, Wei Ni wrote:
>>
>>
>> On 2016年04月18日 15:15, Thierry Reding wrote:
Old Signed by an unknown key
>>>
>>> On Sat, Apr 16, 2016 at 10:19:33PM +0200, Arnd Bergmann wrote:
After the PM support has been added to this driver, we get
a harmless warning when that support is disabled at compile
time:
drivers/thermal/tegra/soctherm.c:641:12: error: 'soctherm_resume' defined
but not used [-Werror=unused-function]
static int soctherm_resume(struct device *dev)
This marks the two PM functions as __maybe_unused to shut up
the warning. This is preferred over adding an #ifdef around
them, as it is harder to get wrong, and provides better
compile-time coverage.
Signed-off-by: Arnd Bergmann
Fixes: a134b4143b65 ("thermal: tegra: add PM support")
---
drivers/thermal/tegra/soctherm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> The need for this should go away when Jon's generic power domain series
>>
>> Hi Thierry,
>> Could you please show me the Jon's generic power domain series, so that I can
>> verify it.
>
> Here are the remaining patches from Jon's series:
>
> https://patchwork.ozlabs.org/patch/603285/
> https://patchwork.ozlabs.org/patch/603287/
> https://patchwork.ozlabs.org/patch/603284/
I checked this generic power domain series, it select PM and PM_GENERIC_DOMAINS
for Tegra SoC Family. But the soctherm_suspend/resume callbacks defined by
SIMPLE_DEV_PM_OPS are only used when the CONFIG_PM_SLEEP is enabled, so if the
CONFIG_PM_SLEEP is disabled, we still will get this warning.
So to avoid the warning, I think this patch is needed.
Wei.
>
> Thierry
>
> * Unknown Key
> * 0x7F3EB3A1
>
