All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v7 4/5] of/fdt: mark hotpluggable memory
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
  To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin
  Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
	Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
	Aneesh Kumar K.V, linux-kernel
In-Reply-To: <1479160961-25840-1-git-send-email-arbab@linux.vnet.ibm.com>

When movable nodes are enabled, any node containing only hotpluggable
memory is made movable at boot time.

On x86, hotpluggable memory is discovered by parsing the ACPI SRAT,
making corresponding calls to memblock_mark_hotplug().

If we introduce a dt property to describe memory as hotpluggable,
configs supporting early fdt may then also do this marking and use
movable nodes.

Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Tested-by: Balbir Singh <bsingharora@gmail.com>
---
 drivers/of/fdt.c       | 19 +++++++++++++++++++
 include/linux/of_fdt.h |  1 +
 mm/Kconfig             |  2 +-
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c89d5d2..c9b5cac 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1015,6 +1015,7 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
 	const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
 	const __be32 *reg, *endp;
 	int l;
+	bool hotpluggable;
 
 	/* We are scanning "memory" nodes only */
 	if (type == NULL) {
@@ -1034,6 +1035,7 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
 		return 0;
 
 	endp = reg + (l / sizeof(__be32));
+	hotpluggable = of_get_flat_dt_prop(node, "hotpluggable", NULL);
 
 	pr_debug("memory scan node %s, reg size %d,\n", uname, l);
 
@@ -1049,6 +1051,13 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
 		    (unsigned long long)size);
 
 		early_init_dt_add_memory_arch(base, size);
+
+		if (!hotpluggable)
+			continue;
+
+		if (early_init_dt_mark_hotplug_memory_arch(base, size))
+			pr_warn("failed to mark hotplug range 0x%llx - 0x%llx\n",
+				base, base + size);
 	}
 
 	return 0;
@@ -1146,6 +1155,11 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 	memblock_add(base, size);
 }
 
+int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
+{
+	return memblock_mark_hotplug(base, size);
+}
+
 int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
 					phys_addr_t size, bool nomap)
 {
@@ -1168,6 +1182,11 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 	WARN_ON(1);
 }
 
+int __init __weak early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size)
+{
+	return -ENOSYS;
+}
+
 int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
 					phys_addr_t size, bool nomap)
 {
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index 4341f32..271b3fd 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -71,6 +71,7 @@ extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
 extern void early_init_fdt_scan_reserved_mem(void);
 extern void early_init_fdt_reserve_self(void);
 extern void early_init_dt_add_memory_arch(u64 base, u64 size);
+extern int early_init_dt_mark_hotplug_memory_arch(u64 base, u64 size);
 extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
 					     bool no_map);
 extern void * early_init_dt_alloc_memory_arch(u64 size, u64 align);
diff --git a/mm/Kconfig b/mm/Kconfig
index 061b46b..33a9b06 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -153,7 +153,7 @@ config MOVABLE_NODE
 	bool "Enable to assign a node which has only movable memory"
 	depends on HAVE_MEMBLOCK
 	depends on NO_BOOTMEM
-	depends on X86_64 || MEMORY_HOTPLUG
+	depends on X86_64 || OF_EARLY_FLATTREE || MEMORY_HOTPLUG
 	depends on NUMA
 	default n
 	help
-- 
1.8.3.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [PATCH v7 3/5] mm: enable CONFIG_MOVABLE_NODE on non-x86 arches
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
  To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin
  Cc: linuxppc-dev, linux-mm, devicetree, Bharata B Rao,
	Nathan Fontenot, Stewart Smith, Alistair Popple, Balbir Singh,
	Aneesh Kumar K.V, linux-kernel
In-Reply-To: <1479160961-25840-1-git-send-email-arbab@linux.vnet.ibm.com>

To support movable memory nodes (CONFIG_MOVABLE_NODE), at least one of
the following must be true:

1. This config has the capability to identify movable nodes at boot.
   Right now, only x86 can do this.

2. Our config supports memory hotplug, which means that a movable node
   can be created by hotplugging all of its memory into ZONE_MOVABLE.

Fix the Kconfig definition of CONFIG_MOVABLE_NODE, which currently
recognizes (1), but not (2).

Signed-off-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
---
 mm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/Kconfig b/mm/Kconfig
index 86e3e0e..061b46b 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -153,7 +153,7 @@ config MOVABLE_NODE
 	bool "Enable to assign a node which has only movable memory"
 	depends on HAVE_MEMBLOCK
 	depends on NO_BOOTMEM
-	depends on X86_64
+	depends on X86_64 || MEMORY_HOTPLUG
 	depends on NUMA
 	default n
 	help
-- 
1.8.3.1

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply related

* [PATCH v7 2/5] mm: remove x86-only restriction of movable_node
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
  To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin
  Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
	Stewart Smith, Alistair Popple, Balbir Singh, Aneesh Kumar K.V,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479160961-25840-1-git-send-email-arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

In commit c5320926e370 ("mem-hotplug: introduce movable_node boot
option"), the memblock allocation direction is changed to bottom-up and
then back to top-down like this:

1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
2. memblock_set_bottom_up(false), called by x86's numa_init().

Even though (1) occurs in generic mm code, it is wrapped by #ifdef
CONFIG_MOVABLE_NODE, which depends on X86_64.

This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
things will be unbalanced. (1) will happen for them, but (2) will not.

This toggle was added in the first place because x86 has a delay between
adding memblocks and marking them as hotpluggable. Since other arches do
this marking either immediately or not at all, they do not require the
bottom-up toggle.

So, resolve things by moving (1) from cmdline_parse_movable_node() to
x86's setup_arch(), immediately after the movable_node parameter has
been parsed.

Signed-off-by: Reza Arbab <arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
 Documentation/kernel-parameters.txt |  2 +-
 arch/x86/kernel/setup.c             | 24 ++++++++++++++++++++++++
 mm/memory_hotplug.c                 | 20 --------------------
 3 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 37babf9..adcccd5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2401,7 +2401,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			that the amount of memory usable for all allocations
 			is not too small.
 
-	movable_node	[KNL,X86] Boot-time switch to enable the effects
+	movable_node	[KNL] Boot-time switch to enable the effects
 			of CONFIG_MOVABLE_NODE=y. See mm/Kconfig for details.
 
 	MTD_Partition=	[MTD]
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9c337b0..4cfba94 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -985,6 +985,30 @@ void __init setup_arch(char **cmdline_p)
 
 	parse_early_param();
 
+#ifdef CONFIG_MEMORY_HOTPLUG
+	/*
+	 * Memory used by the kernel cannot be hot-removed because Linux
+	 * cannot migrate the kernel pages. When memory hotplug is
+	 * enabled, we should prevent memblock from allocating memory
+	 * for the kernel.
+	 *
+	 * ACPI SRAT records all hotpluggable memory ranges. But before
+	 * SRAT is parsed, we don't know about it.
+	 *
+	 * The kernel image is loaded into memory at very early time. We
+	 * cannot prevent this anyway. So on NUMA system, we set any
+	 * node the kernel resides in as un-hotpluggable.
+	 *
+	 * Since on modern servers, one node could have double-digit
+	 * gigabytes memory, we can assume the memory around the kernel
+	 * image is also un-hotpluggable. So before SRAT is parsed, just
+	 * allocate memory near the kernel image to try the best to keep
+	 * the kernel away from hotpluggable memory.
+	 */
+	if (movable_node_is_enabled())
+		memblock_set_bottom_up(true);
+#endif
+
 	x86_report_nx();
 
 	/* after early param, so could get panic from serial */
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index cad4b91..e43142c1 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1727,26 +1727,6 @@ static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)
 static int __init cmdline_parse_movable_node(char *p)
 {
 #ifdef CONFIG_MOVABLE_NODE
-	/*
-	 * Memory used by the kernel cannot be hot-removed because Linux
-	 * cannot migrate the kernel pages. When memory hotplug is
-	 * enabled, we should prevent memblock from allocating memory
-	 * for the kernel.
-	 *
-	 * ACPI SRAT records all hotpluggable memory ranges. But before
-	 * SRAT is parsed, we don't know about it.
-	 *
-	 * The kernel image is loaded into memory at very early time. We
-	 * cannot prevent this anyway. So on NUMA system, we set any
-	 * node the kernel resides in as un-hotpluggable.
-	 *
-	 * Since on modern servers, one node could have double-digit
-	 * gigabytes memory, we can assume the memory around the kernel
-	 * image is also un-hotpluggable. So before SRAT is parsed, just
-	 * allocate memory near the kernel image to try the best to keep
-	 * the kernel away from hotpluggable memory.
-	 */
-	memblock_set_bottom_up(true);
 	movable_node_enabled = true;
 #else
 	pr_warn("movable_node option not supported\n");
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* [PATCH v7 1/5] powerpc/mm: allow memory hotplug into a memoryless node
From: Reza Arbab @ 2016-11-14 22:02 UTC (permalink / raw)
  To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
	Andrew Morton, Rob Herring, Frank Rowand, Thomas Gleixner,
	Ingo Molnar, H. Peter Anvin
  Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
	linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Bharata B Rao, Nathan Fontenot,
	Stewart Smith, Alistair Popple, Balbir Singh, Aneesh Kumar K.V,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479160961-25840-1-git-send-email-arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>

Remove the check which prevents us from hotplugging into an empty node.

The original commit b226e4621245 ("[PATCH] powerpc: don't add memory to
empty node/zone"), states that this was intended to be a temporary measure.
It is a workaround for an oops which no longer occurs.

Signed-off-by: Reza Arbab <arbab-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Acked-by: Balbir Singh <bsingharora-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
Cc: Nathan Fontenot <nfont-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Cc: Bharata B Rao <bharata-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
 arch/powerpc/mm/numa.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index a51c188..0cb6bd8 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1085,7 +1085,7 @@ static int hot_add_node_scn_to_nid(unsigned long scn_addr)
 int hot_add_scn_to_nid(unsigned long scn_addr)
 {
 	struct device_node *memory = NULL;
-	int nid, found = 0;
+	int nid;
 
 	if (!numa_enabled || (min_common_depth < 0))
 		return first_online_node;
@@ -1101,17 +1101,6 @@ int hot_add_scn_to_nid(unsigned long scn_addr)
 	if (nid < 0 || !node_online(nid))
 		nid = first_online_node;
 
-	if (NODE_DATA(nid)->node_spanned_pages)
-		return nid;
-
-	for_each_online_node(nid) {
-		if (NODE_DATA(nid)->node_spanned_pages) {
-			found = 1;
-			break;
-		}
-	}
-
-	BUG_ON(!found);
 	return nid;
 }
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related

* Re: [PATCH v2] cpufreq: conservative: Decrease frequency faster when the update deferred
From: Rafael J. Wysocki @ 2016-11-14 21:59 UTC (permalink / raw)
  To: Stratos Karafotis
  Cc: Rafael J. Wysocki, Rafael J. Wysocki, Viresh Kumar,
	linux-pm@vger.kernel.org, LKML
In-Reply-To: <8e9ccf39-002e-5f72-8b00-47968f6b19b8@semaphore.gr>

On Mon, Nov 14, 2016 at 10:46 PM, Stratos Karafotis
<stratosk@semaphore.gr> wrote:
>
>
> On 14/11/2016 10:44 μμ, Rafael J. Wysocki wrote:
>> On Sat, Nov 12, 2016 at 10:04 PM, Stratos Karafotis
>> <stratosk@semaphore.gr> wrote:
>>> Conservative governor changes the CPU frequency in steps.
>>> That means that if a CPU runs at max frequency, it will need several
>>> sampling periods to return to min frequency when the workload
>>> is finished.
>>>
>>> If the update function that calculates the load and target frequency
>>> is deferred, the governor might need even more time to decrease the
>>> frequency.
>>>
>>> This may have impact to power consumption and after all conservative
>>> should decrease the frequency if there is no workload at every sampling
>>> rate.
>>>
>>> To resolve the above issue calculate the number of sampling periods
>>> that the update is deferred. Considering that for each sampling period
>>> conservative should drop the frequency by a freq_step because the
>>> CPU was idle apply the proper subtraction to requested frequency.
>>>
>>> Below, the kernel trace with and without this patch. First an
>>> intensive workload is applied on a specific CPU. Then the workload
>>> is removed and the CPU goes to idle.
>>>
>>> WITHOUT
>>>
>>>      <idle>-0     [007] dN..   620.329153: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.350857: cpu_frequency: state=1700000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.370856: cpu_frequency: state=1900000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.390854: cpu_frequency: state=2100000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.411853: cpu_frequency: state=2200000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.432854: cpu_frequency: state=2400000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.453854: cpu_frequency: state=2600000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.494856: cpu_frequency: state=2900000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.515856: cpu_frequency: state=3100000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.536858: cpu_frequency: state=3300000 cpu_id=7
>>> kworker/7:2-556   [007] ....   620.557857: cpu_frequency: state=3401000 cpu_id=7
>>>      <idle>-0     [007] d...   669.591363: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   669.591939: cpu_idle: state=4294967295 cpu_id=7
>>>      <idle>-0     [007] d...   669.591980: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] dN..   669.591989: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   670.201224: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   670.221975: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   670.222016: cpu_frequency: state=3300000 cpu_id=7
>>>      <idle>-0     [007] d...   670.222026: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   670.234964: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   670.801251: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   671.236046: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   671.236073: cpu_frequency: state=3100000 cpu_id=7
>>>      <idle>-0     [007] d...   671.236112: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   671.393437: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   671.401277: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   671.404083: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   671.404111: cpu_frequency: state=2900000 cpu_id=7
>>>      <idle>-0     [007] d...   671.404125: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   671.404974: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   671.501180: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   671.995414: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   671.995459: cpu_frequency: state=2800000 cpu_id=7
>>>      <idle>-0     [007] d...   671.995469: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   671.996287: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   672.001305: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.078374: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   672.078410: cpu_frequency: state=2600000 cpu_id=7
>>>      <idle>-0     [007] d...   672.078419: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.158020: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   672.158040: cpu_frequency: state=2400000 cpu_id=7
>>>      <idle>-0     [007] d...   672.158044: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.160038: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   672.234557: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.237121: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   672.237174: cpu_frequency: state=2100000 cpu_id=7
>>>      <idle>-0     [007] d...   672.237186: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.237778: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   672.267902: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.269860: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   672.269906: cpu_frequency: state=1900000 cpu_id=7
>>>      <idle>-0     [007] d...   672.269914: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.271902: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...   672.751342: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...   672.823056: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-556   [007] ....   672.823095: cpu_frequency: state=1600000 cpu_id=7
>>>
>>> WITH
>>>
>>>      <idle>-0     [007] dN..  4380.928009: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-399   [007] ....  4380.949767: cpu_frequency: state=2000000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4380.969765: cpu_frequency: state=2200000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4381.009766: cpu_frequency: state=2500000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4381.029767: cpu_frequency: state=2600000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4381.049769: cpu_frequency: state=2800000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4381.069769: cpu_frequency: state=3000000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4381.089771: cpu_frequency: state=3100000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4381.109772: cpu_frequency: state=3400000 cpu_id=7
>>> kworker/7:2-399   [007] ....  4381.129773: cpu_frequency: state=3401000 cpu_id=7
>>>      <idle>-0     [007] d...  4428.226159: cpu_idle: state=1 cpu_id=7
>>>      <idle>-0     [007] d...  4428.226176: cpu_idle: state=4294967295 cpu_id=7
>>>      <idle>-0     [007] d...  4428.226181: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...  4428.227177: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...  4428.551640: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...  4428.649239: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-399   [007] ....  4428.649268: cpu_frequency: state=2800000 cpu_id=7
>>>      <idle>-0     [007] d...  4428.649278: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...  4428.689856: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...  4428.799542: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...  4428.801683: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-399   [007] ....  4428.801748: cpu_frequency: state=1700000 cpu_id=7
>>>      <idle>-0     [007] d...  4428.801761: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...  4428.806545: cpu_idle: state=4294967295 cpu_id=7
>>> ...
>>>      <idle>-0     [007] d...  4429.051880: cpu_idle: state=4 cpu_id=7
>>>      <idle>-0     [007] d...  4429.086240: cpu_idle: state=4294967295 cpu_id=7
>>> kworker/7:2-399   [007] ....  4429.086293: cpu_frequency: state=1600000 cpu_id=7
>>>
>>> Without the patch the CPU dropped to min frequency after 3.2s
>>> With the patch applied the CPU dropped to min frequency after 0.86s
>>>
>>> Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
>>> ---
>>>  v1 -> v2
>>> - Use correct terminology in change log
>>> - Change the member variable name from 'deferred_periods' to 'idle_periods'
>>> - Fix format issue
>>>
>>>  drivers/cpufreq/cpufreq_conservative.c | 14 +++++++++++++-
>>>  drivers/cpufreq/cpufreq_governor.c     | 18 +++++++++++++-----
>>>  drivers/cpufreq/cpufreq_governor.h     |  1 +
>>>  3 files changed, 27 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq_conservative.c b/drivers/cpufreq/cpufreq_conservative.c
>>> index fa5ece3..d787772 100644
>>> --- a/drivers/cpufreq/cpufreq_conservative.c
>>> +++ b/drivers/cpufreq/cpufreq_conservative.c
>>> @@ -73,7 +73,19 @@ static unsigned int cs_dbs_update(struct cpufreq_policy *policy)
>>>          */
>>>         if (cs_tuners->freq_step == 0)
>>>                 goto out;
>>> -
>>> +       /*
>>> +        * Decrease requested_freq for each idle period that we didn't
>>> +        * update the frequency
>>> +        */
>>> +       if (policy_dbs->idle_periods < UINT_MAX) {
>>> +               unsigned int freq_target = policy_dbs->idle_periods *
>>> +                               get_freq_target(cs_tuners, policy);
>>> +               if (requested_freq > freq_target)
>>> +                       requested_freq -= freq_target;
>>> +               else
>>> +                       requested_freq = policy->min;
>>> +               policy_dbs->idle_periods = UINT_MAX;
>>> +       }
>>>         /*
>>>          * If requested_freq is out of range, it is likely that the limits
>>>          * changed in the meantime, so fall back to current frequency in that
>>> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
>>> index 3729474..1bc7137 100644
>>> --- a/drivers/cpufreq/cpufreq_governor.c
>>> +++ b/drivers/cpufreq/cpufreq_governor.c
>>> @@ -117,7 +117,7 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>         struct policy_dbs_info *policy_dbs = policy->governor_data;
>>>         struct dbs_data *dbs_data = policy_dbs->dbs_data;
>>>         unsigned int ignore_nice = dbs_data->ignore_nice_load;
>>> -       unsigned int max_load = 0;
>>> +       unsigned int max_load = 0, idle_periods = UINT_MAX;
>>>         unsigned int sampling_rate, io_busy, j;
>>>
>>>         /*
>>> @@ -163,8 +163,12 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>                          * calls, so the previous load value can be used then.
>>>                          */
>>>                         load = j_cdbs->prev_load;
>>> -               } else if (unlikely(time_elapsed > 2 * sampling_rate &&
>>> -                                   j_cdbs->prev_load)) {
>>> +               } else if (unlikely(time_elapsed > 2 * sampling_rate)) {
>>> +                       unsigned int periods = time_elapsed / sampling_rate;
>>> +
>>> +                       if (periods < idle_periods)
>>> +                               idle_periods = periods;
>>> +
>>>                         /*
>>>                          * If the CPU had gone completely idle and a task has
>>>                          * just woken up on this CPU now, it would be unfair to
>>> @@ -189,8 +193,10 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>                          * 'time_elapsed' (as compared to the sampling rate)
>>>                          * indicates this scenario.
>>>                          */
>>> -                       load = j_cdbs->prev_load;
>>> -                       j_cdbs->prev_load = 0;
>>> +                       if (j_cdbs->prev_load) {
>>> +                               load = j_cdbs->prev_load;
>>> +                               j_cdbs->prev_load = 0;
>>> +                       }
>>>                 } else {
>>>                         if (time_elapsed >= idle_time) {
>>>                                 load = 100 * (time_elapsed - idle_time) / time_elapsed;
>>> @@ -218,6 +224,8 @@ unsigned int dbs_update(struct cpufreq_policy *policy)
>>>                 if (load > max_load)
>>>                         max_load = load;
>>>         }
>>> +       policy_dbs->idle_periods = idle_periods;
>>> +
>>>         return max_load;
>>>  }
>>>  EXPORT_SYMBOL_GPL(dbs_update);
>>
>> I have a murky suspicion that the changes in dbs_update() are going to
>> break something.  I need to recall what it was, though.
>
> The only change in dbs_update() is the calculation of 'idle_periods'.
> If I don't miss something I left current functionality untouched.

Well, not quite.  The else branch may now trigger when
j_cdbs->prev_load is zero too which it didn't do before, AFAICS.

> But you know better. :)

I simply spent some time on this code several months ago and I
wouldn't like to repeat that experience. :-)

>
> Please let me know if you want me to proceed with the changes that
> Viresh suggested.

Yes, I'm going to apply his patch.

>
> Thank you both for your time.

No problem.

Thanks,
Rafael

^ permalink raw reply

* Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor
From: Sakari Ailus @ 2016-11-14 21:58 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: Pavel Machek, ivo.g.dimitrov.75, pali.rohar, linux-media, galak,
	mchehab, linux-kernel
In-Reply-To: <20161104000525.jzouapxxwwiwdwjy@earth>

Hi Sebastian,

On Fri, Nov 04, 2016 at 01:05:25AM +0100, Sebastian Reichel wrote:
> Hi,
> 
> On Fri, Nov 04, 2016 at 01:05:01AM +0200, Sakari Ailus wrote:
> > On Thu, Nov 03, 2016 at 11:48:43PM +0100, Sebastian Reichel wrote:
> > > On Tue, Nov 01, 2016 at 12:54:08AM +0200, Sakari Ailus wrote:
> > > > > > Thanks, this answered half of my questions already. ;-)
> > > > > :-).
> > > > > 
> > > > > I'll have to go through the patches, et8ek8 driver is probably not
> > > > > enough to get useful video. platform/video-bus-switch.c is needed for
> > > > > camera switching, then some omap3isp patches to bind flash and
> > > > > autofocus into the subdevice.
> > > > > 
> > > > > Then, device tree support on n900 can be added.
> > > > 
> > > > I briefly discussed with with Sebastian.
> > > > 
> > > > Do you think the elusive support for the secondary camera is worth keeping
> > > > out the main camera from the DT in mainline? As long as there's a reasonable
> > > > way to get it working, I'd just merge that. If someone ever gets the
> > > > secondary camera working properly and nicely with the video bus switch,
> > > > that's cool, we'll somehow deal with the problem then. But frankly I don't
> > > > think it's very useful even if we get there: the quality is really bad.
> > > 
> > > If we want to keep open the option to add proper support for the
> > > second camera, we could also add the bus switch and not add the
> > > front camera node in DT. Then adding the front camera does not
> > > require DT or userspace API changes. It would need an additional
> > > DT quirk in arch/arm/mach-omap2/board-generic.c for RX51, which
> > > adds the CCP2 bus settings from the camera node to the bus
> > > switch node to keep isp_of_parse_node happy. That should be
> > > easy to implement and not add much delay in upstreaming.
> > 
> > By adding the video bus switch we have a little bit more complex system as a
> > whole. The V4L2 async does not currently support this. There's more here:
> > 
> > <URL:http://www.spinics.net/lists/linux-media/msg107262.html>
> 
> I'm not sure what part relevant for video-bus-switch is currently
> not supported?
> 
> video-bus-switch registers its own async notifier and only registers
> itself as subdevices to omap3isp, once its own subdevices have been
> registered successfully.

Do you happen to have patches for this?

I still think we should clean up the V4L2 async framework though.

> 
> > What I thought was that once we have everything that's required in
> > place, we can just change what's in DT. But the software needs to
> > continue to work with the old DT content.
> 
> Right, so DT is not a problem. But adding the switch would change
> the media-graph, which is exposed to userspace.

Well, yes, indeed. We'll have those cases coming anyway, as support for
multiple streams over a single link is added. In some cases more sub-devices
will be needed to expose all the necessary configurability to the user.

> 
> > > For actually getting both cameras available with runtime-switching
> > > the proper solution would probably involve moving the parsing of
> > > the bus-settings to the sensor driver and providing a callback.
> > > This callback can be called by omap3isp when it wants to configure
> > > the phy (which is basically when it starts streaming). That seems
> > > to be the only place needing the buscfg anyways.
> > > 
> > > Then the video-bus-switch could do something like this (pseudocode):
> > > 
> > > static void get_buscfg(struct *this, struct *buscfg) {
> > >     if (selected_cam == 0)
> > >         return this->sensor_a->get_buscfg(buscfg);
> > >     else
> > >         return this->sensor_b->get_buscfg(buscfg);
> > > }
> > > 
> > > Regarding the usefulness: I noticed, that the Neo900 people also
> > > plan to have the bus-switch [0]. It's still the same crappy front-cam,
> > > though. Nevertheless it might be useful for testing. It has nice
> > > test-image capabilities, which might be useful for regression
> > > testing once everything is in place.
> > > 
> > > [0] http://neo900.org/stuff/block-diagrams/neo900/neo900.html
> > 
> > Seriously? I suppose there should be no need for that anymore, is there?
> > 
> > I think they wanted to save one GPIO in order to shave off 0,0001 cents from
> > the manufacturing costs or something like that. And the result is...
> > painful. :-I
> 
> CSI1/CCP2 is more than a single I/O pin, isn't it? Or do you
> reference to the GPIO dual use to enable frontcam and switch
> between the cameras? That is indeed a really ugly solution :(

The GPIO, yes. It was a really bad idea...

-- 
Regards,

Sakari Ailus
e-mail: sakari.ailus@iki.fi	XMPP: sailus@retiisi.org.uk

^ permalink raw reply

* [Buildroot] [PATCH] openjpeg: refresh patches
From: Baruch Siach @ 2016-11-14 21:58 UTC (permalink / raw)
  To: buildroot

The 2.1.2 version bump did not take into account the recently added fixes.
Update the patches to apply based on upstream pull requests #866 and #867.

Cc: Peter Seiderer <ps.report@gmx.net>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
 ...tiff-append-flags-found-by-pkg-config-if-.patch | 60 +++++++++++-----------
 ...lcms2-append-flags-found-by-pkg-config-if.patch | 38 +++++++-------
 2 files changed, 50 insertions(+), 48 deletions(-)

diff --git a/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch b/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch
index be509024de86..bce790a47863 100644
--- a/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch
+++ b/package/openjpeg/0001-thirdparty-tiff-append-flags-found-by-pkg-config-if-.patch
@@ -17,56 +17,56 @@ Signed-off-by: Samuel Martin <s.martin49@gmail.com>
  1 file changed, 21 insertions(+), 2 deletions(-)
 
 diff --git a/thirdparty/CMakeLists.txt b/thirdparty/CMakeLists.txt
-index d1e68ca..225f51d 100644
+index cb24b43b58e2..cd6a5e1391b0 100644
 --- a/thirdparty/CMakeLists.txt
 +++ b/thirdparty/CMakeLists.txt
 @@ -1,5 +1,9 @@
  # 3rd party libs
  
-+IF(NOT BUILD_THIRDPARTY)
++if(NOT BUILD_THIRDPARTY)
 +  include(FindPkgConfig)
-+ENDIF(NOT BUILD_THIRDPARTY)
++endif(NOT BUILD_THIRDPARTY)
 +
  #------------
  # Try to find lib Z
- IF(BUILD_THIRDPARTY)
-@@ -35,6 +39,9 @@ IF(BUILD_THIRDPARTY)
-   SET(PNG_INCLUDE_DIRNAME ${OPENJPEG_SOURCE_DIR}/thirdparty/libpng PARENT_SCOPE)
- ELSE (BUILD_THIRDPARTY)
-   IF (ZLIB_FOUND)
+ if(BUILD_THIRDPARTY)
+@@ -36,6 +40,9 @@ if(BUILD_THIRDPARTY)
+ else(BUILD_THIRDPARTY)
+   if(ZLIB_FOUND)
+     find_package(PNG)
 +    # Static only build:
 +    #   it is not necessary to invoke pkg_check_module on libpng, because libpng
 +    #   only depends on zlib, which is already checked.
-     FIND_PACKAGE(PNG)
-     IF(PNG_FOUND)
+     if(PNG_FOUND)
        message(STATUS "Your system seems to have a PNG lib available, we will use it")
-@@ -66,12 +73,24 @@ IF(BUILD_THIRDPARTY)
-   SET(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
- ELSE (BUILD_THIRDPARTY)
-   FIND_PACKAGE(TIFF)
+       set(OPJ_HAVE_PNG_H 1 PARENT_SCOPE)
+@@ -66,12 +73,24 @@ if(BUILD_THIRDPARTY)
+   set(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
+ else(BUILD_THIRDPARTY)
+   find_package(TIFF)
 +  # Static only build:
 +  #   it is necessary to invoke pkg_check_module on libtiff since it may have
 +  #   several other dependencies not declared by its cmake module, but they are
 +  #   in the its pkgconfig module.
-+  IF(PKG_CONFIG_FOUND)
-+    FOREACH(pc_tiff_module tiff tiff3 tiff4 tiff-3 tiff-4 libtiff libtiff3 libtiff4 libtiff-3 libtiff-4)
++  if(PKG_CONFIG_FOUND)
++    foreach(pc_tiff_module tiff tiff3 tiff4 tiff-3 tiff-4 libtiff libtiff3 libtiff4 libtiff-3 libtiff-4)
 +      pkg_check_modules(PC_TIFF QUIET ${pc_tiff_module})
-+      IF(PC_TIFF_FOUND)
++      if(PC_TIFF_FOUND)
 +        break()
-+      ENDIF(PC_TIFF_FOUND)
-+    ENDFOREACH()
-+  ENDIF(PKG_CONFIG_FOUND)
-   IF(TIFF_FOUND)
++      endif(PC_TIFF_FOUND)
++    endforeach()
++  endif(PKG_CONFIG_FOUND)
+   if(TIFF_FOUND)
      message(STATUS "Your system seems to have a TIFF lib available, we will use it")
-     SET(OPJ_HAVE_TIFF_H 1 PARENT_SCOPE)
-     SET(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
--    SET(TIFF_LIBNAME ${TIFF_LIBRARIES} PARENT_SCOPE)
--    SET(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} PARENT_SCOPE)
-+    SET(TIFF_LIBNAME ${TIFF_LIBRARIES} ${PC_TIFF_STATIC_LIBRARIES} PARENT_SCOPE)
-+    SET(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} ${PC_TIFF_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
-   ELSE (TIFF_FOUND) # not found
-     SET(OPJ_HAVE_TIFF_H 0 PARENT_SCOPE)
-     SET(OPJ_HAVE_LIBTIFF 0 PARENT_SCOPE)
+     set(OPJ_HAVE_TIFF_H 1 PARENT_SCOPE)
+     set(OPJ_HAVE_LIBTIFF 1 PARENT_SCOPE)
+-    set(TIFF_LIBNAME ${TIFF_LIBRARIES} PARENT_SCOPE)
+-    set(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} PARENT_SCOPE)
++    set(TIFF_LIBNAME ${TIFF_LIBRARIES} ${PC_TIFF_STATIC_LIBRARIES} PARENT_SCOPE)
++    set(TIFF_INCLUDE_DIRNAME ${TIFF_INCLUDE_DIR} ${PC_TIFF_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
+   else(TIFF_FOUND) # not found
+     set(OPJ_HAVE_TIFF_H 0 PARENT_SCOPE)
+     set(OPJ_HAVE_LIBTIFF 0 PARENT_SCOPE)
 -- 
 2.10.2
 
diff --git a/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch b/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch
index 4366c0af88cf..5697b82de2e0 100644
--- a/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch
+++ b/package/openjpeg/0002-thirdparty-lcms2-append-flags-found-by-pkg-config-if.patch
@@ -7,9 +7,11 @@ Subject: [PATCH] thirdparty: lcms2: append flags found by pkg-config if
 This change allows to get all required CFLAGS/LDFLAGS in case of static only
 build.
 
-Fixes a buildroot build failure (see [1]).
+Fixes a buildroot build failure (see [1], [2] and [3]).
 
 [1] http://autobuild.buildroot.net/results/5ce/5cee20afd8bef5268832cddcb3a5270746be7a57
+[2] http://lists.busybox.net/pipermail/buildroot/2016-November/177187.html
+[3] http://lists.busybox.net/pipermail/buildroot/2016-November/177188.html
 
 Signed-off-by: Peter Seiderer <ps.report@gmx.net>
 ---
@@ -17,31 +19,31 @@ Signed-off-by: Peter Seiderer <ps.report@gmx.net>
  1 file changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/thirdparty/CMakeLists.txt b/thirdparty/CMakeLists.txt
-index 225f51d..42770ad 100644
+index cd6a5e1391b0..a3a8494d89b1 100644
 --- a/thirdparty/CMakeLists.txt
 +++ b/thirdparty/CMakeLists.txt
-@@ -113,12 +113,19 @@ IF( BUILD_THIRDPARTY)
-   SET(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
- ELSE (BUILD_THIRDPARTY)
-   FIND_PACKAGE(LCMS2)
+@@ -113,12 +113,19 @@ if( BUILD_THIRDPARTY)
+   set(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
+ else(BUILD_THIRDPARTY)
+   find_package(LCMS2)
 +  # Static only build:
 +  #   it is necessary to invoke pkg_check_module on lcms2 since it may have
 +  #   several other dependencies not declared by its cmake module, but they are
 +  #   in the its pkgconfig module.
-+  IF(PKG_CONFIG_FOUND)
++  if(PKG_CONFIG_FOUND)
 +    pkg_check_modules(PC_LCMS2 QUIET lcms2)
-+  ENDIF(PKG_CONFIG_FOUND)
-   IF(LCMS2_FOUND)
++  endif(PKG_CONFIG_FOUND)
+   if(LCMS2_FOUND)
      message(STATUS "Your system seems to have a LCMS2 lib available, we will use it")
-     SET(OPJ_HAVE_LCMS2_H 1 PARENT_SCOPE)
-     SET(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
--    SET(LCMS_LIBNAME ${LCMS2_LIBRARIES} PARENT_SCOPE)
--    SET(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} PARENT_SCOPE)
-+    SET(LCMS_LIBNAME ${LCMS2_LIBRARIES} ${PC_LCMS2_STATIC_LIBRARIES} PARENT_SCOPE)
-+    SET(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} ${PC_LCMS2_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
-   ELSE (LCMS2_FOUND) # not found lcms2
+     set(OPJ_HAVE_LCMS2_H 1 PARENT_SCOPE)
+     set(OPJ_HAVE_LIBLCMS2 1 PARENT_SCOPE)
+-    set(LCMS_LIBNAME ${LCMS2_LIBRARIES} PARENT_SCOPE)
+-    set(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} PARENT_SCOPE)
++    set(LCMS_LIBNAME ${LCMS2_LIBRARIES} ${PC_LCMS2_STATIC_LIBRARIES} PARENT_SCOPE)
++    set(LCMS_INCLUDE_DIRNAME ${LCMS2_INCLUDE_DIRS} ${PC_LCMS2_STATIC_INCLUDE_DIRS} PARENT_SCOPE)
+   else(LCMS2_FOUND) # not found lcms2
      # try to find LCMS
-     FIND_PACKAGE(LCMS)
+     find_package(LCMS)
 -- 
-2.8.1
+2.10.2
 
-- 
2.10.2

^ permalink raw reply related

* [PATCH 2/2] libselinux, libsemanage: swig: use SWIG_fail when an error occurs
From: Nicolas Iooss @ 2016-11-14 21:57 UTC (permalink / raw)
  To: selinux
In-Reply-To: <20161114215712.18962-1-nicolas.iooss@m4x.org>

Using SWIG_fail in the Python SWIG wrappers makes the wrapping function
destroy/free the memory which could have been dynamically allocated
before calling the wrapped function. This thus prevents possible memory
leaks in the wrappers of set*con(), set*con_raw(), security_compute_*(),
etc.

Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
 libselinux/src/exception.sh  | 2 +-
 libsemanage/src/exception.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libselinux/src/exception.sh b/libselinux/src/exception.sh
index a3ff83235ced..d6c8c71713ad 100755
--- a/libselinux/src/exception.sh
+++ b/libselinux/src/exception.sh
@@ -8,7 +8,7 @@ echo "
   \$action 
   if (result < 0) {
      PyErr_SetFromErrno(PyExc_OSError);
-     return NULL;
+     SWIG_fail;
   }
 }
 "
diff --git a/libsemanage/src/exception.sh b/libsemanage/src/exception.sh
index a4095f4f8ba6..97bc2ae879f2 100644
--- a/libsemanage/src/exception.sh
+++ b/libsemanage/src/exception.sh
@@ -4,7 +4,7 @@ echo "
   \$action
   if (result < 0) {
      PyErr_SetFromErrno(PyExc_OSError);
-     return NULL;
+     SWIG_fail;
   }
 }
 "
-- 
2.10.2

^ permalink raw reply related

* [PATCH 1/2] libselinux,libsemanage: fall back to gcc in exception.sh
From: Nicolas Iooss @ 2016-11-14 21:57 UTC (permalink / raw)
  To: selinux

clang does not support -aux-info option. When exception.sh is run with
CC=clang, use gcc to build selinuxswig_python_exception.i and
semanageswig_python_exception.i.

This does not solve the issue of building libselinux and libsemanage
Python wrappers on a system without gcc. However parsing the result of
"gcc -aux-info" is easier than parsing the header files so stay with
this command at least for now.

Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
---
 libselinux/src/exception.sh  | 6 +++++-
 libsemanage/src/exception.sh | 6 +++++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/libselinux/src/exception.sh b/libselinux/src/exception.sh
index a58bf3f45778..a3ff83235ced 100755
--- a/libselinux/src/exception.sh
+++ b/libselinux/src/exception.sh
@@ -15,6 +15,10 @@ echo "
 ;;
 esac
 }
-${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/selinux/selinux.h
+if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/selinux/selinux.h
+then
+    # clang does not support -aux-info so fall back to gcc
+    gcc -x c -c -I../include - -aux-info temp.aux < ../include/selinux/selinux.h
+fi
 for i in `awk '/<stdin>.*extern int/ { print $6 }' temp.aux`; do except $i ; done 
 rm -f -- temp.aux -.o
diff --git a/libsemanage/src/exception.sh b/libsemanage/src/exception.sh
index d18959cbe85d..a4095f4f8ba6 100644
--- a/libsemanage/src/exception.sh
+++ b/libsemanage/src/exception.sh
@@ -9,6 +9,10 @@ echo "
 }
 "
 }
-${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/semanage/semanage.h
+if ! ${CC:-gcc} -x c -c -I../include - -aux-info temp.aux < ../include/semanage/semanage.h
+then
+    # clang does not support -aux-info so fall back to gcc
+    gcc -x c -c -I../include - -aux-info temp.aux < ../include/semanage/semanage.h
+fi
 for i in `awk '/extern int/ { print $6 }' temp.aux`; do except $i ; done
 rm -f -- temp.aux -.o
-- 
2.10.2

^ permalink raw reply related

* Re: [Xenomai] irqchip missing?
From: Lowell Gilbert @ 2016-11-14 21:56 UTC (permalink / raw)
  To: xenomai
In-Reply-To: <d9406df2-c733-579b-8494-036c7e138e7b@xenomai.org>

Philippe Gerum <rpm@xenomai.org> writes:

> On 11/07/2016 11:11 PM, Lowell Gilbert wrote:
>> Lowell Gilbert <kludge@be-well.ilk.org> writes:
>> 
>>> I have a system based on a Cortex A9. When I was running under Xenomai
>>> 2.6, I was able to grab interrupts in RTDM. A few months ago, I updated
>>> from a 3.16 Linux kernel and 2.6.4 Xenomai to a 4.1 kernel with 3.0.2
>>> Xenomai. I'm trying to grab the same IRQ now, and the irqchip doesn't
>>> seem to have a set_affinity callback, so I get a kernel dump.
>> 
>> ipipe_set_irq_affinity() is being called with a GPIO chip, instead of
>> the GIC that I expect. Why would that be?
>> 
>
> ipipe_set_irq_affinity() receives an interrupt number, not an IC
> descriptor. Are you referring to the irq_set_affinity() handler from the
> irq_chip descriptor instead? Please be specific about the code you refer
> to (call site).

In ipipe_set_irq_affinity(), I checked irq_get_chip(irq)->name. That
gave me "gpio-dwapb" rather than "GIC".  There is no irq_set_affinity
driver on that chip, and so it crashes.

I haven't figured out how the chip table gets set up.

Be well.


^ permalink raw reply

* [Buildroot] [PATCH] package/gcc: backport xtensa trap pattern for 5.x
From: Thomas Petazzoni @ 2016-11-14 21:55 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1479117941-14895-1-git-send-email-jcmvbkbc@gmail.com>

Hello,

On Mon, 14 Nov 2016 02:05:41 -0800, Max Filippov wrote:
> gcc 5.x uses trap pattern extensively to mark locations where program
> execution should never get. Default pattern implementation emits a call
> to 'abort' function. This function however is not always available, e.g.
> it's not available for the libc dynamic linker. Backport implementation
> of the trap pattern for xtensa that does not result in a call to
> 'abort'.
> 
> Fixes:
>   http://autobuild.buildroot.net/results/0fbcc4475545904bf88f25a3bdf3ee552bf4960e
>   http://autobuild.buildroot.net/results/cb7f5bdfac615d774f3bcd1b802f8d74460bc557
>   http://autobuild.buildroot.net/results/cf3dc9ae4f74ff28b285f1a862b71d96384d7651
> 
> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
> ---
>  .../5.4.0/875-xtensa-implement-trap-pattern.patch  | 67 ++++++++++++++++++++++
>  1 file changed, 67 insertions(+)
>  create mode 100644 package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch

Applied to master, thanks. However, I'm wondering if this backport
should also be done on gcc versions earlier than 5.x. Could you clarify
this point?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [U-Boot] [RFC 1/1] image: Add TEE loading to FIT loadable processing
From: Andrew F. Davis @ 2016-11-14 21:55 UTC (permalink / raw)
  To: u-boot
In-Reply-To: <CAPnjgZ0dALeZqUkgE7sD-bpoV7NRqjoQKUmpF=Hjz76o3LpNRQ@mail.gmail.com>

On 11/14/2016 02:44 PM, Simon Glass wrote:
> Hi Andrew,
> 
> On 14 November 2016 at 12:49, Andrew F. Davis <afd@ti.com> wrote:
>> To help automate the loading of a TEE image during the boot we add a new
>> FIT section type 'tee', when we see this type while loading the loadable
>> sections we automatically call the platforms TEE processing function on
>> this image section.
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
>>  Kconfig         | 10 ++++++++++
>>  common/image.c  | 18 ++++++++++++++++++
>>  include/image.h | 15 +++++++++++++++
>>  3 files changed, 43 insertions(+)
>>
>> diff --git a/Kconfig b/Kconfig
>> index 1263d0b..97cf7c8 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -291,6 +291,16 @@ config FIT_IMAGE_POST_PROCESS
>>           injected into the FIT creation (i.e. the blobs would have been pre-
>>           processed before being added to the FIT image).
>>
>> +config FIT_IMAGE_TEE_PROCESS
>> +       bool "Enable processing of TEE images during FIT loading by U-Boot"
>> +       depends on FIT && TI_SECURE_DEVICE
> 
> This is a generic option so I don't think it should depend on TI.
> 

This was based on FIT_IMAGE_POST_PROCESS which is also generic but
depends on TI as we currently are the only users.

I think it should be removed from both, so I'll remove it here at least.

>> +       help
>> +         Allows platforms to perform processing, such as authentication and
>> +         installation, on TEE images extracted from FIT images in a platform
>> +         or board specific way. In order to use this feature a platform or
>> +         board-specific implementation of board_tee_image_process() must be
>> +         provided.
>> +
>>  config SPL_DFU_SUPPORT
>>         bool "Enable SPL with DFU to load binaries to memory device"
>>         depends on USB
>> diff --git a/common/image.c b/common/image.c
>> index 7604494..4552ca5 100644
>> --- a/common/image.c
>> +++ b/common/image.c
>> @@ -165,6 +165,7 @@ static const table_entry_t uimage_type[] = {
>>         {       IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" },
>>         {       IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image" },
>>         {       IH_TYPE_FPGA,       "fpga",       "FPGA Image" },
>> +       {       IH_TYPE_TEE,        "tee",        "TEE OS Image",},
> 
> Perhaps write out TEE in full? It's a bit cryptic.
> 

Will do.

>>         {       -1,                 "",           "",                   },
>>  };
>>
>> @@ -1408,6 +1409,8 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
>>         int fit_img_result;
>>         const char *uname;
>>
>> +       uint8_t img_type;
>> +
>>         /* Check to see if the images struct has a FIT configuration */
>>         if (!genimg_has_config(images)) {
>>                 debug("## FIT configuration was not specified\n");
>> @@ -1447,6 +1450,21 @@ int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
>>                                 /* Something went wrong! */
>>                                 return fit_img_result;
>>                         }
>> +
>> +                       fit_img_result = fit_image_get_node(buf, uname);
>> +                       if (fit_img_result < 0) {
>> +                               /* Something went wrong! */
>> +                               return fit_img_result;
>> +                       }
>> +                       fit_img_result = fit_image_get_type(buf, fit_img_result, &img_type);
>> +                       if (fit_img_result < 0) {
>> +                               /* Something went wrong! */
>> +                               return fit_img_result;
>> +                       }
>> +#if defined(CONFIG_FIT_IMAGE_TEE_PROCESS)
>> +                       if (img_type == IH_TYPE_TEE)
>> +                               board_tee_image_process(img_data, img_len);
>> +#endif
> 
> Instead of putting this here, I think it would be better for
> boot_get_loadable() to return the correct values for ld_start and
> ld_len. Perhaps you need to pass it the loadable index to load, so it
> is called multiple times? The only caller is bootm_find_images().
> 

Something like how boot_get_fpga() does it? This seems like a lot of
code duplication between boot_get_fpga() and boot_get_loadable(), and
both ignore ld_start and ld_len.

Does it not make more sense to have a single function for loadable
components like we have now? The loadables themselves have a type we can
switch on and then call a platform specific hook for that loadable type.

I don't want a big TI specific function in common/image.c, but if this
is okay I'll move it out of platform and into here.

> It is too ugly, I think, to check the image type in the 'load'
> function, and do special things.
> 

The alternative is a boot_get_<type> function for each type. All called
from bootm_find_images().

>>                 }
>>                 break;
>>         default:
>> diff --git a/include/image.h b/include/image.h
>> index 2b1296c..57084c8 100644
>> --- a/include/image.h
>> +++ b/include/image.h
>> @@ -279,6 +279,7 @@ enum {
>>         IH_TYPE_ZYNQMPIMAGE,            /* Xilinx ZynqMP Boot Image */
>>         IH_TYPE_FPGA,                   /* FPGA Image */
>>         IH_TYPE_VYBRIDIMAGE,    /* VYBRID .vyb Image */
>> +       IH_TYPE_TEE,            /* Trusted Execution Environment OS Image */
>>
>>         IH_TYPE_COUNT,                  /* Number of image types */
>>  };
>> @@ -1263,4 +1264,18 @@ int board_fit_config_name_match(const char *name);
>>  void board_fit_image_post_process(void **p_image, size_t *p_size);
>>  #endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
>>
>> +#ifdef CONFIG_FIT_IMAGE_TEE_PROCESS
> 
> I don't think you should have this #ifdef in the header file.
> 

Then board_tee_image_process would always have a deceleration, even on
boards without a definition of it.

>> +/**
>> + * board_fit_tee_process() - Do any needed processing on a loaded TEE image
>> + *
>> + * This is used to verify, decrypt, and/or install a TEE in a platform or
>> + * board specific way.
> 
> nit: board-specific
> 
> 
>> + *
>> + * @tee_image: pointer to the image
> 
> What format is the image?
> 

Platform specific. Different TEEs have different header types and our
platforms require different signing headers.

>> + * @tee_size: the image size
>> + * @return no return value (failure should be handled internally)
>> + */
>> +void board_tee_image_process(void *tee_image, size_t tee_size);
> 
> I think it's a good idea to return an error code here, since the
> function may fail.
> 
>> +#endif /* CONFIG_FIT_IMAGE_TEE_PROCESS */
>> +
>>  #endif /* __IMAGE_H__ */
>> --
>> 2.10.1
>>
> 
> Regards,
> SImon
> 

^ permalink raw reply

* [PATCH] ti-ipc: update to include -pthread fixes
From: Denys Dmytriyenko @ 2016-11-14 21:55 UTC (permalink / raw)
  To: meta-ti

From: Denys Dmytriyenko <denys@ti.com>

Signed-off-by: Denys Dmytriyenko <denys@ti.com>
---
 recipes-ti/ipc/ti-ipc.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-ti/ipc/ti-ipc.inc b/recipes-ti/ipc/ti-ipc.inc
index 869dada..488e0fc 100644
--- a/recipes-ti/ipc/ti-ipc.inc
+++ b/recipes-ti/ipc/ti-ipc.inc
@@ -9,7 +9,7 @@ TI_IPC_GIT_PROTOCOL = "git"
 TI_IPC_GIT_BRANCH = "ipc-next"
 
 #Corresponds to 3.44.00.00
-TI_IPC_SRCREV = "e6f64d4b04f1c929366c922a2e5a4728fbb4d919"
+TI_IPC_SRCREV = "a1852fc8b254ed207bd1c1c88f5b362c9b6cc454"
 
 BRANCH = "${TI_IPC_GIT_BRANCH}"
 SRC_URI = "${TI_IPC_GIT_URI};protocol=${TI_IPC_GIT_PROTOCOL};branch=${BRANCH};name=ipcdev"
@@ -17,7 +17,7 @@ SRCREV = "${TI_IPC_SRCREV}"
 
 S = "${WORKDIR}/git"
 PV = "3.44.00.00"
-INC_PR = "r0"
+INC_PR = "r1"
 
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 
-- 
2.7.4



^ permalink raw reply related

* [Buildroot] [PATCH 1/3] boot/uboot: bump to version 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:55 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1479144385-27214-1-git-send-email-festevam@gmail.com>

Hello,

On Mon, 14 Nov 2016 15:26:23 -0200, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam <festevam@gmail.com>
> ---
>  boot/uboot/Config.in  | 4 ++--
>  boot/uboot/uboot.hash | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)

All three applied to next. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* [Buildroot] [autobuild.buildroot.net] Build results for 2016-11-13
From: Thomas Petazzoni @ 2016-11-14 21:54 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1479160383.4567.1.camel@embedded.rocks>

Hello,

On Mon, 14 Nov 2016 22:53:03 +0100, J?rg Krause wrote:

> > ?????????arm |???????????????????tremor-19427 | NOK |
> > http://autobuild.buildroot.net/results/054f1c77b0e5d46b2dc53769469c0e
> > d03e6b79ef  
> 
> The ARM Cortex-M4 toolchain supports *only* Thumb-2 instructions,
> whereas tremor has ARM assembly code and therefore cannot be build with
> this toolchain.
> 
> I would just exclude the relevant CPU ARMv7-M (BR2_ARM_CPU_ARMV7M) for
> simplicity, right?

Or, better, make tremor not use ARM-only instructions, by disabling the
optimized code. The benefit of this approach is that you don't have to
propagate the !BR2_ARM_CPU_ARMV7M dependency to the reverse
dependencies of tremor.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* qed, qedi patchset submission
From: Arun Easi @ 2016-11-14 21:53 UTC (permalink / raw)
  To: Martin K. Petersen, David Miller, linux-scsi, netdev

Hi Martin, David,

This is regarding the submission of the recent patch series we have posted
to linux-scsi and netdev:

    [PATCH v2 0/6] Add QLogic FastLinQ iSCSI (qedi) driver.
    [PATCH v2 1/6] qed: Add support for hardware offloaded iSCSI.
    [PATCH v2 2/6] qed: Add iSCSI out of order packet handling.
    [PATCH v2 3/6] qedi: Add QLogic FastLinQ offload iSCSI driver framework.
    [PATCH v2 4/6] qedi: Add LL2 iSCSI interface for offload iSCSI.
    [PATCH v2 5/6] qedi: Add support for iSCSI session management.
    [PATCH v2 6/6] qedi: Add support for data path.

Patches 1 & 2 are "qed" module patches that goes under
drivers/net/ethernet/qlogic/qed/ and include/linux/qed/ directory.
	- These are the iSCSI enablement changes to the common "qed"
	  module. There is no dependency for these patches and so
	  can go independently.

Patches 3, 4, 5 & 6 are the qedi patches that is aimed towards
drivers/scsi/qedi/ directory.
	- These are the core qedi changes and is dependent on the
	  qed changes (invokes qed_XXX functions).

As qed sits in the net tree, the patches are usually submitted via netdev.

Do you have any preference or thoughts on how the "qed" patches be 
approached? Just as a reference, our rdma driver "qedr" went through 
something similar[1], and eventually "qed" patches were taken by David 
in the net tree and "qedr", in the rdma tree (obviously) by Doug L.

Hi David,

For the "qed" enablement sent with the v2 series, we did not prefix the 
qed patches with "[PATCH net-next]" prefix, so netdev folks may have 
failed to notice/review that, sorry about that. We will send the next (v3) 
series with that corrected.

Right now, we are basing the "qed" patches on top of latest net + net-next 
tree. FYI, I tried a test merge of net-next/master + qed patches with 
"net/master" and I see no conflict in qed.

Regards,
-Arun

[1] http://marc.info/?l=linux-rdma&m=147509152719831&w=2

^ permalink raw reply

* [Buildroot] [git commit] package/gcc: backport xtensa trap pattern for 5.x
From: Thomas Petazzoni @ 2016-11-14 21:53 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=d3f0d52144f27097bba225bdb2a3b1620d44ab5a
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master

gcc 5.x uses trap pattern extensively to mark locations where program
execution should never get. Default pattern implementation emits a call
to 'abort' function. This function however is not always available, e.g.
it's not available for the libc dynamic linker. Backport implementation
of the trap pattern for xtensa that does not result in a call to
'abort'.

Fixes:
  http://autobuild.buildroot.net/results/0fbcc4475545904bf88f25a3bdf3ee552bf4960e
  http://autobuild.buildroot.net/results/cb7f5bdfac615d774f3bcd1b802f8d74460bc557
  http://autobuild.buildroot.net/results/cf3dc9ae4f74ff28b285f1a862b71d96384d7651

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 .../5.4.0/875-xtensa-implement-trap-pattern.patch  | 67 ++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch b/package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch
new file mode 100644
index 0000000..870b079
--- /dev/null
+++ b/package/gcc/5.4.0/875-xtensa-implement-trap-pattern.patch
@@ -0,0 +1,67 @@
+From 2b4b5775554c91a63ccae4ee566db696b633652e Mon Sep 17 00:00:00 2001
+From: jcmvbkbc <jcmvbkbc@138bc75d-0d04-0410-961f-82ee72b054a4>
+Date: Wed, 10 Jun 2015 15:07:40 +0000
+Subject: [PATCH] xtensa: implement trap pattern
+
+2015-06-10  Max Filippov  <jcmvbkbc@gmail.com>
+gcc/
+	* config/xtensa/xtensa.h (TARGET_DEBUG): New definition.
+	* config/xtensa/xtensa.md (define_attr "type"): New type "trap".
+	(define_insn "trap"): New definition.
+
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+
+git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk at 224330 138bc75d-0d04-0410-961f-82ee72b054a4
+---
+ gcc/config/xtensa/xtensa.h  |  1 +
+ gcc/config/xtensa/xtensa.md | 15 ++++++++++++++-
+ 2 files changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/gcc/config/xtensa/xtensa.h b/gcc/config/xtensa/xtensa.h
+index 615f741..fb8702c 100644
+--- a/gcc/config/xtensa/xtensa.h
++++ b/gcc/config/xtensa/xtensa.h
+@@ -67,6 +67,7 @@ extern unsigned xtensa_current_frame_size;
+ #define TARGET_THREADPTR	XCHAL_HAVE_THREADPTR
+ #define TARGET_LOOPS	        XCHAL_HAVE_LOOPS
+ #define TARGET_WINDOWED_ABI	(XSHAL_ABI == XTHAL_ABI_WINDOWED)
++#define TARGET_DEBUG		XCHAL_HAVE_DEBUG
+ 
+ #define TARGET_DEFAULT \
+   ((XCHAL_HAVE_L32R	? 0 : MASK_CONST16) |				\
+diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
+index 6d84384..a577aa3 100644
+--- a/gcc/config/xtensa/xtensa.md
++++ b/gcc/config/xtensa/xtensa.md
+@@ -86,7 +86,7 @@
+ ;; Attributes.
+ 
+ (define_attr "type"
+-  "unknown,jump,call,load,store,move,arith,multi,nop,farith,fmadd,fconv,fload,fstore,mul16,mul32,div32,mac16,rsr,wsr,entry"
++  "unknown,jump,call,load,store,move,arith,multi,nop,farith,fmadd,fconv,fload,fstore,mul16,mul32,div32,mac16,rsr,wsr,entry,trap"
+   (const_string "unknown"))
+ 
+ (define_attr "mode"
+@@ -1764,6 +1764,19 @@
+   [(set_attr "length" "0")
+    (set_attr "type" "nop")])
+ 
++(define_insn "trap"
++  [(trap_if (const_int 1) (const_int 0))]
++  ""
++{
++  if (TARGET_DEBUG)
++    return "break\t1, 15";
++  else
++    return (TARGET_DENSITY ? "ill.n" : "ill");
++}
++  [(set_attr "type"	"trap")
++   (set_attr "mode"	"none")
++   (set_attr "length"	"3")])
++
+ ;; Setting up a frame pointer is tricky for Xtensa because GCC doesn't
+ ;; know if a frame pointer is required until the reload pass, and
+ ;; because there may be an incoming argument value in the hard frame
+-- 
+2.1.4
+

^ permalink raw reply related

* [Buildroot] [autobuild.buildroot.net] Build results for 2016-11-13
From: Jörg Krause @ 2016-11-14 21:53 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <20161114073015.24C9A20BE0@mail.free-electrons.com>

On Mon, 2016-11-14 at 08:30 +0100, Thomas Petazzoni wrote:
> Hello,
> 
> Build statistics for 2016-11-13
> ================================
> 
> ??????successes : 220
> ???????failures : 52?
> ???????timeouts : 0??
> ??????????TOTAL : 272
> 

[snip]

> ?????????arm |???????????????????tremor-19427 | NOK |
> http://autobuild.buildroot.net/results/054f1c77b0e5d46b2dc53769469c0e
> d03e6b79ef

The ARM Cortex-M4 toolchain supports *only* Thumb-2 instructions,
whereas tremor has ARM assembly code and therefore cannot be build with
this toolchain.

I would just exclude the relevant CPU ARMv7-M (BR2_ARM_CPU_ARMV7M) for
simplicity, right?

Best regards,
J?rg Krause

^ permalink raw reply

* Re: [PATCH v2 04/12] PCI: iproc: Fix exception with multi-function devices
From: Bjorn Helgaas @ 2016-11-14 21:52 UTC (permalink / raw)
  To: Ray Jui
  Cc: Bjorn Helgaas, linux-kernel, bcm-kernel-feedback-list, linux-pci,
	Alex Barba, Oza Oza
In-Reply-To: <1477960721-17649-5-git-send-email-ray.jui@broadcom.com>

On Mon, Oct 31, 2016 at 05:38:33PM -0700, Ray Jui wrote:
> During enumeration with multi-function EP devices, access to the
> configuration space of a non-exist function results in an unsupported
> request being returned as expected. By default the PAXB based iProc
> PCIe controller forwards this as an APB error to the host system and
> that causes an exception, which is undesired
> 
> This patch disables this undesired behaviour and lets the kernel PCI
> stack deals with an access to the non-exist function, in which case
> a vendor ID of 0xffff is returned and handled gracefully
> 
> Reported-by: JD Zheng <jiandong.zheng@broadcom.com>
> Signed-off-by: Ray Jui <ray.jui@broadcom.com>
> Reviewed-by: JD Zheng <jiandong.zheng@broadcom.com>
> Reviewed-by: Oza Oza <oza.oza@broadcom.com>
> Reviewed-by: Scott Branden <scott.branden@broadcom.com>
> ---
>  drivers/pci/host/pcie-iproc.c | 58 +++++++++++++++++++++++++++++++++++++++++--
>  drivers/pci/host/pcie-iproc.h |  3 +++
>  2 files changed, 59 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
> index f3b3340..07ec478 100644
> --- a/drivers/pci/host/pcie-iproc.c
> +++ b/drivers/pci/host/pcie-iproc.c
> @@ -58,6 +58,9 @@
>  #define PCIE_DL_ACTIVE_SHIFT         2
>  #define PCIE_DL_ACTIVE               BIT(PCIE_DL_ACTIVE_SHIFT)
>  
> +#define APB_ERR_EN_SHIFT             0
> +#define APB_ERR_EN                   BIT(APB_ERR_EN_SHIFT)
> +
>  #define OARR_VALID_SHIFT             0
>  #define OARR_VALID                   BIT(OARR_VALID_SHIFT)
>  #define OARR_SIZE_CFG_SHIFT          1
> @@ -96,6 +99,9 @@ enum iproc_pcie_reg {
>  	/* link status */
>  	IPROC_PCIE_LINK_STATUS,
>  
> +	/* enable APB error for unsupported requests */
> +	IPROC_PCIE_APB_ERR_EN,
> +
>  	/* total number of core registers */
>  	IPROC_PCIE_MAX_NUM_REG,
>  };
> @@ -124,6 +130,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
>  	[IPROC_PCIE_OMAP_LO]      = 0xd40,
>  	[IPROC_PCIE_OMAP_HI]      = 0xd44,
>  	[IPROC_PCIE_LINK_STATUS]  = 0xf0c,
> +	[IPROC_PCIE_APB_ERR_EN]   = 0xf40,
>  };
>  
>  /* iProc PCIe PAXC v1 registers */
> @@ -181,6 +188,28 @@ static inline void iproc_pcie_write_reg(struct iproc_pcie *pcie,
>  	writel(val, pcie->base + offset);
>  }
>  
> +/**
> + * APB error forwarding can be disabled during access of configuration
> + * registers of the endpoint device, to prevent unsupported requests
> + * (typically seen during enumeration with multi-function devices) from
> + * triggering a system exception
> + */
> +static inline void iproc_pcie_apb_err_disable(struct pci_bus *bus,
> +					      bool disable)
> +{
> +	struct iproc_pcie *pcie = iproc_data(bus);
> +	u32 val;
> +
> +	if (bus->number && pcie->has_apb_err_disable) {
> +		val = iproc_pcie_read_reg(pcie, IPROC_PCIE_APB_ERR_EN);
> +		if (disable)
> +			val &= ~APB_ERR_EN;
> +		else
> +			val |= APB_ERR_EN;
> +		iproc_pcie_write_reg(pcie, IPROC_PCIE_APB_ERR_EN, val);
> +	}
> +}
> +
>  static inline void iproc_pcie_ob_write(struct iproc_pcie *pcie,
>  				       enum iproc_pcie_reg reg,
>  				       unsigned window, u32 val)
> @@ -244,10 +273,34 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct pci_bus *bus,
>  		return (pcie->base + offset);
>  }
>  
> +static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
> +				    int where, int size, u32 *val)
> +{
> +	int ret;
> +
> +	iproc_pcie_apb_err_disable(bus, true);
> +	ret = pci_generic_config_read32(bus, devfn, where, size, val);
> +	iproc_pcie_apb_err_disable(bus, false);

I guess this means that any other APB errors (unrelated to this config
access, e.g., a driver doing MMIo to a device at the same time the user is
doing "lspci") that happen to occur during this window will also be
ignored.

> +
> +	return ret;
> +}
> +
> +static int iproc_pcie_config_write32(struct pci_bus *bus, unsigned int devfn,
> +				     int where, int size, u32 val)
> +{
> +	int ret;
> +
> +	iproc_pcie_apb_err_disable(bus, true);
> +	ret = pci_generic_config_write32(bus, devfn, where, size, val);
> +	iproc_pcie_apb_err_disable(bus, false);
> +
> +	return ret;
> +}
> +
>  static struct pci_ops iproc_pcie_ops = {
>  	.map_bus = iproc_pcie_map_cfg_bus,
> -	.read = pci_generic_config_read32,
> -	.write = pci_generic_config_write32,
> +	.read = iproc_pcie_config_read32,
> +	.write = iproc_pcie_config_write32,
>  };
>  
>  static void iproc_pcie_reset(struct iproc_pcie *pcie)
> @@ -485,6 +538,7 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
>  		break;
>  	case IPROC_PCIE_PAXB:
>  		regs = iproc_pcie_reg_paxb;
> +		pcie->has_apb_err_disable = true;
>  		break;
>  	case IPROC_PCIE_PAXC:
>  		regs = iproc_pcie_reg_paxc;
> diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
> index 768be05..711dd3a 100644
> --- a/drivers/pci/host/pcie-iproc.h
> +++ b/drivers/pci/host/pcie-iproc.h
> @@ -57,6 +57,8 @@ struct iproc_msi;
>   * @phy: optional PHY device that controls the Serdes
>   * @map_irq: function callback to map interrupts
>   * @ep_is_internal: indicates an internal emulated endpoint device is connected
> + * @has_apb_err_disable: indicates the controller can be configured to prevent
> + * unsupported request from being forwarded as an APB bus error
>   * @need_ob_cfg: indicates SW needs to configure the outbound mapping window
>   * @ob: outbound mapping parameters
>   * @msi: MSI data
> @@ -74,6 +76,7 @@ struct iproc_pcie {
>  	struct phy *phy;
>  	int (*map_irq)(const struct pci_dev *, u8, u8);
>  	bool ep_is_internal;
> +	bool has_apb_err_disable;
>  	bool need_ob_cfg;
>  	struct iproc_pcie_ob ob;
>  	struct iproc_msi *msi;
> -- 
> 2.1.4
> 

^ permalink raw reply

* [Buildroot] [git commit branch/next] configs/warp7: Bump to U-Boot 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:52 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=87f1bdda38b43192908dab585dc6b4fc3e39ffe5
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 configs/warp7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index a55a504..fca7a1d 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -25,7 +25,7 @@ BR2_LINUX_KERNEL_INTREE_DTS_NAME="imx7s-warp"
 BR2_TARGET_UBOOT=y
 BR2_TARGET_UBOOT_BOARDNAME="warp7_secure"
 BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.09.01"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.11"
 BR2_TARGET_UBOOT_FORMAT_IMX=y
 
 # wifi firmware for brcm43430

^ permalink raw reply related

* [Buildroot] [git commit branch/next] uboot-tools: bump to version 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:52 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=99fd3bae35f9971544990c1869933b8ae22832ec
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 package/uboot-tools/uboot-tools.hash | 2 +-
 package/uboot-tools/uboot-tools.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/uboot-tools/uboot-tools.hash b/package/uboot-tools/uboot-tools.hash
index db60dab..5b2c3bf 100644
--- a/package/uboot-tools/uboot-tools.hash
+++ b/package/uboot-tools/uboot-tools.hash
@@ -1,2 +1,2 @@
 # Locally computed:
-sha256  95728e89dd476d17428f94080752ab48884be477b6a678941582aeef618b70bb  u-boot-2016.09.01.tar.bz2
+sha256  45813e6565dcc0436abe6752624324cdbf5f3ac106570d76d32b46ec529bcdc8  u-boot-2016.11.tar.bz2
diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk
index a3335a5..bb0cba8 100644
--- a/package/uboot-tools/uboot-tools.mk
+++ b/package/uboot-tools/uboot-tools.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-UBOOT_TOOLS_VERSION = 2016.09.01
+UBOOT_TOOLS_VERSION = 2016.11
 UBOOT_TOOLS_SOURCE = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2
 UBOOT_TOOLS_SITE = ftp://ftp.denx.de/pub/u-boot
 UBOOT_TOOLS_LICENSE = GPLv2+

^ permalink raw reply related

* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Julia Lawall @ 2016-11-14 21:52 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <20161114214037.GE9868@bhelgaas-glaptop.roam.corp.google.com>



On Mon, 14 Nov 2016, Bjorn Helgaas wrote:

> On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> > Use DEVICE_ATTR_RW for read-write attributes.  This simplifies the
> > source code, improves readbility, and reduces the chance of
> > inconsistencies.
> >
> > The semantic patch that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @rw@
> > declarer name DEVICE_ATTR;
> > identifier x,x_show,x_store;
> > @@
> >
> > DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> >
> > @script:ocaml@
> > x << rw.x;
> > x_show << rw.x_show;
> > x_store << rw.x_store;
> > @@
> >
> > if not (x^"_show" = x_show && x^"_store" = x_store)
> > then Coccilib.include_match false
> >
> > @@
> > declarer name DEVICE_ATTR_RW;
> > identifier rw.x,rw.x_show,rw.x_store;
> > @@
> >
> > - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> > + DEVICE_ATTR_RW(x);
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> I applied this to pci/aspm to follow the herd, although it looks
> pretty similar to the ill-fated "Replace numeric parameter like 0444
> with macro" series (http://lwn.net/Articles/696229/).  Maybe this is
> different because everybody except me knows what ATTR_RW means?  To
> me, "0644" contained more information than "_RW" does.
>
> I do certainly like the removal of the "_show" and "_store"
> redundancy.

I think that the point is the latter.  There were also a couple of cases
where the permissions didn't match with the set of provided functions.

julia

>
> > ---
> >  drivers/pci/pcie/aspm.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index 0ec649d..3b14d9e 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> >  	return n;
> >  }
> >
> > -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> > -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> > +static DEVICE_ATTR_RW(link_state);
> > +static DEVICE_ATTR_RW(clk_ctl);
> >
> >  static char power_group[] = "power";
> >  void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
> >
>

^ permalink raw reply

* Re: [PATCH 13/15] PCI/ASPM: use permission-specific DEVICE_ATTR variants
From: Julia Lawall @ 2016-11-14 21:52 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: Bjorn Helgaas, kernel-janitors, linux-pci, linux-kernel
In-Reply-To: <20161114214037.GE9868@bhelgaas-glaptop.roam.corp.google.com>



On Mon, 14 Nov 2016, Bjorn Helgaas wrote:

> On Sat, Oct 29, 2016 at 09:37:07PM +0200, Julia Lawall wrote:
> > Use DEVICE_ATTR_RW for read-write attributes.  This simplifies the
> > source code, improves readbility, and reduces the chance of
> > inconsistencies.
> >
> > The semantic patch that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > // <smpl>
> > @rw@
> > declarer name DEVICE_ATTR;
> > identifier x,x_show,x_store;
> > @@
> >
> > DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> >
> > @script:ocaml@
> > x << rw.x;
> > x_show << rw.x_show;
> > x_store << rw.x_store;
> > @@
> >
> > if not (x^"_show" = x_show && x^"_store" = x_store)
> > then Coccilib.include_match false
> >
> > @@
> > declarer name DEVICE_ATTR_RW;
> > identifier rw.x,rw.x_show,rw.x_store;
> > @@
> >
> > - DEVICE_ATTR(x, \(0644\|S_IRUGO|S_IWUSR\), x_show, x_store);
> > + DEVICE_ATTR_RW(x);
> > // </smpl>
> >
> > Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> I applied this to pci/aspm to follow the herd, although it looks
> pretty similar to the ill-fated "Replace numeric parameter like 0444
> with macro" series (http://lwn.net/Articles/696229/).  Maybe this is
> different because everybody except me knows what ATTR_RW means?  To
> me, "0644" contained more information than "_RW" does.
>
> I do certainly like the removal of the "_show" and "_store"
> redundancy.

I think that the point is the latter.  There were also a couple of cases
where the permissions didn't match with the set of provided functions.

julia

>
> > ---
> >  drivers/pci/pcie/aspm.c |    4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index 0ec649d..3b14d9e 100644
> > --- a/drivers/pci/pcie/aspm.c
> > +++ b/drivers/pci/pcie/aspm.c
> > @@ -886,8 +886,8 @@ static ssize_t clk_ctl_store(struct device *dev,
> >  	return n;
> >  }
> >
> > -static DEVICE_ATTR(link_state, 0644, link_state_show, link_state_store);
> > -static DEVICE_ATTR(clk_ctl, 0644, clk_ctl_show, clk_ctl_store);
> > +static DEVICE_ATTR_RW(link_state);
> > +static DEVICE_ATTR_RW(clk_ctl);
> >
> >  static char power_group[] = "power";
> >  void pcie_aspm_create_sysfs_dev_files(struct pci_dev *pdev)
> >
>

^ permalink raw reply

* [Buildroot] [git commit branch/next] boot/uboot: bump to version 2016.11
From: Thomas Petazzoni @ 2016-11-14 21:52 UTC (permalink / raw)
  To: buildroot

commit: https://git.buildroot.net/buildroot/commit/?id=ce7b0b8dfba9832169d80916b9adf83ef27dbb04
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next

Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 boot/uboot/Config.in  | 4 ++--
 boot/uboot/uboot.hash | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/boot/uboot/Config.in b/boot/uboot/Config.in
index fabf27d..3b4bfac 100644
--- a/boot/uboot/Config.in
+++ b/boot/uboot/Config.in
@@ -38,7 +38,7 @@ choice
 	  Select the specific U-Boot version you want to use
 
 config BR2_TARGET_UBOOT_LATEST_VERSION
-	bool "2016.09.01"
+	bool "2016.11"
 
 config BR2_TARGET_UBOOT_CUSTOM_VERSION
 	bool "Custom version"
@@ -86,7 +86,7 @@ endif
 
 config BR2_TARGET_UBOOT_VERSION
 	string
-	default "2016.09.01"	if BR2_TARGET_UBOOT_LATEST_VERSION
+	default "2016.11"	if BR2_TARGET_UBOOT_LATEST_VERSION
 	default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE \
 		if BR2_TARGET_UBOOT_CUSTOM_VERSION
 	default "custom"	if BR2_TARGET_UBOOT_CUSTOM_TARBALL
diff --git a/boot/uboot/uboot.hash b/boot/uboot/uboot.hash
index db60dab..5b2c3bf 100644
--- a/boot/uboot/uboot.hash
+++ b/boot/uboot/uboot.hash
@@ -1,2 +1,2 @@
 # Locally computed:
-sha256  95728e89dd476d17428f94080752ab48884be477b6a678941582aeef618b70bb  u-boot-2016.09.01.tar.bz2
+sha256  45813e6565dcc0436abe6752624324cdbf5f3ac106570d76d32b46ec529bcdc8  u-boot-2016.11.tar.bz2

^ permalink raw reply related

* [PATCH v2 1/2] drm/dp/i915: Fix DP link rate math
From: Dhinakaran Pandiyan @ 2016-11-14 21:50 UTC (permalink / raw)
  To: intel-gfx; +Cc: jani.nikula, Dhinakaran Pandiyan
In-Reply-To: <1479159735-29364-1-git-send-email-dhinakaran.pandiyan@intel.com>

We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec. are expressed in
Gbps/lane, which seems to have led to some confusion.

E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 2160000 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion

Using link clock frequency, like we do
Max. data rate = 540000 kHz * 4 lanes = 2160000 kSymbols/s
Because, each symbol has 8 bit of data, this is 2160000 kBps
and there is no need to account for channel encoding here.

But, currently we do 540000 kHz * 4 lanes * (8/10) = 1728000 kBps

Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * (bpp/8) to give the final result in
kBps

v2: Changed to DIV_ROUND_UP() and comment changes (Ville)

Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
---
Fixed a typo that snuck in.

 drivers/gpu/drm/i915/intel_dp.c | 35 +++++++++++++++--------------------
 1 file changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..bdef314 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp *intel_dp)
 	return min(source_max, sink_max);
 }
 
-/*
- * The units on the numbers in the next two are... bizarre.  Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- *     270000 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits.  ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000.  At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
 static int
 intel_dp_link_required(int pixel_clock, int bpp)
 {
-	return (pixel_clock * bpp + 9) / 10;
+	/* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
+	return DIV_ROUND_UP(pixel_clock * bpp, 8);
 }
 
 static int
 intel_dp_max_data_rate(int max_link_clock, int max_lanes)
 {
-	return (max_link_clock * max_lanes * 8) / 10;
+	/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+	 * link rate that is generally expressed in Gbps. Since, 8 bits of data
+	 * is transmitted every LS_Clk per lane, there is no need to account for
+	 * the channel encoding that is done in the PHY layer here.
+	 */
+
+	return max_link_clock * max_lanes;
 }
 
 static int
@@ -3573,7 +3563,12 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
 			if (val == 0)
 				break;
 
-			/* Value read is in kHz while drm clock is saved in deca-kHz */
+			/* Value read multiplied by 200kHz gives the per-lane
+			 * link rate in kHz. The source rates are, however,
+			 * stored in terms of LS_Clk kHz. The full conversion
+			 * back to symbols is
+			 * (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
+			 */
 			intel_dp->sink_rates[i] = (val * 200) / 10;
 		}
 		intel_dp->num_sink_rates = i;
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply related


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.