Re: [PATCH] usb: phy: samsung: Add support for USB 3.0 phy for exynos5250

[Felipe Balbi]

Hi,

On Wed, Dec 19, 2012 at 11:52:01AM +0530, Vivek Gautam wrote:
> >>> @@ -736,7 +1035,41 @@ static int __devinit samsung_usbphy_probe(struct 
> >>> platform_device *pdev)
> >>>
> >>>   sphy->clk = clk;
> >>>
> >>> - return usb_add_phy(&sphy->phy, USB_PHY_TYPE_USB2);
> >>> + sphy->has_usb3 = (sphy->cpu_type == TYPE_EXYNOS5250);
> >>> +
> >>> + if (sphy->has_usb3) {
> >>> + struct resource *usb3phy_mem;
> >>> + void __iomem*usb3phy_base;
> >>> +
> >>> + usb3phy_mem = platform_get_resource(pdev, IORESOURCE_MEM, 
> >>> 1);
> >>> + if (!usb3phy_mem) {
> >>> + dev_err(dev, "%s: missing mem resource\n", 
> >>> __func__);
> >>> + return -ENODEV;
> >>> + }
> >>> +
> >>> + usb3phy_base = devm_request_and_ioremap(dev, usb3phy_mem);
> >>> + if (!usb3phy_base) {
> >>> + dev_err(dev, "%s: register mapping failed\n", 
> >>> __func__);
> >>> + return -ENXIO;
> >>> + }
> >>> +
> >>> + sphy->usb3phy.regs_phy  = usb3phy_base;
> >>> + sphy->usb3phy.phy.dev   = sphy->dev;
> >>> + sphy->usb3phy.phy.label = "samsung-usb3phy";
> >>> + sphy->usb3phy.phy.init  = samsung_usb3phy_init;
> >>> + sphy->usb3phy.phy.shutdown  = samsung_usb3phy_shutdown;
> >>> + }
> >>> +
> >>> + ret = usb_add_phy(&sphy->phy, USB_PHY_TYPE_USB2);
> >>> + if (ret)
> >>> + return ret;
> >>
> >> is this realy how your HW behaves ? USB2 and USB3 phys are a single HW
> >> entity ? I kinda doubt that :-s
> >>
> 
> They are separate HW in fact.
> So, do you expect to see a separate driver interface for USB 3.0 type phy ?

yes. Just as we did on OMAP. One driver for the USB2 part and one driver
for USB3 part (which are actually two, but you can only talk to them as
one) :-)

> That will be quite similar architecturally to current samsung-usbphy
> driver for USB 2.0 type phy,
> and may require some code duplication too.

If it duplicates code, then perhaps it's best to keep it as is but I'm
actually surprised you guys have similar programming model on both
parts. I mean, the differences at HW behavior are huge: on one side you
use ULPI/UTMI+ on the other PIPE3, on one side you have 480Mbps
half-duplex signalling, on the other you have 5Gbps dual simplex
signalling, the differences go on and on.

Also, what you say about duplicating, it seems to me that it will
duplicate only the boylerplate part (allocating memory, having a
platform_driver, and so on), because you _do_ have completely separate
functions to handle usb3 part.

One more comment below:

> +static u32 exynos5_usb3phy_set_clock(struct samsung_usbphy *sphy)
> +{
> + u32 reg;
> + u32 refclk;
> +
> + refclk = sphy->ref_clk_freq;
> +
> + reg = PHYCLKRST_REFCLKSEL_EXT_REFCLK |
> + PHYCLKRST_FSEL(refclk);
> +
> + switch (refclk) {
> + case HOST_CTRL0_FSEL_CLKSEL_50M:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case HOST_CTRL0_FSEL_CLKSEL_20M:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x00));
> + break;
> + case HOST_CTRL0_FSEL_CLKSEL_19200K:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + case HOST_CTRL0_FSEL_CLKSEL_24M:
> + default:
> + reg |= (PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF |
> + PHYCLKRST_SSC_REFCLKSEL(0x88));
> + break;
> + }
> +
> + return reg;
> +}

looks like this should be done by commong clock framework by clock
reparenting perhaps ?

-- 
balbi


signature.asc
Description: Digital signature

[PATCH v4 0/6] Add movablecore_map boot option with SRAT support.

[Tang Chen]

[What we are doing]
This patchset provide a boot option for user to specify ZONE_MOVABLE memory
map for each node in the system.

movablecore_map=nn[KMG]@ss[KMG] or movablecore_map=acpi

movablecore_map=nn[KMG]@ss[KMG]:
This option makes sure memory range from ss to ss+nn is movable memory.

movablecore_map=acpi:
This option informs the kernel to use Hot Pluggable bit in SRAT from ACPI BIOS
to determine which memory device could be hotplugged. Users don't need to
take part in.


[Why we do this]
If we hot remove a memroy, the memory cannot have kernel memory,
because Linux cannot migrate kernel memory currently. Therefore,
we have to guarantee that the hot removed memory has only movable
memory.

Linux has two boot options, kernelcore= and movablecore=, for
creating movable memory. These boot options can specify the amount
of memory use as kernel or movable memory. Using them, we can
create ZONE_MOVABLE which has only movable memory.

But it does not fulfill a requirement of memory hot remove, because
even if we specify the boot options, movable memory is distributed
in each node evenly. So when we want to hot remove memory which
memory range is 0x8000-0c000, we have no way to specify
the memory as movable memory.

So we proposed a new feature which specifies memory range to use as
movable memory.


[Ways to do this]
There may be 2 ways to specify movable memory.
 1. use firmware information
 2. use boot option

1. use firmware information
  According to ACPI spec 5.0, SRAT table has memory affinity structure
  and the structure has Hot Pluggable Filed. See "5.2.16.2 Memory
  Affinity Structure". If we use the information, we might be able to
  specify movable memory by firmware. For example, if Hot Pluggable
  Filed is enabled, Linux sets the memory as movable memory.

2. use boot option
  This is our proposal. New boot option can specify memory range to use
  as movable memory.


[How we do this]
We chose second way at first, because if we use first way, users cannot change
memory range to use as movable memory easily. We think if we create
movable memory, performance regression may occur by NUMA. In this case,
user can turn off the feature easily if we prepare the boot option.
And if we prepare the boot optino, the user can select which memory
to use as movable memory easily.

And from v4, we also support the first way, using Hot Pluggable bit.


[How to use]
Specify the following boot option:
movablecore_map=nn[KMG]@ss[KMG] or movablecore_map=acpi.

1. If user want to specify hotpluggable memory ranges by himself, then specify
   as the following:
movablecore_map=nn[KMG]@ss[KMG]
   In this way, the kernel will check if the ranges are hotpluggable with info
   from SRAT from ACPI BIOS.
   - If a range is hotpluggable, then from ss to the end of the corresponding
 node will be ZONE_MOVABLE.
   - If a range is not hotpluggable, then the range will be ignored.

2. If user want to leave the configuration work to the kernel, then specify
   as the following:
movablecore_map=acpi
   In this way, the kernel will get hotplug info from SRAT in ACPI BIOS, and
   auto decide which memory devices could be hotplugged. And all the memory
   on these devices will be in ZONE_MOVABLE.

3. If user didn't specify this option, then the kernel will use all the
   memory on all the nodes evenly. And there is no performance drawback.

And the following points should be considered.

1) If the range is involved in a single node, then from ss to the end of
   the node will be ZONE_MOVABLE.
2) If the range covers two or more nodes, then from ss to the end of
   the 1st node will be ZONE_MOVABLE, and all the other nodes will only
   have ZONE_MOVABLE.
3) If no range is in the node, then the node will have no ZONE_MOVABLE
   unless kernelcore or movablecore is specified.
4) This option could be specified at most MAX_NUMNODES times.
5) If kernelcore or movablecore is also specified, movablecore_map will have
   higher priority to be satisfied.
6) This option has no conflict with memmap option.


Change log:

v3 -> v4:
1) patch2: Add new function remove_movablecore_map() to remove a range from
   movablecore_map.map[].
2) patch2: Add movablecore_map=acpi logic to allow user to skip the physical
   address config. If this option is specified, movablecore_map.map[]
   will be clear at first, and add all the hotpluggable memory ranges
   into it when parsing SRAT.
3) patch3: New patch, add logic to check the Hot Pluggable bit when parsing 
SRAT.
   If user also specifies a memory range, the logic will check if it is
   hotpluggable and remove it from movablecore_map.map[] if not.

v2 -> v3:
1) Use memblock_alloc_try_nid() instead of memblock_alloc_nid() to allocate
   memory twice if a whole node is ZONE_MOVABLE.
2) Add DMA, DMA32 addresses check, make sure ZONE_MOVABLE won't use these 
addresses.
   Suggested by Wu Jianguo 
3) Add lowmem addresses check, when t

[PATCH v4 1/6] x86: get pg_data_t's memory from other node

[Tang Chen]

From: Yasuaki Ishimatsu 

If system can create movable node which all memory of the
node is allocated as ZONE_MOVABLE, setup_node_data() cannot
allocate memory for the node's pg_data_t.
So, use memblock_alloc_try_nid() instead of memblock_alloc_nid()
to retry when the first allocation fails.

Signed-off-by: Yasuaki Ishimatsu 
Signed-off-by: Lai Jiangshan 
Signed-off-by: Tang Chen 
Signed-off-by: Jiang Liu 
---
 arch/x86/mm/numa.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index 2d125be..db939b6 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -222,10 +222,9 @@ static void __init setup_node_data(int nid, u64 start, u64 
end)
nd_pa = __pa(nd);
remapped = true;
} else {
-   nd_pa = memblock_alloc_nid(nd_size, SMP_CACHE_BYTES, nid);
+   nd_pa = memblock_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
if (!nd_pa) {
-   pr_err("Cannot find %zu bytes in node %d\n",
-  nd_size, nid);
+   pr_err("Cannot find %zu bytes in any node\n", nd_size);
return;
}
nd = __va(nd_pa);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 5/6] page_alloc: Make movablecore_map has higher priority

[Tang Chen]

If kernelcore or movablecore is specified at the same time
with movablecore_map, movablecore_map will have higher
priority to be satisfied.
This patch will make find_zone_movable_pfns_for_nodes()
calculate zone_movable_pfn[] with the limit from
zone_movable_limit[].

Signed-off-by: Tang Chen 
Reviewed-by: Wen Congyang 
Reviewed-by: Lai Jiangshan 
Reviewed-by: Wu Jianguo 
Tested-by: Lin Feng 
---
 mm/page_alloc.c |   28 +---
 1 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 128d28a..6ab1ffe 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4917,9 +4917,17 @@ static void __init find_zone_movable_pfns_for_nodes(void)
required_kernelcore = max(required_kernelcore, corepages);
}
 
-   /* If kernelcore was not specified, there is no ZONE_MOVABLE */
-   if (!required_kernelcore)
+   /*
+* If neither kernelcore/movablecore nor movablecore_map is specified,
+* there is no ZONE_MOVABLE. But if movablecore_map is specified, the
+* start pfn of ZONE_MOVABLE has been stored in zone_movable_limit[].
+*/
+   if (!required_kernelcore) {
+   if (movablecore_map.nr_map)
+   memcpy(zone_movable_pfn, zone_movable_limit,
+   sizeof(zone_movable_pfn));
goto out;
+   }
 
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
@@ -4949,10 +4957,24 @@ restart:
for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
unsigned long size_pages;
 
+   /*
+* Find more memory for kernelcore in
+* [zone_movable_pfn[nid], zone_movable_limit[nid]).
+*/
start_pfn = max(start_pfn, zone_movable_pfn[nid]);
if (start_pfn >= end_pfn)
continue;
 
+   if (zone_movable_limit[nid]) {
+   end_pfn = min(end_pfn, zone_movable_limit[nid]);
+   /* No range left for kernelcore in this node */
+   if (start_pfn >= end_pfn) {
+   zone_movable_pfn[nid] =
+   zone_movable_limit[nid];
+   break;
+   }
+   }
+
/* Account for what is only usable for kernelcore */
if (start_pfn < usable_startpfn) {
unsigned long kernel_pages;
@@ -5012,12 +5034,12 @@ restart:
if (usable_nodes && required_kernelcore > usable_nodes)
goto restart;
 
+out:
/* Align start of ZONE_MOVABLE on all nids to MAX_ORDER_NR_PAGES */
for (nid = 0; nid < MAX_NUMNODES; nid++)
zone_movable_pfn[nid] =
roundup(zone_movable_pfn[nid], MAX_ORDER_NR_PAGES);
 
-out:
/* restore the node_state */
node_states[N_MEMORY] = saved_node_state;
 }
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT.

[Tang Chen]

The Hot Plugable bit in SRAT flags specifys if the memory range
could be hotplugged.

If user specified movablecore_map=nn[KMG]@ss[KMG], reset
movablecore_map.map to the intersection of hotpluggable ranges from
SRAT and old movablecore_map.map.
Else if user specified movablecore_map=acpi, just use the hotpluggable
ranges from SRAT.
Otherwise, do nothing. The kernel will use all the memory in all nodes
evenly.

The idea "getting info from SRAT" was from Liu Jiang .
And the idea "do more limit for memblock" was from Wu Jianguo 


Signed-off-by: Tang Chen 
Tested-by: Gu Zheng 
---
 arch/x86/mm/srat.c |   38 +++---
 1 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 4ddf497..947a2b5 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -146,7 +146,12 @@ int __init
 acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
 {
u64 start, end;
+   u32 hotpluggable;
int node, pxm;
+#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+   int overlap;
+   unsigned long start_pfn, end_pfn;
+#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
if (srat_disabled())
return -1;
@@ -157,8 +162,10 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
return -1;
 
-   if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info())
+   hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
+   if (hotpluggable && !save_add_info())
return -1;
+
start = ma->base_address;
end = start + ma->length;
pxm = ma->proximity_domain;
@@ -178,9 +185,34 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
 
node_set(node, numa_nodes_parsed);
 
-   printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+   printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx] %s\n",
   node, pxm,
-  (unsigned long long) start, (unsigned long long) end - 1);
+  (unsigned long long) start, (unsigned long long) end - 1,
+  hotpluggable ? "Hot Pluggable": "");
+
+#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+   start_pfn = PFN_DOWN(start);
+   end_pfn = PFN_UP(end);
+
+   if (!hotpluggable) {
+   /* Clear the range overlapped in movablecore_map.map */
+   remove_movablecore_map(start_pfn, end_pfn);
+   goto out;
+   }
+
+   /* If not using SRAT, don't modify user configuration. */
+   if (!movablecore_map.acpi)
+   goto out;
+
+   /* If user chose to use SRAT info, insert the range anyway. */
+   if (insert_movablecore_map(start_pfn, end_pfn))
+   pr_err("movablecore_map: too many entries;"
+   " ignoring [mem %#010llx-%#010llx]\n",
+   (unsigned long long) start,
+   (unsigned long long) (end - 1));
+
+out:
+#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
return 0;
 }
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/6] page_alloc: add movablecore_map kernel parameter

[Tang Chen]

[What are we doing]
This patch adds a new kernel boot option named movablecore_map to allow
user to specify the range of ZONE_MOVABLE of each node.


[Why do we do this]
The memory used by kernel, such as direct mapping pages, could not be
migrated. As a result, the corresponding memory device could not be
hotplugged. So in order to implement a whole node hotplug feature, we
need to limit the node to only contain movable memory (ZONE_MOVABLE).

This option provide 3 ways to control which memory could be hotplugged.
1. User could specify one or more physical address ranges to inform kernel
   these ranges should be in ZONE_MOVABLE.
   (using movablecore_map=nn[KMG]@ss[KMG])

2. Using the Hot Pluggable bit in flags from SRAT from BIOS, user could just
   leave the configuration work to the kernel.
   (using movablecore_map=acpi)

3. Users with feature known as "hardware memory migration" could migrate
   kernel pages transparently to OS, and these users may just don't use it.

NOTE: We do not use node ids because they could change on each boot.


[How to use]
The option can be used as following:

1. If user want to specify hotpluggable memory ranges by himself, then specify
   as the following:
movablecore_map=nn[KMG]@ss[KMG]
   In this way, the kernel will check if the ranges are hotpluggable with the
   Hot Pluggable bit in SRAT from ACPI BIOS.
   - If a range is hotpluggable, then from ss to the end of the corresponding
 node will be ZONE_MOVABLE.
   - If a range is not hotpluggable, then the range will be ignored.

2. If user want to leave the configuration work to the kernel, then specify
   as the following:
movablecore_map=acpi
   In this way, the kernel will get hotplug info from SRAT in ACPI BIOS, and
   auto decide which memory devices could be hotplugged. And all the memory
   on these devices will be in ZONE_MOVABLE.

3. If user didn't specify this option, then the kernel will use all the
   memory on all the nodes evenly. And there is no performance drawback.


This patch also adds functions to parse movablecore_map boot option.
Since the option could be specified more then once, all the maps will
be stored in the global variable movablecore_map.map array.

And also, we keep the array in monotonic increasing order by start_pfn.
And merge all overlapped ranges.

Signed-off-by: Tang Chen 
Signed-off-by: Lai Jiangshan 
Reviewed-by: Wen Congyang 
Tested-by: Lin Feng 
Tested-by: Gu Zheng 
---
 Documentation/kernel-parameters.txt |   29 +
 include/linux/mm.h  |   17 +++
 mm/page_alloc.c |  211 +++
 3 files changed, 257 insertions(+), 0 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index ea8e5b4..af6cce0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1642,6 +1642,35 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
that the amount of memory usable for all allocations
is not too small.
 
+   movablecore_map=acpi
+   [KNL,X86,IA-64,PPC] This parameter is similar to
+memmap except it specifies the memory map of
+ZONE_MOVABLE.
+   This option inform the kernel to use Hot Pluggable bit
+   in flags from SRAT from ACPI BIOS to determine which
+   memory devices could be hotplugged. The corresponding
+   memory ranges will be set as ZONE_MOVABLE.
+
+   movablecore_map=nn[KMG]@ss[KMG]
+   [KNL,X86,IA-64,PPC] The kernel will check if the range
+   is hotpluggable with Hot Pluggable bit in SRAT. If not,
+   the range will be ingored. If yes, do the following:
+   - If more ranges are all within one node, then from
+ lowest ss to the end of the node will be ZONE_MOVABLE.
+   - If a range is within a node, then from ss to the end
+ of the node will be ZONE_MOVABLE.
+   - If a range covers two or more nodes, then from ss to
+ the end of the 1st node will be ZONE_MOVABLE, and all
+ the rest nodes will only have ZONE_MOVABLE.
+   If memmap is specified at the same time, the
+   movablecore_map will be limited within the memmap
+   areas.
+   If kernelcore or movablecore is also specified,
+   movablecore_map will have higher priority to be
+   satisfied. So the administrator should be careful that
+   the amount of movablecore_map areas are not too large.
+   Otherwise kernel won't have enough memory to start.
+
MTD_Partiti

[PATCH v4 6/6] page_alloc: Bootmem limit with movablecore_map

[Tang Chen]

This patch make sure bootmem will not allocate memory from areas that
may be ZONE_MOVABLE. The map info is from movablecore_map boot option.

Signed-off-by: Tang Chen 
Signed-off-by: Lai Jiangshan 
Reviewed-by: Wen Congyang 
Tested-by: Lin Feng 
---
 include/linux/memblock.h |1 +
 mm/memblock.c|   18 +-
 2 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index d452ee1..6e25597 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -42,6 +42,7 @@ struct memblock {
 
 extern struct memblock memblock;
 extern int memblock_debug;
+extern struct movablecore_map movablecore_map;
 
 #define memblock_dbg(fmt, ...) \
if (memblock_debug) printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
diff --git a/mm/memblock.c b/mm/memblock.c
index 6259055..197c3be 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -101,6 +101,7 @@ phys_addr_t __init_memblock 
memblock_find_in_range_node(phys_addr_t start,
 {
phys_addr_t this_start, this_end, cand;
u64 i;
+   int curr = movablecore_map.nr_map - 1;
 
/* pump up @end */
if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
@@ -114,13 +115,28 @@ phys_addr_t __init_memblock 
memblock_find_in_range_node(phys_addr_t start,
this_start = clamp(this_start, start, end);
this_end = clamp(this_end, start, end);
 
-   if (this_end < size)
+restart:
+   if (this_end <= this_start || this_end < size)
continue;
 
+   for (; curr >= 0; curr--) {
+   if ((movablecore_map.map[curr].start_pfn << PAGE_SHIFT)
+   < this_end)
+   break;
+   }
+
cand = round_down(this_end - size, align);
+   if (curr >= 0 &&
+   cand < movablecore_map.map[curr].end_pfn << PAGE_SHIFT) {
+   this_end = movablecore_map.map[curr].start_pfn
+  << PAGE_SHIFT;
+   goto restart;
+   }
+
if (cand >= this_start)
return cand;
}
+
return 0;
 }
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 4/6] page_alloc: Introduce zone_movable_limit[] to keep movable limit for nodes

[Tang Chen]

This patch introduces a new array zone_movable_limit[] to store the
ZONE_MOVABLE limit from movablecore_map boot option for all nodes.
The function sanitize_zone_movable_limit() will find out to which
node the ranges in movable_map.map[] belongs, and calculates the
low boundary of ZONE_MOVABLE for each node.

Signed-off-by: Tang Chen 
Signed-off-by: Liu Jiang 
Reviewed-by: Wen Congyang 
Reviewed-by: Lai Jiangshan 
Tested-by: Lin Feng 
---
 mm/page_alloc.c |   79 ++-
 1 files changed, 78 insertions(+), 1 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 40d2f4b..128d28a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -212,6 +212,7 @@ static unsigned long __meminitdata 
arch_zone_highest_possible_pfn[MAX_NR_ZONES];
 static unsigned long __initdata required_kernelcore;
 static unsigned long __initdata required_movablecore;
 static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
+static unsigned long __meminitdata zone_movable_limit[MAX_NUMNODES];
 
 /* movable_zone is the "real" zone pages in ZONE_MOVABLE are taken from */
 int movable_zone;
@@ -4385,6 +4386,77 @@ static unsigned long __meminit 
zone_absent_pages_in_node(int nid,
return __absent_pages_in_range(nid, zone_start_pfn, zone_end_pfn);
 }
 
+/**
+ * sanitize_zone_movable_limit - Sanitize the zone_movable_limit array.
+ *
+ * zone_movable_limit is initialized as 0. This function will try to get
+ * the first ZONE_MOVABLE pfn of each node from movablecore_map, and
+ * assigne them to zone_movable_limit.
+ * zone_movable_limit[nid] == 0 means no limit for the node.
+ *
+ * Note: Each range is represented as [start_pfn, end_pfn)
+ */
+static void __meminit sanitize_zone_movable_limit(void)
+{
+   int map_pos = 0, i, nid;
+   unsigned long start_pfn, end_pfn;
+
+   if (!movablecore_map.nr_map)
+   return;
+
+   /* Iterate all ranges from minimum to maximum */
+   for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, &nid) {
+   /*
+* If we have found lowest pfn of ZONE_MOVABLE of the node
+* specified by user, just go on to check next range.
+*/
+   if (zone_movable_limit[nid])
+   continue;
+
+#ifdef CONFIG_ZONE_DMA
+   /* Skip DMA memory. */
+   if (start_pfn < arch_zone_highest_possible_pfn[ZONE_DMA])
+   start_pfn = arch_zone_highest_possible_pfn[ZONE_DMA];
+#endif
+
+#ifdef CONFIG_ZONE_DMA32
+   /* Skip DMA32 memory. */
+   if (start_pfn < arch_zone_highest_possible_pfn[ZONE_DMA32])
+   start_pfn = arch_zone_highest_possible_pfn[ZONE_DMA32];
+#endif
+
+#ifdef CONFIG_HIGHMEM
+   /* Skip lowmem if ZONE_MOVABLE is highmem. */
+   if (zone_movable_is_highmem() &&
+   start_pfn < arch_zone_lowest_possible_pfn[ZONE_HIGHMEM])
+   start_pfn = arch_zone_lowest_possible_pfn[ZONE_HIGHMEM];
+#endif
+
+   if (start_pfn >= end_pfn)
+   continue;
+
+   while (map_pos < movablecore_map.nr_map) {
+   if (end_pfn <= movablecore_map.map[map_pos].start_pfn)
+   break;
+
+   if (start_pfn >= movablecore_map.map[map_pos].end_pfn) {
+   map_pos++;
+   continue;
+   }
+
+   /*
+* The start_pfn of ZONE_MOVABLE is either the minimum
+* pfn specified by movablecore_map, or 0, which means
+* the node has no ZONE_MOVABLE.
+*/
+   zone_movable_limit[nid] = max(start_pfn,
+   movablecore_map.map[map_pos].start_pfn);
+
+   break;
+   }
+   }
+}
+
 #else /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 static inline unsigned long __meminit zone_spanned_pages_in_node(int nid,
unsigned long zone_type,
@@ -4403,6 +4475,10 @@ static inline unsigned long __meminit 
zone_absent_pages_in_node(int nid,
return zholes_size[zone_type];
 }
 
+static void __meminit sanitize_zone_movable_limit(void)
+{
+}
+
 #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
 static void __meminit calculate_node_totalpages(struct pglist_data *pgdat,
@@ -4846,7 +4922,6 @@ static void __init find_zone_movable_pfns_for_nodes(void)
goto out;
 
/* usable_startpfn is the lowest possible pfn ZONE_MOVABLE can be at */
-   find_usable_zone_for_movable();
usable_startpfn = arch_zone_lowest_possible_pfn[movable_zone];
 
 restart:
@@ -5005,6 +5080,8 @@ void __init free_area_init_nodes(unsigned long 
*max_zone_pfn)
 
/* Find the PFNs that ZONE_MOVABLE begins at in each node */
memset(zone

[GIT PULL] pwm: Changes for v3.8-rc1

[Thierry Reding]

Hi Linus,

The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:

  Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)

are available in the git repository at:

  git://gitorious.org/linux-pwm/linux-pwm.git tags/for-3.8-rc1

for you to fetch changes up to 20e8ac3eea4dcfeea6ebeae57cd2c739fa48da11:

  pwm: samsung: add missing s3c->pwm_id assignment (2012-12-14 08:32:58 +0100)

Thanks,
Thierry


pwm: Changes for v3.8-rc1

A new driver has been added for the SPEAr platform and the TWL4030/6030
driver has been replaced by two drivers that control the regular PWMs
and the PWM driven LEDs provided by the chips.

The vt8500, tiecap, tiehrpwm, i.MX, LPC32xx and Samsung drivers have all
been improved and the device tree bindings now support the PWM signal
polarity.


Alban Bedel (3):
  pwm: lpc32xx: Fix the PWM polarity
  pwm: lpc32xx: Properly disable the clock on device removal
  pwm: lpc32xx: Set the chip base for dynamic allocation

Axel Lin (1):
  pwm: spear: Staticize spear_pwm_config()

Joonyoung Shim (1):
  pwm: samsung: add missing s3c->pwm_id assignment

Lothar Waßmann (1):
  pwm: i.MX: eliminate build warning

Peter Ujfalusi (3):
  pwm: New driver to support PWMs on TWL4030/6030 series of PMICs
  pwm: New driver to support PWM driven LEDs on TWL4030/6030 series of PMICs
  pwm: Remove pwm-twl6030 driver

Philip, Avinash (7):
  pwm: Device tree support for PWM polarity
  pwm: Add TI PWM subsystem driver
  pwm: tiecap: Add device-tree binding
  pwm: pwm-tiecap: pinctrl support
  pwm: pwm-tiehrpwm: Adding TBCLK gating support.
  pwm: tiehrpwm: Add device-tree binding
  pwm: pwm-tiehrpwm: pinctrl support

Shiraz Hashim (1):
  pwm: Add SPEAr PWM chip driver support

Thierry Reding (1):
  pwm: Export of_pwm_xlate_with_flags()

Tony Prisk (3):
  pwm: vt8500: Update vt8500 PWM driver support
  pwm: vt8500: Fix build error
  pwm: vt8500: Ensure PWM clock is enabled during pwm_config

 .../devicetree/bindings/pwm/pwm-tiecap.txt |  23 ++
 .../devicetree/bindings/pwm/pwm-tiehrpwm.txt   |  23 ++
 .../devicetree/bindings/pwm/pwm-tipwmss.txt|  31 ++
 Documentation/devicetree/bindings/pwm/pwm.txt  |  17 +-
 .../devicetree/bindings/pwm/spear-pwm.txt  |  18 ++
 .../devicetree/bindings/pwm/ti,twl-pwm.txt |  17 +
 .../devicetree/bindings/pwm/ti,twl-pwmled.txt  |  17 +
 .../devicetree/bindings/pwm/vt8500-pwm.txt |  17 +
 drivers/pwm/Kconfig|  39 ++-
 drivers/pwm/Makefile   |   5 +-
 drivers/pwm/core.c |  29 ++
 drivers/pwm/pwm-imx.c  |   2 +-
 drivers/pwm/pwm-lpc32xx.c  |  23 +-
 drivers/pwm/pwm-samsung.c  |   1 +
 drivers/pwm/pwm-spear.c| 276 
 drivers/pwm/pwm-tiecap.c   |  48 ++-
 drivers/pwm/pwm-tiehrpwm.c |  62 +++-
 drivers/pwm/pwm-tipwmss.c  | 139 
 drivers/pwm/pwm-tipwmss.h  |  39 +++
 drivers/pwm/pwm-twl-led.c  | 344 
 drivers/pwm/pwm-twl.c  | 359 +
 drivers/pwm/pwm-twl6030.c  | 184 ---
 drivers/pwm/pwm-vt8500.c   |  98 --
 include/linux/pwm.h|   3 +
 24 files changed, 1593 insertions(+), 221 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/spear-pwm.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
 create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
 create mode 100644 drivers/pwm/pwm-spear.c
 create mode 100644 drivers/pwm/pwm-tipwmss.c
 create mode 100644 drivers/pwm/pwm-tipwmss.h
 create mode 100644 drivers/pwm/pwm-twl-led.c
 create mode 100644 drivers/pwm/pwm-twl.c
 delete mode 100644 drivers/pwm/pwm-twl6030.c


pgpRedQAaprad.pgp
Description: PGP signature

Re: [rtc-linux] [PATCH] rtc: recycle id when unloading a rtc driver

[Andrew Morton]

On Wed, 19 Dec 2012 08:55:57 +0100 Alexander Holler  
wrote:

> >
> > I'm all confused.
> >
> > Lothar's patch simply reverts Vincent's patch.  And that appears to be
> > the correct thing to so, as the ida_simple_remove() in
> > rtc_device_release() should be sufficient.
> >
> > But apparently that doesn't work, because Vincent was seeing the RTC
> > ID's increment rather than getting reused.
> >
> > Is it the case that rtc_device_release() is not being called sometimes?
> > If so, under what circumstances?
> 
> Maybe something (sysfs or whatever) still has a reference to it. Vincent 
> should check that.
> 
> But I'm sure the ID will be recycled with that put_device() in 
> unregister because I've got the same warning as Lothar did when 
> (porperly) removing an RTC (with kernel 3.7).

If, as appears to be the case, rtc_device_release() is not being called
then we're also leaking memory.  So yes please, it would be good if
someone who can reproduce the IDs-dont-decrease problem could dive in
and work out why ->release() isn't begin called.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command

[Sebastian Andrzej Siewior]

On Wed, Dec 19, 2012 at 03:13:32AM +, Fangxiaozhi (Franko) wrote:
>   By the way, I found the kernel is updated to 3.7.1 today. So I have to 
> update my patch based on 3.7.1, and resubmit it?
>   Right?

You should rebase your patch on top of Greg's usb-next branch of his usb tree.
 
http://git.kernel.org/?p=linux/kernel/git/gregkh/usb.git;a=shortlog;h=refs/heads/usb-next

but I guess that there are hardly any changes in that area. The last change in
drivers/usb/storage/initializers.* is yours "USB: usb-storage fails to attach
to Huawei Datacard cdrom device".

If you call ./scripts/get_maintainer.pl on your patch you should learn that
you miss
|Matthew Dharm 
|usb-stor...@lists.one-eyed-alien.net

> > And shouldn't you read something from the us->recv_bulk_pipe after
> > that?
>   Well, because our device will re-connect to switch the ports if it 
> receives the command.
>   So it is not necessary to read the response of the command.

Hmm. I guess this for Matthew / Greg to decide, I don't insist on anything.
Maybe a comment would be nice because now it looks, atleast to me, that
something is missing.

Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/01] Input multitouch: fix horizontal two-finger-scrolling on Sentelic touchpads

[Henrik Rydberg]

Hi Christophe,

> Fix horizontal two-finger scrolling on Sentelic touchpads. Currently
> horizontal two-fingers scrolling does not work with these touchpads.
> The patch also makes vertical two-finger scrolling smoother in some
> applications e.g. Firefox.
> 
> Signed-off-by: Christophe TORDEUX 
> 
> 
> This patch was inspired by the reading of
> drivers/input/mouse/synaptics.c. It is known to work (tested) on
> Sentelic touchpads version STL3888_C0. Very probably works on all later
> versions, and possibly works on some earlier versions of the hardware in
> question.

Thanks for the patch. I would prefer it if this driver was converted
to use input_mt_assign_slots() instead.

> 
> diff -uprN -X vanilla/linux-3.7-rc8/Documentation/dontdiff 
> vanilla/linux-3.7-rc8/drivers/input/mouse/sentelic.c 
> linux-3.7-rc8/drivers/input/mouse/sentelic.c
> --- vanilla/linux-3.7-rc8/drivers/input/mouse/sentelic.c  2012-12-11 
> 04:32:44.476930522 +0100
> +++ linux-3.7-rc8/drivers/input/mouse/sentelic.c  2012-12-12 
> 01:16:41.766018017 +0100
> @@ -706,8 +706,10 @@ static psmouse_ret_t fsp_process_byte(st
>   struct input_dev *dev = psmouse->dev;
>   struct fsp_data *ad = psmouse->private;
>   unsigned char *packet = psmouse->packet;
> + unsigned char *last_packet = ad->last_pkt;
>   unsigned char button_status = 0, lscroll = 0, rscroll = 0;
>   unsigned short abs_x, abs_y, fgrs = 0;
> + unsigned short last_abs_x, last_abs_y;
>   int rel_x, rel_y;
>  
>   if (psmouse->pktcnt < 4)
> @@ -734,6 +736,9 @@ static psmouse_ret_t fsp_process_byte(st
>  
>   abs_x = GET_ABS_X(packet);
>   abs_y = GET_ABS_Y(packet);
> + last_abs_x = GET_ABS_X(last_packet);
> + last_abs_y = GET_ABS_Y(last_packet);
> + memcpy(ad->last_pkt, packet, psmouse->pktcnt);

Why not save the variables instead of the array?

>  
>   if (packet[0] & FSP_PB0_MFMC) {
>   /*
> @@ -753,10 +758,19 @@ static psmouse_ret_t fsp_process_byte(st
>*/
>   fgrs = 1;
>   fsp_set_slot(dev, 0, false, 0, 0);
> +
> + /* We don't need to re-order
> +  * coordinates if last finger
> +  * was same finger
> +  */
> + last_abs_x = abs_x;
> + last_abs_y = abs_y;
>   }
>   ad->last_mt_fgr = 2;
>  
> - fsp_set_slot(dev, 1, fgrs == 2, abs_x, abs_y);
> + fsp_set_slot(dev, 1, fgrs == 2,
> + max(abs_x, last_abs_x),
> + max(abs_y, last_abs_y));

Relying on the box (x1, y1, max(x1, x2), max(y1, y2)) seems to assume
a lot about the behavior of the device.

>   } else {
>   /* 1st finger */
>   if (ad->last_mt_fgr == 1) {
> @@ -767,9 +781,18 @@ static psmouse_ret_t fsp_process_byte(st
>*/
>   fgrs = 1;
>   fsp_set_slot(dev, 1, false, 0, 0);
> +
> + /* We don't need to re-order
> +  * coordinates if last finger
> +  * was same finger
> +  */
> + last_abs_x = abs_x;
> + last_abs_y = abs_y;
>   }
>   ad->last_mt_fgr = 1;
> - fsp_set_slot(dev, 0, fgrs != 0, abs_x, abs_y);
> + fsp_set_slot(dev, 0, fgrs != 0,
> + min(abs_x, last_abs_x),
> + min(abs_y, last_abs_y));
>   }
>   } else {
>   /* SFAC packet */
> @@ -788,12 +811,18 @@ static psmouse_ret_t fsp_process_byte(st
>   if (abs_x != 0 && abs_y != 0)
>   fgrs = 1;
>  
> + /* We don't need to re-order
> +  * coordinates of SFAC packets
> +  */
> + last_abs_x = abs_x;
> + last_abs_y = abs_y;
> +
>   fsp_set_slot(dev, 0, fgrs > 0, abs_x, abs_y);
>   fsp_set_slot(dev, 1, false, 0, 0);
>   }
>   if (fgrs > 0) {
> - input_report_abs(dev, ABS_X, abs_x);
> - input_report_abs(dev, ABS_Y, abs_y);
> +

Re: [PATCH 1/2] x86: Provide guards in uapi/asm/hw_breakpoint.h to prevent deletion by patch

[Jean Delvare]

On Mon, 17 Dec 2012 14:49:25 +, David Howells wrote:
> Provide reinclusion guards in the empty uapi/asm/hw_breakpoint.h to make sure
> that the patch program doesn't delete it.
> 
> However, should some part of asm/hw_breakpoint.h actually be exported here,
> or, possibly, should the entire uapi file be removed?  In v3.6, though the
> file was marked for export to userspace, it had nothing outside of __KERNEL__.
> 
> Signed-off-by: David Howells 
> cc: Jean Delvare 
> ---
> 
>  arch/x86/include/uapi/asm/hw_breakpoint.h |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/uapi/asm/hw_breakpoint.h 
> b/arch/x86/include/uapi/asm/hw_breakpoint.h
> index e69de29..895596b 100644
> --- a/arch/x86/include/uapi/asm/hw_breakpoint.h
> +++ b/arch/x86/include/uapi/asm/hw_breakpoint.h
> @@ -0,0 +1,4 @@
> +#ifndef  _UAPI_I386_HW_BREAKPOINT_H
> +#define  _UAPI_I386_HW_BREAKPOINT_H
> +
> +#endif   /* _UAPI_I386_HW_BREAKPOINT_H */
> 

Reviewed-by: Jean Delvare 

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] x86: Provide guards in uapi/asm/setup.h to prevent deletion by patch

[Jean Delvare]

On Mon, 17 Dec 2012 14:49:32 +, David Howells wrote:
> Provide reinclusion guards in the empty uapi/asm/setup.h to make sure that the
> patch program doesn't delete it.
> 
> However, should some part of asm/hw_setup.h actually be exported here, or,
> possibly, should the entire uapi file be removed?  In v3.6, though the file
> was marked for export to userspace, it had nothing outside of __KERNEL__.
> 
> Signed-off-by: David Howells 
> cc: Jean Delvare 
> ---
> 
>  arch/x86/include/uapi/asm/setup.h |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/include/uapi/asm/setup.h 
> b/arch/x86/include/uapi/asm/setup.h
> index e69de29..96a4d53 100644
> --- a/arch/x86/include/uapi/asm/setup.h
> +++ b/arch/x86/include/uapi/asm/setup.h
> @@ -0,0 +1,4 @@
> +#ifndef _UAPI_ASM_X86_SETUP_H
> +#define _UAPI_ASM_X86_SETUP_H
> +
> +#endif /* _UAPI_ASM_X86_SETUP_H */
> 

Reviewed-by: Jean Delvare 

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [rtc-linux] [PATCH] rtc: recycle id when unloading a rtc driver

[Alexander Holler]

Am 19.12.2012 09:27, schrieb Andrew Morton:

On Wed, 19 Dec 2012 08:55:57 +0100 Alexander Holler  
wrote:



I'm all confused.

Lothar's patch simply reverts Vincent's patch.  And that appears to be
the correct thing to so, as the ida_simple_remove() in
rtc_device_release() should be sufficient.

But apparently that doesn't work, because Vincent was seeing the RTC
ID's increment rather than getting reused.

Is it the case that rtc_device_release() is not being called sometimes?
If so, under what circumstances?


Maybe something (sysfs or whatever) still has a reference to it. Vincent
should check that.

But I'm sure the ID will be recycled with that put_device() in
unregister because I've got the same warning as Lothar did when
(porperly) removing an RTC (with kernel 3.7).


If, as appears to be the case, rtc_device_release() is not being called
then we're also leaking memory.  So yes please, it would be good if
someone who can reproduce the IDs-dont-decrease problem could dive in
and work out why ->release() isn't begin called.


Unlikely, as I've worked hard to get one of the first drivers for 
pluggable RTCs into the kernel. ;)
I think every sane kernel has them statically linked in and it's likely 
a problem of the RTC-driver Vincent experienced that with.


Regards,

Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: common clock framwork: clk_set_rate issue

[Sascha Hauer]

On Wed, Dec 19, 2012 at 02:49:25PM +0800, Chao Xie wrote:
> On Tue, Dec 18, 2012 at 3:47 PM, Sascha Hauer  wrote:
> >> There is already a flag to do it.
> >> CLK_SET_RATE_PARENT
> >
> > That flag has another meaning. It means that a clock is allowed to
> > change the parents rate when a rate change is requested. What I meant
> > is a flag that allows a mux to change its parent when a rate change is
> > requested.
> >
> another flag can help it. what i mean is that i can clear the flag
> CLK_SET_RATE_PARENT of MUX's children, so when clock changing will not
> impact the MUX.
> 
> >> if the mux does not want to changes the input for clk_set_rate called
> >> by its child, it can clear this flag.
> >> The question is whether we need add the round_rate/recalc_rate for MUX
> >> type of clock? Is there any special issue about it that why current
> >> MUX implementation does not have these callbacks?
> >
> > They currently do not need these callbacks. When a clock does not have
> > round_rate propagates up to the parent if CLK_SET_RATE_PARENT is set or
> > it returns the parents rate if this flag is not set. The situation with
> > set_rate is similar.
> >
> So it means that for a uart clock  that get its clock from
> MUX --> DIV --> UART
> when uart want to change its rate, the driver has to know the topology
> of clock tree. It can not directly clk_set_rate(uart), because it only
> change the DIV settings, and if we want to change the MUX input, we
> have to invoke clk_set_parent(MUX). So the uart driver need to know
> the clock tree topology, and it is not good for sharing a driver
> between mutiple SOCs that has same UART controller IP.
> That is what i am confused about.

A driver shouldn't need to know the clock topology. If you have a setup
like described above and want to have the mux look for the best parent
during rate change, then a new flag for the mux is needed, something
like:

CLK_SET_RATE_SWITCH_PARENT (1 << x) /* allow to change parent on clk_set_rate /*

For the reasons I described earlier in this thread this would have to be
optional as on i.MX I don't want magic parent changes to happen on a
rate change.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] spi: Add the flag indicate to registe new device as children of master or not.

[Mark Brown]

On Wed, Dec 19, 2012 at 04:44:03AM -0500, Jun Chen wrote:

> This spi_alloc_device function will be called in the spi_new_device
> function to alloc new device as the master. But other way, it is called
> by the of_register_spi_devices function to register new device as the
> children of the master. I will update changlog to add it. 

But why is this a bad thing?  You've said what's happening but not why
it's a problem.


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: dapm: Fix the unpaired runtime_get/put cases

[Mark Brown]

On Wed, Dec 19, 2012 at 06:36:37PM +0800, Chuansheng Liu wrote:

> But some devices has been set to STANDY bias directly during device probing,
> such as cs42l73_probe():
> cs42l73_set_bias_level(codec, SND_SOC_BIAS_STANDBY);

> Then it will cause runtime_get() not be called but laterly runtime_put() will
> be called. Also found some other uppaired cases.

This is just a bug in the driver, if it's idle_bias_off then it really
should be starting in _OFF or at the very least starting actually in
_STANDBY (including taking the runtime reference) rather than partially
in _STANDBY.

> So here add new flag get_runtime, and the logic will be:
> 1/ when device is from off to non-off bias, runtime_get() will be called if 
> not yet;
> 2/ When device is off bias, runtime_put() will be called if runtime_get() has
>been called;

This is really not a good idea at all, it's just adding new special
cases and making the code more obscure.


signature.asc
Description: Digital signature

[PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT.

[Tang Chen]

The Hot Plugable bit in SRAT flags specifys if the memory range
could be hotplugged.

If user specified movablecore_map=nn[KMG]@ss[KMG], reset
movablecore_map.map to the intersection of hotpluggable ranges from
SRAT and old movablecore_map.map.
Else if user specified movablecore_map=acpi, just use the hotpluggable
ranges from SRAT.
Otherwise, do nothing. The kernel will use all the memory in all nodes
evenly.

The idea "getting info from SRAT" was from Liu Jiang .
And the idea "do more limit for memblock" was from Wu Jianguo 


Signed-off-by: Tang Chen 
Tested-by: Gu Zheng 
---
 arch/x86/mm/srat.c |   55 +--
 1 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 4ddf497..a8856d2 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -146,7 +146,12 @@ int __init
 acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
 {
u64 start, end;
+   u32 hotpluggable;
int node, pxm;
+#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+   int overlap;
+   unsigned long start_pfn, end_pfn;
+#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
 
if (srat_disabled())
return -1;
@@ -157,8 +162,10 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
return -1;
 
-   if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info())
+   hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
+   if (hotpluggable && !save_add_info())
return -1;
+
start = ma->base_address;
end = start + ma->length;
pxm = ma->proximity_domain;
@@ -178,9 +185,51 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
 
node_set(node, numa_nodes_parsed);
 
-   printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+   printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx] %s\n",
   node, pxm,
-  (unsigned long long) start, (unsigned long long) end - 1);
+  (unsigned long long) start, (unsigned long long) end - 1,
+  hotpluggable ? "Hot Pluggable": "");
+
+#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+   start_pfn = PFN_DOWN(start);
+   end_pfn = PFN_UP(end);
+
+   if (!hotpluggable) {
+   /* Clear the range overlapped in movablecore_map.map */
+   remove_movablecore_map(start_pfn, end_pfn);
+   goto out;
+   }
+
+   if (!movablecore_map.acpi) {
+   for (overlap = 0; overlap < movablecore_map.nr_map; overlap++) {
+   if (start_pfn < movablecore_map.map[overlap].end_pfn)
+   break;
+   }
+
+   /*
+* If there is no overlapped range, or the end of the overlapped
+* range is higher than end_pfn, then insert nothing.
+*/
+   if (end_pfn <= movablecore_map.map[overlap].end_pfn)
+   goto out;
+
+   /*
+* Otherwise, insert the rest of this range to prevent memblock
+* from allocating memory in it.
+*/
+   start_pfn = movablecore_map.map[overlap].end_pfn;
+   start = start_pfn >> PAGE_SHIFT;
+   }
+
+   /* If user chose to use SRAT info, insert the range anyway. */
+   if (insert_movablecore_map(start_pfn, end_pfn))
+   pr_err("movablecore_map: too many entries;"
+   " ignoring [mem %#010llx-%#010llx]\n",
+   (unsigned long long) start,
+   (unsigned long long) (end - 1));
+
+out:
+#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
return 0;
 }
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 3/6] ACPI: Restructure movablecore_map with memory info from SRAT.

[Tang Chen]

On 12/19/2012 04:15 PM, Tang Chen wrote:

The Hot Plugable bit in SRAT flags specifys if the memory range
could be hotplugged.

If user specified movablecore_map=nn[KMG]@ss[KMG], reset
movablecore_map.map to the intersection of hotpluggable ranges from
SRAT and old movablecore_map.map.
Else if user specified movablecore_map=acpi, just use the hotpluggable
ranges from SRAT.
Otherwise, do nothing. The kernel will use all the memory in all nodes
evenly.

The idea "getting info from SRAT" was from Liu Jiang.
And the idea "do more limit for memblock" was from Wu 
Jianguo

Signed-off-by: Tang Chen
Tested-by: Gu Zheng
---
  arch/x86/mm/srat.c |   38 +++---
  1 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 4ddf497..947a2b5 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -146,7 +146,12 @@ int __init
  acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
  {
u64 start, end;
+   u32 hotpluggable;
int node, pxm;
+#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+   int overlap;
+   unsigned long start_pfn, end_pfn;
+#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */

if (srat_disabled())
return -1;
@@ -157,8 +162,10 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
if ((ma->flags&  ACPI_SRAT_MEM_ENABLED) == 0)
return -1;

-   if ((ma->flags&  ACPI_SRAT_MEM_HOT_PLUGGABLE)&&  !save_add_info())
+   hotpluggable = ma->flags&  ACPI_SRAT_MEM_HOT_PLUGGABLE;
+   if (hotpluggable&&  !save_add_info())
return -1;
+
start = ma->base_address;
end = start + ma->length;
pxm = ma->proximity_domain;
@@ -178,9 +185,34 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)

node_set(node, numa_nodes_parsed);

-   printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+   printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx] %s\n",
   node, pxm,
-  (unsigned long long) start, (unsigned long long) end - 1);
+  (unsigned long long) start, (unsigned long long) end - 1,
+  hotpluggable ? "Hot Pluggable": "");
+
+#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
+   start_pfn = PFN_DOWN(start);
+   end_pfn = PFN_UP(end);
+
+   if (!hotpluggable) {
+   /* Clear the range overlapped in movablecore_map.map */
+   remove_movablecore_map(start_pfn, end_pfn);
+   goto out;
+   }
+
+   /* If not using SRAT, don't modify user configuration. */
+   if (!movablecore_map.acpi)
+   goto out;


Here, forgot to do some check. Please see the new resent one.

Thanks. :)


+
+   /* If user chose to use SRAT info, insert the range anyway. */
+   if (insert_movablecore_map(start_pfn, end_pfn))
+   pr_err("movablecore_map: too many entries;"
+   " ignoring [mem %#010llx-%#010llx]\n",
+   (unsigned long long) start,
+   (unsigned long long) (end - 1));
+
+out:
+#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
return 0;
  }



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/5] page_alloc: Bootmem limit with movablecore_map

[Tang Chen]

Hi Wu,

Sorry for such a long delay.

On 11/26/2012 08:40 PM, wujianguo wrote:

Hi Tang,
I tested this patchset in x86_64, and I found that this patch didn't
work as expected.
For example, if node2's memory pfn range is [0x68-0x98),
I boot kernel with movablecore_map=4G@0x68000, all memory in node2 will be
in ZONE_MOVABLE, but bootmem still can be allocated from 
[0x78000-0x98000),
that means bootmem *is allocated* from ZONE_MOVABLE. This because 
movablecore_map
only contains [0x68000-0x78000). I think we can fixup movablecore_map, 
how
about this:

Signed-off-by: Jianguo Wu
Signed-off-by: Jiang Liu
---
  arch/x86/mm/srat.c |   15 +++
  include/linux/mm.h |3 +++
  mm/page_alloc.c|2 +-
  3 files changed, 19 insertions(+), 1 deletions(-)

diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 4ddf497..f1aac08 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -147,6 +147,8 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
  {
u64 start, end;
int node, pxm;
+   int i;
+   unsigned long start_pfn, end_pfn;

if (srat_disabled())
return -1;
@@ -181,6 +183,19 @@ acpi_numa_memory_affinity_init(struct 
acpi_srat_mem_affinity *ma)
printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
   node, pxm,
   (unsigned long long) start, (unsigned long long) end - 1);
+
+   start_pfn = PFN_DOWN(start);
+   end_pfn = PFN_UP(end);


I think the logic here has some problems.

Let's assume the range here is [3G, 5G), and
movablecore_map.map[] is like: [1G, 2G), [3G, 4G), [7G,8G).


+   for (i = 0; i<  movablecore_map.nr_map; i++) {
+   if (end_pfn<= movablecore_map.map[i].start)
+   break;


When i = 0, 5G > 1G, no break.


+
+   if (movablecore_map.map[i].end<  end_pfn) {
+   insert_movablecore_map(movablecore_map.map[i].end,
+   end_pfn);


2G < 5G, so insert [2G, 5G). It's incorrect.
We should insert [4G, 5G).

I got your idea, and I also add SRAT support. So I made a new patch to
do this. Please have a look if you like. :)

Thanks. :)


+   }
+   }
+
return 0;
  }

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 5a65251..7a23403 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1356,6 +1356,9 @@ extern int __meminit __early_pfn_to_nid(unsigned long 
pfn);
  #endif /* CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID */
  #endif

+extern void insert_movablecore_map(unsigned long start_pfn,
+ unsigned long end_pfn);
+
  extern void set_dma_reserve(unsigned long new_dma_reserve);
  extern void memmap_init_zone(unsigned long, int, unsigned long,
unsigned long, enum memmap_context);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 544c829..e6b5090 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5089,7 +5089,7 @@ early_param("movablecore", cmdline_parse_movablecore);
   * This function will also merge the overlapped ranges, and sort the array
   * by start_pfn in monotonic increasing order.
   */
-static void __init insert_movablecore_map(unsigned long start_pfn,
+void __init insert_movablecore_map(unsigned long start_pfn,
  unsigned long end_pfn)
  {
int pos, overlap;
-- 1.7.6.1
.

Thanks,
Jianguo Wu

On 2012-11-23 18:44, Tang Chen wrote:

This patch make sure bootmem will not allocate memory from areas that
may be ZONE_MOVABLE. The map info is from movablecore_map boot option.

Signed-off-by: Tang Chen
Signed-off-by: Lai Jiangshan
Reviewed-by: Wen Congyang
Tested-by: Lin Feng
---
  include/linux/memblock.h |1 +
  mm/memblock.c|   15 ++-
  2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index d452ee1..6e25597 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -42,6 +42,7 @@ struct memblock {

  extern struct memblock memblock;
  extern int memblock_debug;
+extern struct movablecore_map movablecore_map;

  #define memblock_dbg(fmt, ...) \
if (memblock_debug) printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
diff --git a/mm/memblock.c b/mm/memblock.c
index 6259055..33b3b4d 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -101,6 +101,7 @@ phys_addr_t __init_memblock 
memblock_find_in_range_node(phys_addr_t start,
  {
phys_addr_t this_start, this_end, cand;
u64 i;
+   int curr = movablecore_map.nr_map - 1;

/* pump up @end */
if (end == MEMBLOCK_ALLOC_ACCESSIBLE)
@@ -114,13 +115,25 @@ phys_addr_t __init_memblock 
memblock_find_in_range_node(phys_addr_t start,
this_start = clamp(this_start, start, end);
this_end = clamp(this_end, start, end);

-   if (this_end<  size)
+res

Re: [PATCH v2 0/5] Multiqueue virtio-scsi, and API for piecewise buffer submission

[Paolo Bonzini]

Il 18/12/2012 23:18, Rolf Eike Beer ha scritto:
> Paolo Bonzini wrote:
>> Hi all,
>>
>> this series adds multiqueue support to the virtio-scsi driver, based
>> on Jason Wang's work on virtio-net.  It uses a simple queue steering
>> algorithm that expects one queue per CPU.  LUNs in the same target always
>> use the same queue (so that commands are not reordered); queue switching
>> occurs when the request being queued is the only one for the target.
>> Also based on Jason's patches, the virtqueue affinity is set so that
>> each CPU is associated to one virtqueue.
>>
>> I tested the patches with fio, using up to 32 virtio-scsi disks backed
>> by tmpfs on the host.  These numbers are with 1 LUN per target.
>>
>> FIO configuration
>> -
>> [global]
>> rw=read
>> bsrange=4k-64k
>> ioengine=libaio
>> direct=1
>> iodepth=4
>> loops=20
>>
>> overall bandwidth (MB/s)
>> 
>>
>> # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 VCPUs
>> 1  540   626 599
>> 2  795   965 925
>> 4  997  13761500
>> 8 1136  21302060
>> 161440  22692474
>> 241408  21792436
>> 321515  19782319
>>
>> (These numbers for single-queue are with 4 VCPUs, but the impact of adding
>> more VCPUs is very limited).
>>
>> avg bandwidth per LUN (MB/s)
>> 
>>
>> # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 VCPUs
>> 1  540   626 599
>> 2  397   482 462
>> 4  249   344 375
>> 8  142   266 257
>> 16  90   141 154
>> 24  5890 101
>> 32  4761  72
> 
> Is there an explanation why 8x8 is slower then 4x8 in both cases?

Regarding the "in both cases" part, it's because the second table has
the same data as the first, but divided by the first column.

In general, the "strangenesses" you find are probably within statistical
noise or due to other effects such as host CPU utilization or contention
on the big QEMU lock.

Paolo


 8x1 and 8x2
> being slower than 4x1 and 4x2 is more or less expected, but 8x8 loses against 
> 4x8 while 8x4 wins against 4x4 and 8x16 against 4x16.
> 
> Eike
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/8] mm: memcg: only evict file pages when we have plenty

[Mel Gorman]

On Wed, Dec 19, 2012 at 12:21:55AM -0500, Simon Jeons wrote:
> On Mon, 2012-12-17 at 16:54 +0100, Michal Hocko wrote:
> > On Sun 16-12-12 09:21:54, Simon Jeons wrote:
> > > On 12/13/2012 10:55 PM, Michal Hocko wrote:
> > > >On Wed 12-12-12 17:28:44, Johannes Weiner wrote:
> > > >>On Wed, Dec 12, 2012 at 04:53:36PM -0500, Rik van Riel wrote:
> > > >>>On 12/12/2012 04:43 PM, Johannes Weiner wrote:
> > > dc0422c "mm: vmscan: only evict file pages when we have plenty" makes
> > > a point of not going for anonymous memory while there is still enough
> > > inactive cache around.
> > > 
> > > The check was added only for global reclaim, but it is just as useful
> > > for memory cgroup reclaim.
> > > 
> > > Signed-off-by: Johannes Weiner 
> > > ---
> > >   mm/vmscan.c | 19 ++-
> > >   1 file changed, 10 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index 157bb11..3874dcb 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -1671,6 +1671,16 @@ static void get_scan_count(struct lruvec 
> > > *lruvec, struct scan_control *sc,
> > >   denominator = 1;
> > >   goto out;
> > >   }
> > > + /*
> > > +  * There is enough inactive page cache, do not reclaim
> > > +  * anything from the anonymous working set right now.
> > > +  */
> > > + if (!inactive_file_is_low(lruvec)) {
> > > + fraction[0] = 0;
> > > + fraction[1] = 1;
> > > + denominator = 1;
> > > + goto out;
> > > + }
> > > 
> > >   anon  = get_lru_size(lruvec, LRU_ACTIVE_ANON) +
> > >   get_lru_size(lruvec, LRU_INACTIVE_ANON);
> > > @@ -1688,15 +1698,6 @@ static void get_scan_count(struct lruvec 
> > > *lruvec, struct scan_control *sc,
> > >   fraction[1] = 0;
> > >   denominator = 1;
> > >   goto out;
> > > - } else if (!inactive_file_is_low_global(zone)) {
> > > - /*
> > > -  * There is enough inactive page cache, do not
> > > -  * reclaim anything from the working set right 
> > > now.
> > > -  */
> > > - fraction[0] = 0;
> > > - fraction[1] = 1;
> > > - denominator = 1;
> > > - goto out;
> > >   }
> > >   }
> > > 
> > > 
> > > >>>I believe the if() block should be moved to AFTER
> > > >>>the check where we make sure we actually have enough
> > > >>>file pages.
> > > >>You are absolutely right, this makes more sense.  Although I'd figure
> > > >>the impact would be small because if there actually is that little
> > > >>file cache, it won't be there for long with force-file scanning... :-)
> > > >Yes, I think that the result would be worse (more swapping) so the
> > > >change can only help.
> > > >
> > > >>I moved the condition, but it throws conflicts in the rest of the
> > > >>series.  Will re-run tests, wait for Michal and Mel, then resend.
> > > >Yes the patch makes sense for memcg as well. I guess you have tested
> > > >this primarily with memcg. Do you have any numbers? Would be nice to put
> > > >them into the changelog if you have (it should help to reduce swapping
> > > >with heavy streaming IO load).
> > > >
> > > >Acked-by: Michal Hocko 
> > > 
> > > Hi Michal,
> > > 
> > > I still can't understand why "The goto out means that it should be
> > > fine either way.",
> > 
> > Not sure I understand your question. goto out just says that either page
> > cache is low or inactive file LRU is too small. And it works for both
> > memcg and global because the page cache is low condition is evaluated
> > only for the global reclaim and always before inactive file is small.
> > Makes more sense?
> 
> Hi Michal,
> 
> I confuse of Gorman's comments below, why the logic change still fine.  
> 

Those comments were wrong.

-- 
Mel Gorman
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Inconsistency in clk framework

[Russell King - ARM Linux]

On Wed, Dec 19, 2012 at 05:10:33PM +1300, Tony Prisk wrote:
> Hi Mike,
> 
> In attempting to remove some IS_ERR_OR_NULL references, it was pointed
> out that clk_get() can return NULL if CONFIG_HAVE_CLK is not defined.

That is correct - but why is that a problem?  As far as users are
concerned, NULL is a valid clock.  If HAVE_CLK is undefined, do you
want all your drivers to suddenly stop working?

> This seems to contradict the kernel docs associated with the normal
> clk_get (when HAVE_CLK is defined) which states:
> 
> * Returns a struct clk corresponding to the clock producer, or
> * valid IS_ERR() condition containing errno.
> 
> Wouldn't a return code of ERR_PTR(-ENOENT) make more sense and be inline
> with the empty of_ versions as well (which return -ENOENT when CONFIG_OF
> is undefined).

No.

> Also, I noticed that clk_get_sys() doesn't appear to be defined in clk.h
> when HAVE_CLK is undefined - is this correct?

It was never promoted to an official API because its only platform code
which should be using it; no device driver (which should have a struct
device to pass into clk_get()) should ever use clk_get_sys().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] rtc: tx4939: Kill get_tx4939rtc_plat_data() function

[Axel Lin]

Simply use dev_get_drvdata() instead.

Signed-off-by: Axel Lin 
---
 drivers/rtc/rtc-tx4939.c |   21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/rtc/rtc-tx4939.c b/drivers/rtc/rtc-tx4939.c
index a12bfac..b570d02 100644
--- a/drivers/rtc/rtc-tx4939.c
+++ b/drivers/rtc/rtc-tx4939.c
@@ -22,11 +22,6 @@ struct tx4939rtc_plat_data {
spinlock_t lock;
 };
 
-static struct tx4939rtc_plat_data *get_tx4939rtc_plat_data(struct device *dev)
-{
-   return platform_get_drvdata(to_platform_device(dev));
-}
-
 static int tx4939_rtc_cmd(struct tx4939_rtc_reg __iomem *rtcreg, int cmd)
 {
int i = 0;
@@ -44,7 +39,7 @@ static int tx4939_rtc_cmd(struct tx4939_rtc_reg __iomem 
*rtcreg, int cmd)
 
 static int tx4939_rtc_set_mmss(struct device *dev, unsigned long secs)
 {
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev);
struct tx4939_rtc_reg __iomem *rtcreg = pdata->rtcreg;
int i, ret;
unsigned char buf[6];
@@ -68,7 +63,7 @@ static int tx4939_rtc_set_mmss(struct device *dev, unsigned 
long secs)
 
 static int tx4939_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev);
struct tx4939_rtc_reg __iomem *rtcreg = pdata->rtcreg;
int i, ret;
unsigned long sec;
@@ -93,7 +88,7 @@ static int tx4939_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
 
 static int tx4939_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
 {
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev);
struct tx4939_rtc_reg __iomem *rtcreg = pdata->rtcreg;
int i, ret;
unsigned long sec;
@@ -125,7 +120,7 @@ static int tx4939_rtc_set_alarm(struct device *dev, struct 
rtc_wkalrm *alrm)
 
 static int tx4939_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
 {
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev);
struct tx4939_rtc_reg __iomem *rtcreg = pdata->rtcreg;
int i, ret;
unsigned long sec;
@@ -154,7 +149,7 @@ static int tx4939_rtc_read_alarm(struct device *dev, struct 
rtc_wkalrm *alrm)
 
 static int tx4939_rtc_alarm_irq_enable(struct device *dev, unsigned int 
enabled)
 {
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev);
 
spin_lock_irq(&pdata->lock);
tx4939_rtc_cmd(pdata->rtcreg,
@@ -166,7 +161,7 @@ static int tx4939_rtc_alarm_irq_enable(struct device *dev, 
unsigned int enabled)
 
 static irqreturn_t tx4939_rtc_interrupt(int irq, void *dev_id)
 {
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev_id);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev_id);
struct tx4939_rtc_reg __iomem *rtcreg = pdata->rtcreg;
unsigned long events = RTC_IRQF;
 
@@ -194,7 +189,7 @@ static ssize_t tx4939_rtc_nvram_read(struct file *filp, 
struct kobject *kobj,
 char *buf, loff_t pos, size_t size)
 {
struct device *dev = container_of(kobj, struct device, kobj);
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev);
struct tx4939_rtc_reg __iomem *rtcreg = pdata->rtcreg;
ssize_t count;
 
@@ -213,7 +208,7 @@ static ssize_t tx4939_rtc_nvram_write(struct file *filp, 
struct kobject *kobj,
  char *buf, loff_t pos, size_t size)
 {
struct device *dev = container_of(kobj, struct device, kobj);
-   struct tx4939rtc_plat_data *pdata = get_tx4939rtc_plat_data(dev);
+   struct tx4939rtc_plat_data *pdata = dev_get_drvdata(dev);
struct tx4939_rtc_reg __iomem *rtcreg = pdata->rtcreg;
ssize_t count;
 
-- 
1.7.9.5



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/5] ARM: remove useless guard in smp.c

[Mark Rutland]

On Tue, Dec 18, 2012 at 06:47:09PM +, Stephen Boyd wrote:
> On 12/18/12 04:06, Mark Rutland wrote:
> > Currently we only provide an implementation of smp_timer_broadcast in
> > smp.c if GENERIC_CLOCKEVENTS_BROADCAST is selected. As
> > smp_timer_broadcast is only used in smp.c, smp.c depends on SMP, and
> > GENERIC_CLOCKEVENTS_BROADCAST is selected by SMP, this is unnecessary.
> 
> You might want to add that GENERIC_CLOCKEVENTS_BROADCAST depends on
> GENERIC_CLOCKEVENTS and SMP depends on GENERIC_CLOCKEVENTS too.

Will do.

> > This patch removes the redundant guard.
> >
> > Signed-off-by: Mark Rutland 
> 
> Reviewed-by: Stephen Boyd 

Thanks!

Mark.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:

> damn, this is still part of our v3.7-rc kernel. Original commit was done
> with no testing whatsoever and caused a big regression to (at least)
> TI's WiFi driver which depend on SDIO to function.

> Too bad things break and even when reported nobody gives a rat's ***
> about them :-s

I guess it's going to be even more of an issue going forward given the
recent events but FWIW it was always very unusual to see any review of
any TWL patches, the PMIC appeared to have been rather abandoned so the
only way of getting any testing was to put stuff in -next and hope.

Mind you, if there is an issue it doesn't seem that serious given that
it took at least one kernel release before anyone noticed and even when
they did you're the first person who bothered to respond...


signature.asc
Description: Digital signature

Re: [PATCH] SPI: SSP SPI Controller driver v3

[Mika Westerberg]

On Tue, Dec 18, 2012 at 04:11:36PM +0800, chao bi wrote:
> 
> This patch is to implement SSP SPI controller driver, which has been applied 
> and
> validated on intel Moorestown & Medfield platform. The patch are originated by
> Ken Mills  and Sylvain Centelles 
> ,
> migrating to lateset Linux mainline SPI framework by Channing 
> 
> and Chen Jun  according to their integration & 
> validation
> on Medfield platform.

This is the same IP block as used in PXA, right? With few modifications
here and there. Is there a reason not to use spi-pxa2xx.c?

I have a set of patches for spi-pxa2xx.c that adds support for Lynxpoint
LPSS, DMA engine and ACPI enumeration. I'm hoping to send those soon (once
-rc1 is released) to the list.

Maybe we can co-operate to get the Medfield support there as well?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 10:45 AM, Mark Brown wrote:
> On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
> 
>> damn, this is still part of our v3.7-rc kernel. Original commit was done
>> with no testing whatsoever and caused a big regression to (at least)
>> TI's WiFi driver which depend on SDIO to function.
> 
>> Too bad things break and even when reported nobody gives a rat's ***
>> about them :-s
> 
> I guess it's going to be even more of an issue going forward given the
> recent events but FWIW it was always very unusual to see any review of
> any TWL patches, the PMIC appeared to have been rather abandoned so the
> only way of getting any testing was to put stuff in -next and hope.

As for the twl-regulator I still have plan to do a major cleanup there. It is
just sad that it received the DT bindings for the current code. The DT support
addition would have been the perfect place to sanitize it. Now it is just
going to be a huge pain in the back.

As for the 32k clock:
I don't know the state of the common clock framework for OMAPs. Is it already
up in 3.7? Or going for 3.8? 3.9? 3.10?...
We need CCF to resolve this. I can cook up the clock driver for the 32k clock
from twl, but in order to use it we need CCF on OMAP.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

Hi Mark,

On Wed, 2012-12-19 at 09:45 +, Mark Brown wrote:
> On Tue, Dec 18, 2012 at 11:54:50AM +0200, Felipe Balbi wrote:
> 
> > damn, this is still part of our v3.7-rc kernel. Original commit was done
> > with no testing whatsoever and caused a big regression to (at least)
> > TI's WiFi driver which depend on SDIO to function.
> 
> > Too bad things break and even when reported nobody gives a rat's ***
> > about them :-s
> 
> I guess it's going to be even more of an issue going forward given the
> recent events but FWIW it was always very unusual to see any review of
> any TWL patches, the PMIC appeared to have been rather abandoned so the
> only way of getting any testing was to put stuff in -next and hope.

Unfortunately I don't know how many of us are using this specific
platform with the latest kernel, so not much testing is done.


> Mind you, if there is an issue it doesn't seem that serious given that
> it took at least one kernel release before anyone noticed and even when
> they did you're the first person who bothered to respond...

To me it has been very serious.  I had to revert a bunch of patches to
be able to continue working with the mainline.  It took me a while to
see the bug because I've been away during the 3.6 cycle.

I think one of the reasons not many people use the mainline with TWL is
exactly because something seems to break on every new kernel release.
I'm one of those who care and report things when I see them.

I think saying that it is not important because only one person reported
it is not a good excuse.  I would at least have liked seeing an answer
saying, "this can't be fixed because of this and that" or "can you try
to fix it by doing this or that".

--
Cheers,
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: OMAP4: PRM: Correct reset source map

[Ivan Khoronzhuk]

In the map for reset sources register we use defines intended for
using with PRM_RSTCTRL register. So fix it.

Signed-off-by: Ivan Khoronzhuk 
---
 arch/arm/mach-omap2/prm44xx.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 7498bc7..e335216 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -56,9 +56,9 @@ static struct omap_prcm_irq_setup omap4_prcm_irq_setup = {
  *   enumeration)
  */
 static struct prm_reset_src_map omap44xx_prm_reset_src_map[] = {
-   { OMAP4430_RST_GLOBAL_WARM_SW_SHIFT,
+   { OMAP4430_GLOBAL_WARM_SW_RST_SHIFT,
  OMAP_GLOBAL_WARM_RST_SRC_ID_SHIFT },
-   { OMAP4430_RST_GLOBAL_COLD_SW_SHIFT,
+   { OMAP4430_GLOBAL_COLD_RST_SHIFT,
  OMAP_GLOBAL_COLD_RST_SRC_ID_SHIFT },
{ OMAP4430_MPU_SECURITY_VIOL_RST_SHIFT,
  OMAP_SECU_VIOL_RST_SRC_ID_SHIFT },
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: OMAP4: PRM: Correct wrong instance usage for reading reset sources

[Ivan Khoronzhuk]

To read reset sources registers we have to use PRM_DEVICE_INST

Signed-off-by: Ivan Khoronzhuk 
---
 arch/arm/mach-omap2/prm44xx.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 7498bc7..0b61b8d 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -333,7 +333,7 @@ static u32 omap44xx_prm_read_reset_sources(void)
u32 r = 0;
u32 v;
 
-   v = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
+   v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
OMAP4_RM_RSTST);
 
p = omap44xx_prm_reset_src_map;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets

[Ivan Khoronzhuk]

From: Nishanth Menon 

RSTTIME is offset 0x8 and RSTST is offset 0x04 for OMAP4430 and
OMAP4460.

Signed-off-by: Nishanth Menon 
[ivan.khoronz...@ti.com: ported from k3.4]
Signed-off-by: Ivan Khoronzhuk 
---
 arch/arm/mach-omap2/prm44xx.h |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 22b0979..8ee1fbd 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -62,8 +62,8 @@
 
 /* OMAP4 specific register offsets */
 #define OMAP4_RM_RSTCTRL   0x
-#define OMAP4_RM_RSTTIME   0x0004
-#define OMAP4_RM_RSTST 0x0008
+#define OMAP4_RM_RSTST 0x0004
+#define OMAP4_RM_RSTTIME   0x0008
 #define OMAP4_PM_PWSTCTRL  0x
 #define OMAP4_PM_PWSTST0x0004
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:

> I don't know the state of the common clock framework for OMAPs. Is it already
> up in 3.7? Or going for 3.8? 3.9? 3.10?...
> We need CCF to resolve this. I can cook up the clock driver for the 32k clock
> from twl, but in order to use it we need CCF on OMAP.

Well, we at least ought to make sure it doesn't appear in the regulator
DT bindings even if it's handled via some OMAP magic - that was the key
point here.


signature.asc
Description: Digital signature

RE: Why Linux kernel forced to enter X2APIC mode( just because of booting cpu has supported x2apic) without depending on BIOS' setting in MSR->x2apic enablement bit ?

Hi Yinghai , 
Thanks very much for your reply. I also checked some other previous 
emails about x2apic patches.

> From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of
> Yinghai Lu

I just worry about this case, 
> > b) If BIOS feel the system doesn't meet x2apic conditions , it will not set
> x2apic enablement bit in MSR ,and pass control to OS with xapic mode.
> 
> kernel will check if cpuid support x2apic, if it supports x2apic, it will 
> check if
> DMAR/intr-remapping could be enabled, if so kernel will switch to x2apic.
> otherwise it will stay with xapic.
> 
> So you need to make cpuid show does not support x2apic --- check with intel
> they have way to do that.
My concerns is BIOS creates different ACPI tables in xAPIC mode and X2APIC 
mode. 
BIOS will auto detect if the system meets x2APIC condition , if no , it will 
not create right ACPI tables for this mode and don't set MSR bit.
For this case (BIOS didn't set MSR , but BSP supports x2apic ) , I want to know 
1, For Linux kernel, which ACPI tables will be used for x2apic and XAPIC ?
2, why Linux kernel will set x2apic enablement bit in CPU msr ? generally 
speaking , BIOS set it and OS get it.
If OS get it , who will read it ? BIOS ?  I consult BIOS designer , he said , 
their BIOS calling service(just like UEFI run time service)
will also judge MSR again , so I don't know why Linux kernel will set MSR bit , 
unless OS has special target . 

> or you can pass "nox2apic" in boot command line.
Yeah, I think this would be fine if we really want to use xAPIC mode instead of 
x2apic mode.
But I am puzzled why Linux kernel will force to enter x2apic just depends on 
BSP has supported x2apic ? 
"BSP supports x2apic" condition is enough for judging if OS can enable x2apic ? 


Thanks very much ! 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 11:09 AM, Mark Brown wrote:
> On Wed, Dec 19, 2012 at 11:00:32AM +0100, Peter Ujfalusi wrote:
> 
>> I don't know the state of the common clock framework for OMAPs. Is it already
>> up in 3.7? Or going for 3.8? 3.9? 3.10?...
>> We need CCF to resolve this. I can cook up the clock driver for the 32k clock
>> from twl, but in order to use it we need CCF on OMAP.
> 
> Well, we at least ought to make sure it doesn't appear in the regulator
> DT bindings even if it's handled via some OMAP magic - that was the key
> point here.

Sure. It must be a clock driver. I already have similar driver (for McPDM fclk
clock) for twl6040.
Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
driver soon (after writing it and testing it). It is going to be for 3.9 but
we can roll it with us I think locally to resolv issues.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/5] clockevents: Add generic timer broadcast receiver

[Mark Rutland]

On Tue, Dec 18, 2012 at 10:17:11PM +, Stephen Boyd wrote:
> On 12/18/12 04:06, Mark Rutland wrote:
> > diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> > index f113755..c2dd022 100644
> > --- a/kernel/time/tick-broadcast.c
> > +++ b/kernel/time/tick-broadcast.c
> > @@ -125,6 +125,21 @@ int tick_device_uses_broadcast(struct 
> > clock_event_device *dev, int cpu)
> > return ret;
> >  }
> >  
> > +int tick_receive_broadcast(void)
> > +{
> > +   struct tick_device *td = this_cpu_ptr(&tick_cpu_device);
> > +   struct clock_event_device *evt = td->evtdev;
> > +
> > +   if (!evt)
> > +   return -ENODEV;
> > +
> > +   if (!evt->event_handler)
> > +   return -EINVAL;
> > +
> 
> Does this actually happen? It's not obvious to me how it does.

Taking a look at it, I don't think it does. Any tick_device's
clock_event_device should have an event_handler. I'll drop this check.

A tick device might not have a clock_event_device registered in some cases --
the x86 lapic timer has to deal with interrupts pending across a kexec, where
interrupts are enabled before local timers are registered. I'm not sure how
common this problem might be though, and whether it should be dealt with here
or elsewhere.

> > +   evt->event_handler(evt);
> > +   return 0;
> > +}
> > +
> >  /*
> >   * Broadcast the event to the cpus, which are set in the mask (mangled).
> >   */
> 
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> 

Thanks,
Mark.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] add blockconsole version 1.1

[Borislav Petkov]

Hey Jörn,

On Tue, Jul 24, 2012 at 10:28:20PM +0200, Borislav Petkov wrote:
> Ok, thanks for taking the time to explain this - very interesting
> stuff.
>
> So, as far as I'm concerned blockconsole is ready for shipping! 8-)

you're probably very busy so I'll be quick: I still think that
blockconsole is a pretty useful thing and I (and I'm sure others too)
would like to restart the discussion and see it upstream eventually.

If there's anything I can do to help, pls let me know.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:

> I think one of the reasons not many people use the mainline with TWL is
> exactly because something seems to break on every new kernel release.
> I'm one of those who care and report things when I see them.

Well, it's a recursive thing - nobody works on mainline, nobody reviews
mainline code and therefore you shouldn't be surprised if there's
issues.

> I think saying that it is not important because only one person reported
> it is not a good excuse.  I would at least have liked seeing an answer
> saying, "this can't be fixed because of this and that" or "can you try
> to fix it by doing this or that".

That's not what I'm saying.  What I'm saying is that it's clearly not
the case that OMAP is completely broken here or anything, it appears to
be one particular system which it appears vanishingly few people cared
about in mainline even before all the stuff with TI recently.

Looking at your report the reason I didn't reply myself is most likely
to be a combination of my expectation that someone from TI would look at
OMAP problems (at the time there were hundreds of people working on
OMAP) and the lack of detail in your mail - the bisection report was a
bit unclear as you said that you'd reverted the patch "plus a couple of
associated patches" without saying what exactly you'd backed out and
there was no analysis of the problem to engage with.


signature.asc
Description: Digital signature

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote:

> Sure. It must be a clock driver. I already have similar driver (for McPDM fclk
> clock) for twl6040.
> Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
> driver soon (after writing it and testing it). It is going to be for 3.9 but
> we can roll it with us I think locally to resolv issues.

Well, we still haven't got the foggiest idea what the actual problem is
beyond that it's probably related to the 32kHz clock in some way (unless
it was one of the other reverts that coincidentally made a difference,
but we don't know what they were) so it's unlikely that just randomly
implementing clock support is going to fix anything immediately here.


signature.asc
Description: Digital signature

RE: Why Linux kernel forced to enter X2APIC mode( just because of booting cpu has supported x2apic) without depending on BIOS' setting in MSR->x2apic enablement bit ?

Hi Yinghai , 

Actually ,my question like this: 
OS can really enable x2apic correctly without BIOS' help in this case : 
BIOS has claimed definitely it doesn't enable x2apic ,but OS feel it can enable 
x2apic(based on BSP supports x2apic) ).

If Linux don't need BIOS' help , how did linux kernel reach this action? 
I am reading this related code, I just see Linux kernel judge cpu_has_x2apic() 
,if yes, it will set MSR, certainly , IR works right. 
We can think BIOS' supporting is not necessary ? 

Thanks very much . 
-- Bob(LinBao Zhang)
HP linux kernel enginner

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 4/5] clockevents: Add generic timer broadcast function

[Mark Rutland]

On Tue, Dec 18, 2012 at 10:17:13PM +, Stephen Boyd wrote:
> Minor nit
> 
> On 12/18/12 04:06, Mark Rutland wrote:
> > diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
> > index c2dd022..ec22a80 100644
> > --- a/kernel/time/tick-broadcast.c
> > +++ b/kernel/time/tick-broadcast.c
> > @@ -86,6 +87,12 @@ int tick_is_broadcast_device(struct clock_event_device 
> > *dev)
> > return (dev && tick_broadcast_device.evtdev == dev);
> >  }
> >  
> > +static void err_broadcast(const struct cpumask *mask)
> > +{
> > +   pr_crit_once("Attempted to broadcast tick, but no broadcast mechanism "
> > +"present. Some CPUs may be unresponsive.");
> 
> This is missing a newline. You may also want to put the string on a
> single line so we can easily grep for it in the sources.

Whoops, fixed. I'll change both strings to be single line.

> > @@ -105,6 +112,14 @@ int tick_device_uses_broadcast(struct 
> > clock_event_device *dev, int cpu)
> >  */
> > if (!tick_device_is_functional(dev)) {
> > dev->event_handler = tick_handle_periodic;
> > +   if (!dev->broadcast)
> > +   dev->broadcast = tick_broadcast;
> > +   if (!dev->broadcast) {
> > +   pr_warn_once("%s depends on broadcast, but no "
> > +"broadcast function available\n",
> 
> Same one line comment here. I thought checkpatch didn't complain anymore.

In fact it actively warns. Not sure how I missed that.

Thanks,
Mark.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

On Wed, 2012-12-19 at 10:28 +, Mark Brown wrote:
> On Wed, Dec 19, 2012 at 12:01:57PM +0200, Luciano Coelho wrote:
> 
> > I think one of the reasons not many people use the mainline with TWL is
> > exactly because something seems to break on every new kernel release.
> > I'm one of those who care and report things when I see them.
> 
> Well, it's a recursive thing - nobody works on mainline, nobody reviews
> mainline code and therefore you shouldn't be surprised if there's
> issues.

Sure, it's a vicious circle.  In any case, I still endure using it and
going against the flow. ;)


> > I think saying that it is not important because only one person reported
> > it is not a good excuse.  I would at least have liked seeing an answer
> > saying, "this can't be fixed because of this and that" or "can you try
> > to fix it by doing this or that".
> 
> That's not what I'm saying.  What I'm saying is that it's clearly not
> the case that OMAP is completely broken here or anything, it appears to
> be one particular system which it appears vanishingly few people cared
> about in mainline even before all the stuff with TI recently.

You're right.  I also had problems with MMC in a Pandaboard too, but I
didn't even bother investigating it (yet) because I can use my other
setup.


> Looking at your report the reason I didn't reply myself is most likely
> to be a combination of my expectation that someone from TI would look at
> OMAP problems (at the time there were hundreds of people working on
> OMAP) and the lack of detail in your mail - the bisection report was a
> bit unclear as you said that you'd reverted the patch "plus a couple of
> associated patches" without saying what exactly you'd backed out and
> there was no analysis of the problem to engage with.

Right, my report was a bit vague indeed.  What I meant by "plus a couple
of associated patches" was the things that would break compilation if I
reverted only the patch in question.  Most likely I ended up reverting
your whole patchset.

I didn't provide further analysis because I had already spent too much
time trying to figure out how to get my stuff to work.  Reverting the
patches locally and hoping someone would respond to my report was good
enough for me at the time.

I also agree that someone from OMAP should have picked it up, but my
report went out exactly when the bomb was exploding inside TI.  So that
probably explains it.

--
Cheers,
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

On Wed, 2012-12-19 at 10:32 +, Mark Brown wrote:
> On Wed, Dec 19, 2012 at 11:18:11AM +0100, Peter Ujfalusi wrote:
> 
> > Sure. It must be a clock driver. I already have similar driver (for McPDM 
> > fclk
> > clock) for twl6040.
> > Let me check linux-next, if CCF is there for OMAP I can send the 32k clock
> > driver soon (after writing it and testing it). It is going to be for 3.9 but
> > we can roll it with us I think locally to resolv issues.
> 
> Well, we still haven't got the foggiest idea what the actual problem is
> beyond that it's probably related to the 32kHz clock in some way (unless
> it was one of the other reverts that coincidentally made a difference,
> but we don't know what they were) so it's unlikely that just randomly
> implementing clock support is going to fix anything immediately here.

This is exactly what I had to revert (as I mentioned in the other email,
I had to revert the other patches otherwise compilation would break):

0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
029dd3ce "regulator: twl: Remove another unused variable warning"

Let me know if you need more info.

--
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] virtio: add functions for piecewise addition of buffers

[Stefan Hajnoczi]

On Tue, Dec 18, 2012 at 01:32:48PM +0100, Paolo Bonzini wrote:
> +/**
> + * virtqueue_start_buf - start building buffer for the other end
> + * @vq: the struct virtqueue we're talking about.
> + * @buf: a struct keeping the state of the buffer
> + * @data: the token identifying the buffer.
> + * @count: the number of buffers that will be added

Perhaps count should be named count_bufs or num_bufs.

> + * @count_sg: the number of sg lists that will be added

What is the purpose of count_sg?

Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 11:45 AM, Luciano Coelho wrote:
>> Well, we still haven't got the foggiest idea what the actual problem is
>> beyond that it's probably related to the 32kHz clock in some way (unless
>> it was one of the other reverts that coincidentally made a difference,
>> but we don't know what they were) so it's unlikely that just randomly
>> implementing clock support is going to fix anything immediately here.
> 
> This is exactly what I had to revert (as I mentioned in the other email,
> I had to revert the other patches otherwise compilation would break):
> 
> 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> 029dd3ce "regulator: twl: Remove another unused variable warning"

Yeah. 32k clock is not provided by twl.

As I said I need to take a look at CCF to see if it already there. If it is
clock driver + mapping + patch for wl12xx should fix the issue you are facing.

> Let me know if you need more info.

BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
added there:
f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.

Which means that _essential_ clocks and pads are no longer configured.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] of: Fix export of of_find_matching_node_and_match()

[Grant Likely]

Commit 50c8af4cf9, "of: introduce for_each_matching_node_and_match()"
renamed of_find_matching_node() to of_find_matching_node_and_match() and
created a new static inline of_find_matching_node() wrapper around the
new name. However, the change neglected to change the EXPORT_SYMBOL()
reference causing build errors for modules.

This patch fixes the EXPORT_SYMBOL() statement. Discovered on a PowerPC
Efika build with the mpc52xx_uart driver being built as a module.

Reported-by: Benjamin Herrenschmidt 
Signed-off-by: Grant Likely 
Cc: Stephen Warren 
Cc: Rob Herring 
Cc: Anatolij Gustschin 
---

I'll push this patch out to my tree ASAP.

 drivers/of/base.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index db8d211..2390ddb 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -629,7 +629,7 @@ struct device_node *of_find_matching_node_and_match(struct 
device_node *from,
read_unlock(&devtree_lock);
return np;
 }
-EXPORT_SYMBOL(of_find_matching_node);
+EXPORT_SYMBOL(of_find_matching_node_and_match);
 
 /**
  * of_modalias_node - Lookup appropriate modalias for a device node
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Peter Ujfalusi]

On 12/19/2012 11:56 AM, Peter Ujfalusi wrote:
> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> added there:
> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> 
> Which means that _essential_ clocks and pads are no longer configured.

Meanwhile you can try to hack the u-boot to enable the 32k from there. It is
going to stay up since we do not have code to control it in the kernel anymore.

Also do something like this at the same time to get things working:
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index cbc9bdb..b0ff1ec 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -271,4 +271,8 @@

 #define CONFIG_SYS_THUMB_BUILD

+/* Configure all pins and clocks */
+#define CONFIG_SYS_ENABLE_PADS_ALL
+#define CONFIG_SYS_CLOCKS_ENABLE_ALL
+
 #endif /* __CONFIG_OMAP4_COMMON_H */

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Mark Brown]

On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
> On 12/19/2012 11:45 AM, Luciano Coelho wrote:

> > 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> > e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> > 029dd3ce "regulator: twl: Remove another unused variable warning"

> Yeah. 32k clock is not provided by twl.

If these changes do anything to the platform I'd expect them to be
leaving the clock enabled instead of disabling it...


signature.asc
Description: Digital signature

Re: [PATCH] of: Fix export of of_find_matching_node_and_match()

[Grant Likely]

On Wed, Dec 19, 2012 at 10:58 AM, Grant Likely
 wrote:
> Commit 50c8af4cf9, "of: introduce for_each_matching_node_and_match()"
> renamed of_find_matching_node() to of_find_matching_node_and_match() and
> created a new static inline of_find_matching_node() wrapper around the
> new name. However, the change neglected to change the EXPORT_SYMBOL()
> reference causing build errors for modules.
>
> This patch fixes the EXPORT_SYMBOL() statement. Discovered on a PowerPC
> Efika build with the mpc52xx_uart driver being built as a module.
>
> Reported-by: Benjamin Herrenschmidt 
> Signed-off-by: Grant Likely 
> Cc: Stephen Warren 
> Cc: Rob Herring 
> Cc: Anatolij Gustschin 

Rob, I've just pushed this out to my devicetree/merge branch. If
you've got any fixes queued up for Linus, then please pull this in
before sending them on to him. Otherwise I'll send Linus a pull req
for this fix this evening. Ether way, please reply to let me know what
you're going to do.

g.

The following changes since commit 752451f01c4567b506bf4343082682dbb8fb30dd:

  Merge branch 'i2c-embedded/for-next' of
git://git.pengutronix.de/git/wsa/linux (2012-12-18 16:51:10 -0800)

are available in the git repository at:

  git://git.secretlab.ca/git/linux-2.6 devicetree/merge

for you to fetch changes up to 80c2022e5645a1a789531d13010292c5c18bf1db:

  of: Fix export of of_find_matching_node_and_match() (2012-12-19
10:58:53 +)


Grant Likely (1):
  of: Fix export of of_find_matching_node_and_match()

 drivers/of/base.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

> ---
>
> I'll push this patch out to my tree ASAP.
>
>  drivers/of/base.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index db8d211..2390ddb 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -629,7 +629,7 @@ struct device_node 
> *of_find_matching_node_and_match(struct device_node *from,
> read_unlock(&devtree_lock);
> return np;
>  }
> -EXPORT_SYMBOL(of_find_matching_node);
> +EXPORT_SYMBOL(of_find_matching_node_and_match);
>
>  /**
>   * of_modalias_node - Lookup appropriate modalias for a device node
> --
> 1.7.10.4
>



--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2] usb: gadget zero: avoid unnecessary reinit of data in f_sourcesink

[Armando Visconti]

In the IN case, since the USB request is allocated only when
the source/sink function is started and never freed, the USB ept
buffer needs to be initialized only at the beginning. This change
results into a more performant g_zero module, especially when
'pattern=1' is selected.

Signed-off-by: Armando Visconti 
Reviewed-by: Sebastian Andrzej Siewior 
---
This is patch V2, after Sbatian's review. Patch is very simple, but
my assumption needs to be cross-verified. This patch has been
quickly tested using a DWC3 controller gadget device.

Felipe, if you can quicly take a look at it..

Armando

 drivers/usb/gadget/f_sourcesink.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/f_sourcesink.c 
b/drivers/usb/gadget/f_sourcesink.c
index 3c126fd..534cf8c 100644
--- a/drivers/usb/gadget/f_sourcesink.c
+++ b/drivers/usb/gadget/f_sourcesink.c
@@ -536,8 +536,7 @@ static void source_sink_complete(struct usb_ep *ep, struct 
usb_request *req)
check_read_data(ss, req);
if (pattern != 2)
memset(req->buf, 0x55, req->length);
-   } else
-   reinit_write_data(ep, req);
+   }
break;
 
/* this endpoint is normally active while we're configured */
-- 
1.7.4.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH] Fix Intel IOMMU support for Marvell 88SE91xx SATA controllers.

[Andrew Cooks]

This is my second attempt to make Marvell 88SE91xx SATA controllers work when 
IOMMU is enabled.[1][2] 
As suggested, it no longer tries to add support for phantom functions.

What's missing:
* No AMD support. I need some help with this.
* Table of affected chip IDs is incomplete. I think 0x9123, 0x9125, 0x9128 are 
also affected.

Patch is against 3.7.1

Review and feedback would be appreciated.

1. https://bugzilla.redhat.com/show_bug.cgi?id=757166
2. https://bugzilla.kernel.org/show_bug.cgi?id=42679

Signed-off-by: Andrew Cooks 
---
 drivers/iommu/intel-iommu.c |   36 ++--
 drivers/pci/quirks.c|   34 ++
 include/linux/pci.h |1 +
 3 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0badfa4..17e64c0 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1672,6 +1674,31 @@ static int domain_context_mapping_one(struct dmar_domain 
*domain, int segment,
return 0;
 }
 
+/* For buggy devices like Marvell 88SE91xx chips that use unclaimed
+ * functions.
+ */
+static int map_quirky_dma_fn(struct dmar_domain *domain,
+   struct pci_dev *pdev,
+   int translation)
+{
+   u8 fn;
+   int err = 0;
+
+   for (fn = 1; fn < 8; fn++) {
+   if (pci_func_is_dma_source(pdev, fn)) {
+   err = domain_context_mapping_one(domain,
+   pci_domain_nr(pdev->bus),
+   pdev->bus->number,
+   PCI_DEVFN(PCI_SLOT(pdev->devfn), fn),
+   translation);
+   if (err)
+   return err;
+   dev_dbg(&pdev->dev, "func: %d mapped dma quirk", fn);
+   }
+   }
+   return 0;
+}
+
 static int
 domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev,
int translation)
@@ -1685,6 +1712,11 @@ domain_context_mapping(struct dmar_domain *domain, 
struct pci_dev *pdev,
if (ret)
return ret;
 
+   /* quirk for undeclared pci functions */
+   ret = map_quirky_dma_fn(domain, pdev, translation);
+   if (ret)
+   return ret;
+
/* dependent device mapping */
tmp = pci_find_upstream_pcie_bridge(pdev);
if (!tmp)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 7a451ff..8d02bac 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3227,6 +3227,40 @@ static const struct pci_dev_dma_source {
{ 0 }
 };
 
+static const struct pci_dev_dma_source_funcs {
+   u16 vendor;
+   u16 device;
+   u8 func_map;/* bit map. lsb is fn 0. */
+} pci_dev_dma_source_funcs[] = {
+{0x1b4b, 0x9172, (1<<0)|(1<<1)},
+{ 0 }, 
+};
+
+static u8 pci_get_dma_source_map(struct pci_dev *dev)
+{
+   const struct pci_dev_dma_source_funcs *i;
+
+   for (i = pci_dev_dma_source_funcs; i->func_map; i++) {
+   if ((i->vendor == dev->vendor ||
+i->vendor == (u16)PCI_ANY_ID) &&
+   (i->device == dev->device ||
+i->device == (u16)PCI_ANY_ID)) {
+   return i->func_map; 
+   }
+   }
+   return 0;
+}
+
+int pci_func_is_dma_source(struct pci_dev *dev, int fn)
+{
+   u8 fn_map = pci_get_dma_source_map(dev);
+
+   if (fn_map & (1 << fn))
+   return 1;
+
+   return 0;
+}
+
 /*
  * IOMMUs with isolation capabilities need to be programmed with the
  * correct source ID of a device.  In most cases, the source ID matches
diff --git a/include/linux/pci.h b/include/linux/pci.h
index ee21795..8f0fa7f 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1546,6 +1546,7 @@ enum pci_fixup_pass {
 #ifdef CONFIG_PCI_QUIRKS
 void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
 struct pci_dev *pci_get_dma_source(struct pci_dev *dev);
+int pci_func_is_dma_source(struct pci_dev *dev, int fn);
 int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
 #else
 static inline void pci_fixup_device(enum pci_fixup_pass pass,
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Luciano Coelho]

On Wed, 2012-12-19 at 11:56 +0100, Peter Ujfalusi wrote:
> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
> >> Well, we still haven't got the foggiest idea what the actual problem is
> >> beyond that it's probably related to the 32kHz clock in some way (unless
> >> it was one of the other reverts that coincidentally made a difference,
> >> but we don't know what they were) so it's unlikely that just randomly
> >> implementing clock support is going to fix anything immediately here.
> > 
> > This is exactly what I had to revert (as I mentioned in the other email,
> > I had to revert the other patches otherwise compilation would break):
> > 
> > 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> > e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> > 029dd3ce "regulator: twl: Remove another unused variable warning"
> 
> Yeah. 32k clock is not provided by twl.
> 
> As I said I need to take a look at CCF to see if it already there. If it is
> clock driver + mapping + patch for wl12xx should fix the issue you are facing.
> 
> > Let me know if you need more info.
> 
> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> added there:
> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> 
> Which means that _essential_ clocks and pads are no longer configured.

Actually no, I haven't updated my u-boot for a while.  I'll check if
that improves things.

--
Luca.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH rev.2 1/6] ACPI: Separate adding ACPI device objects from probing ACPI drivers

[Rafael J. Wysocki]

On Tuesday, December 18, 2012 04:19:55 PM Bjorn Helgaas wrote:
> On Tue, Dec 18, 2012 at 4:00 PM, Rafael J. Wysocki  wrote:
> > On Tuesday, December 18, 2012 03:15:12 PM Toshi Kani wrote:
> >> On Tue, 2012-12-18 at 22:57 +0100, Rafael J. Wysocki wrote:
> >> > On Tuesday, December 18, 2012 09:10:41 AM Toshi Kani wrote:
> >> > > On Tue, 2012-12-18 at 02:48 +0100, Rafael J. Wysocki wrote:
> >>  :
> >> > > We need to decide which module is responsible for calling .bind().  I
> >> > > think it should be the ACPI scan module, not the ACPI PCI root bridge
> >> > > driver, because:
> >> > >  - bind() needs to be called when _ADR device is added.  The ACPI scan
> >> > > module can scan any devices, while the PCI root driver can only scan
> >> > > when it is added.
> >> > >  - acpi_bus_remove() calls unbind() at hot-remove.  The same module
> >> > > should be responsible for both bind() and unbind() handling.
> >> > >  - It is cleaner to keep struct acpi_device_ops interface to be called
> >> > > by the ACPI core.
> >> >
> >> > I agree with that. :-)
> >> >
> >> > Moreover, I don't think we need acpi_pci_bind() and acpi_pci_unbind() at 
> >> > all.
> >> >
> >> > > So, I would propose the following changes.
> >> > >
> >> > >  - Move the acpi_hot_add_bind() call back to the original place after
> >> > > the device_attach() call.
> >> > >  - Rename the name of acpi_hot_add_bind() to something like
> >> > > acpi_bind_adr_device() since it is no longer hot-add only (and is
> >> > > specific to _ADR devices).
> >> > >  - Create its pair function, acpi_unbind_adr_device(), which is called
> >> > > from acpi_bus_remove().  When a constructor interface is introduced, 
> >> > > its
> >> > > destructor should be introduced as well.
> >> > >  - Remove the binding procedure from acpi_pci_root_add().  This should
> >> > > be done in patch [2/6].
> >> >
> >> > Well, what about moving the code from acpi_pci_bind()/acpi_pci_unbind()
> >> > somewhere else and removing those things altogether?
> >>
> >> Sounds nice.  It will be bonus point if you can do that. :-)
> >
> > I think I can, but I need a few more patches on top of what I've already 
> > posted
> > to do that.
> >
> > I think that https://patchwork.kernel.org/patch/1889821/ and
> > https://patchwork.kernel.org/patch/1884701/ can stay as they are, since 
> > there's
> > some material on top of them already and I'll cut the new patches on top of 
> > all
> > that.  I'll repost the whole series some time later this week, stay tuned. 
> > :-)
> 
> I haven't follow this closely enough to give useful feedback, but I
> trust that what you're doing is going in the right direction.

Cool. :-)

> The only question I have right now is what I mentioned earlier on IRC,
> namely, the idea of "binding" an ACPI handle or device to a pci_dev,
> and whether there's a way to guarantee that the binding doesn't become
> stale.  For example, if we bind pci_dev A to acpi_device B, I think we
> essentially capture the pointer to B and store that pointer in A.
> Obviously we want to know that the captured pointer in A remains valid
> as long as A exists, but I don't know what assures us of that.

This really is a bit more complicated.

First, what we store in A is not a pointer to B, but rather the corresponding
ACPICA handle, which is guaranteed to live longer that B itself.

Second, we not only store the B's handle in A, but also a pointer to A in B
(in the physical_node_list list).  Moreover, we create the "firmware_node"
sysfs file under A and a "physical_node" sysfs file under B.

All of that becomes invalid when either A or B is removed without notice.

For the removal of A we have acpi_platform_notify() that calls
acpi_unbind_one() which kills all of that stuff, so as long as A is removed
earlier than B, we have no problems.

For the removal of B, however, we seem to assume that if the device is
ejectable, there will be an ACPI driver bound to B (ie. the struct acpi_device)
that will take care of the removal of the physical nodes associated with it
before B itself is removed.  At least that's my understanding of the current
code.  Moreover, I'm not sure if this assumption is universally satisfied.

> I don't think this is a new question; I have the same question about
> the current code before your changes.  But it seems like you're
> simplifying this area in a way that might make it easier to answer the
> question.

Well, my patches are not likely to make things worse in this area. :-)

Anyway, I think we should make acpi_bus_scan(), or even acpi_bus_add() after
my changes, mutually exclusive with acpi_bus_trim(), because that will ensure
that we won't be removing ACPI device objects while setting them up (or the
other way around).  That would require us to redesign some ACPI drivers first,
though, because they call acpi_bus_trim() in their initialization code paths
(I don't really think they should be doing that).

Moreover, I think we should make the ACPI core trigger the removal of all
ph

Re: [PATCH v2 1/6] Add header files and Kbuild plumbing for SI476x MFD core

[Mark Brown]

On Tue, Dec 18, 2012 at 07:07:28PM -0800, Andrey Smirnov wrote:
> On 12-12-18 11:37 AM, Mauro Carvalho Chehab wrote:
> >Em Mon, 8 Oct 2012 11:38:01 -0700
> >Andrey Smirnov  escreveu:

Guys, please delete irrelevant context from mails.  I just TL;DRed this
so if there's anything you're expecting from me on this please let me
know.

> >
> >>On 10/08/2012 01:43 AM, Hans Verkuil wrote:
> >>>On Sat October 6 2012 03:54:57 Andrey Smirnov wrote:
> This patch adds all necessary header files and Kbuild plumbing for the
> core driver for Silicon Laboratories Si476x series of AM/FM tuner
> chips.
> 
> The driver as a whole is implemented as an MFD device and this patch
> adds a core portion of it that provides all the necessary
> functionality to the two other drivers that represent radio and audio
> codec subsystems of the chip.
> 
> Signed-off-by: Andrey Smirnov 
> ---
>   drivers/mfd/Kconfig |   14 ++
>   drivers/mfd/Makefile|3 +
>   include/linux/mfd/si476x-core.h |  529 
>  +++
>   include/media/si476x.h  |  449 +
>   4 files changed, 995 insertions(+)
>   create mode 100644 include/linux/mfd/si476x-core.h
>   create mode 100644 include/media/si476x.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index b1a1462..3fab06d 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -895,6 +895,20 @@ config MFD_WL1273_CORE
> driver connects the radio-wl1273 V4L2 module and the wl1273
> audio codec.
> +config MFD_SI476X_CORE
> + tristate "Support for Silicon Laboratories 4761/64/68 AM/FM radio."
> + depends on I2C
> + select MFD_CORE
> + default n
> + help
> +   This is the core driver for the SI476x series of AM/FM radio. This MFD
> +   driver connects the radio-si476x V4L2 module and the si476x
> +   audio codec.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called si476x-core.
> +
> +
>   config MFD_OMAP_USB_HOST
>   bool "Support OMAP USBHS core driver"
>   depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 79dd22d..942257b 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o 
> rc5t583-irq.o
>   obj-$(CONFIG_MFD_SEC_CORE)  += sec-core.o sec-irq.o
>   obj-$(CONFIG_MFD_ANATOP)+= anatop-mfd.o
>   obj-$(CONFIG_MFD_LM3533)+= lm3533-core.o lm3533-ctrlbank.o
> +
> +si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
> +obj-$(CONFIG_MFD_SI476X_CORE)+= si476x-core.o
> diff --git a/include/linux/mfd/si476x-core.h 
> b/include/linux/mfd/si476x-core.h
> new file mode 100644
> index 000..eb6f52a
> --- /dev/null
> +++ b/include/linux/mfd/si476x-core.h
> @@ -0,0 +1,529 @@
> +/*
> + * include/media/si476x-core.h -- Common definitions for si476x core
> + * device
> + *
> + * Copyright (C) 2012 Innovative Converged Devices(ICD)
> + *
> + * Author: Andrey Smirnov 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + */
> +
> +#ifndef SI476X_CORE_H
> +#define SI476X_CORE_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#ifdef DEBUG
> +#define DBG_BUFFER(device, header, buffer, bcount)   
> \
> + do {\
> + dev_info((device), header); \
> + print_hex_dump_bytes("",\
> +  DUMP_PREFIX_OFFSET,\
> +  buffer, bcount);   \
> + } while (0)
> +#else
> +#define DBG_BUFFER(device, header, buffer, bcount)   
> \
> + do {} while (0)
> +#endif
> +
> +enum si476x_freq_suppoted_chips {
> >>>typo: suppoted -> supported
> >>>
> + SI476X_CHIP_SI4761 = 1,
> + SI476X_CHIP_SI4762,
> + SI476X_CHIP_SI4763,
> + SI476X_CHIP_SI4764,
> + SI476X_CHIP_SI4768,
> + SI476X_CHIP_SI476

[PATCH] ACPI: Rework acpi_get_child() to be more efficient

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Observe that acpi_get_child() doesn't need to use the helper
struct acpi_find_child structure and change it to work without it.

Moreover, acpi_get_child() doesn't need to loop any more once it has
found a matching handle, so make it stop in that case.  To prevent
the results from changing, make it use do_acpi_find_child() as a
post-order callback.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/acpi/glue.c |   36 
 1 file changed, 16 insertions(+), 20 deletions(-)

Index: linux/drivers/acpi/glue.c
===
--- linux.orig/drivers/acpi/glue.c
+++ linux/drivers/acpi/glue.c
@@ -90,38 +90,34 @@ static int acpi_find_bridge_device(struc
return ret;
 }
 
-/* Get device's handler per its address under its parent */
-struct acpi_find_child {
-   acpi_handle handle;
-   u64 address;
-};
-
-static acpi_status
-do_acpi_find_child(acpi_handle handle, u32 lvl, void *context, void **rv)
+static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used,
+ void *addr_p, void **ret_p)
 {
-   acpi_status status;
struct acpi_device_info *info;
-   struct acpi_find_child *find = context;
 
-   status = acpi_get_object_info(handle, &info);
-   if (ACPI_SUCCESS(status)) {
-   if ((info->address == find->address)
-   && (info->valid & ACPI_VALID_ADR))
-   find->handle = handle;
-   kfree(info);
+   if (ACPI_SUCCESS(acpi_get_object_info(handle, &info))) {
+   bool found = info->address == *((u64 *)addr_p)
+   && (info->valid & ACPI_VALID_ADR);
+
+   ACPI_FREE(info);
+   if (found) {
+   *ret_p = handle;
+   return AE_CTRL_TERMINATE;
+   }
}
return AE_OK;
 }
 
 acpi_handle acpi_get_child(acpi_handle parent, u64 address)
 {
-   struct acpi_find_child find = { NULL, address };
+   void *ret = NULL;
 
if (!parent)
return NULL;
-   acpi_walk_namespace(ACPI_TYPE_DEVICE, parent,
-   1, do_acpi_find_child, NULL, &find, NULL);
-   return find.handle;
+
+   acpi_walk_namespace(ACPI_TYPE_DEVICE, parent, 1, NULL,
+   do_acpi_find_child, &address, &ret);
+   return (acpi_handle)ret;
 }
 
 EXPORT_SYMBOL(acpi_get_child);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] proc: fix inconsistent lock state

[Xiaotian Feng]

Lockdep found an inconsistent lock state when rcu is processing
delayed work in softirq. Currently, kernel is using spin_lock/spin_unlock
to protect proc_inum_ida, but proc_free_inum is called by rcu in softirq
context.

Use spin_lock_bh/spin_unlock_bh fix following lockdep warning.

[   49.709127] =
[   49.709360] [ INFO: inconsistent lock state ]
[   49.709593] 3.7.0 #36 Not tainted
[   49.709846] -
[   49.710080] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   49.710377] swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   49.710640]  (proc_inum_lock){+.?...}, at: []
proc_free_inum+0x1c/0x50
[   49.711287] {SOFTIRQ-ON-W} state was registered at:
[   49.711540]   [] __lock_acquire+0x8ae/0xca0
[   49.711896]   [] lock_acquire+0x199/0x200
[   49.712242]   [] _raw_spin_lock+0x41/0x50
[   49.712590]   [] proc_alloc_inum+0x4c/0xd0
[   49.712941]   [] alloc_mnt_ns+0x49/0xc0
[   49.713282]   [] create_mnt_ns+0x25/0x70
[   49.713625]   [] mnt_init+0x161/0x1c7
[   49.713962]   [] vfs_caches_init+0x107/0x11a
[   49.714392]   [] start_kernel+0x348/0x38c
[   49.714815]   [] x86_64_start_reservations+0x131/0x136
[   49.715279]   [] x86_64_start_kernel+0x103/0x112
[   49.715728] irq event stamp: 2993422
[   49.716006] hardirqs last  enabled at (2993422):
[] _raw_spin_unlock_irqrestore+0x55/0x80
[   49.716661] hardirqs last disabled at (2993421):
[] _raw_spin_lock_irqsave+0x29/0x70
[   49.717300] softirqs last  enabled at (2993394):
[] _local_bh_enable+0x13/0x20
[   49.717920] softirqs last disabled at (2993395):
[] call_softirq+0x1c/0x30
[   49.718528]
[   49.718528] other info that might help us debug this:
[   49.718992]  Possible unsafe locking scenario:
[   49.718992]
[   49.719433]CPU0
[   49.719669]
[   49.719902]   lock(proc_inum_lock);
[   49.720308]   
[   49.720548] lock(proc_inum_lock);
[   49.720961]
[   49.720961]  *** DEADLOCK ***
[   49.720961]
[   49.721477] no locks held by swapper/1/0.
[   49.721769]
[   49.721769] stack backtrace:
[   49.722150] Pid: 0, comm: swapper/1 Not tainted 3.7.0 #36
[   49.722555] Call Trace:
[   49.722787][] ? vprintk_emit+0x471/0x510
[   49.723307]  [] print_usage_bug+0x2a5/0x2c0
[   49.723671]  [] mark_lock+0x33b/0x5e0
[   49.724014]  [] __lock_acquire+0x813/0xca0
[   49.724374]  [] ? trace_hardirqs_on+0xd/0x10
[   49.724741]  [] lock_acquire+0x199/0x200
[   49.725095]  [] ? proc_free_inum+0x1c/0x50
[   49.725455]  [] _raw_spin_lock+0x41/0x50
[   49.725806]  [] ? proc_free_inum+0x1c/0x50
[   49.726165]  [] proc_free_inum+0x1c/0x50
[   49.726519]  [] ? put_pid+0x42/0x60
[   49.726857]  [] free_pid_ns+0x1c/0x50
[   49.727201]  [] put_pid_ns+0x2e/0x50
[   49.727540]  [] put_pid+0x4a/0x60
[   49.727868]  [] delayed_put_pid+0x12/0x20
[   49.728225]  [] rcu_process_callbacks+0x462/0x790
[   49.728606]  [] __do_softirq+0x1b4/0x3b0
[   49.728959]  [] ? clockevents_program_event+0xc2/0xf0
[   49.729354]  [] call_softirq+0x1c/0x30
[   49.729702]  [] do_softirq+0x59/0xd0
[   49.730039]  [] irq_exit+0x54/0xd0
[   49.730370]  [] smp_apic_timer_interrupt+0x95/0xa3
[   49.730755]  [] apic_timer_interrupt+0x72/0x80
[   49.731124][] ? retint_restore_args+0x13/0x13
[   49.731658]  [] ? cpuidle_wrap_enter+0x55/0xa0
[   49.732029]  [] ? cpuidle_wrap_enter+0x51/0xa0
[   49.732399]  [] cpuidle_enter_tk+0x10/0x20
[   49.732759]  [] cpuidle_enter_state+0x17/0x50
[   49.733128]  [] cpuidle_idle_call+0x287/0x520
[   49.733496]  [] cpu_idle+0xba/0x130
[   49.733830]  [] start_secondary+0x2b3/0x2bc

Signed-off-by: Xiaotian Feng 
Cc: Andrew Morton 
Cc: Al Viro 
Cc: "Eric W. Biederman" 
Cc: linux-kernel@vger.kernel.org
---
 fs/proc/generic.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/proc/generic.c b/fs/proc/generic.c
index 7b3ae3c..e659a0f 100644
--- a/fs/proc/generic.c
+++ b/fs/proc/generic.c
@@ -359,18 +359,18 @@ retry:
if (!ida_pre_get(&proc_inum_ida, GFP_KERNEL))
return -ENOMEM;
 
-   spin_lock(&proc_inum_lock);
+   spin_lock_bh(&proc_inum_lock);
error = ida_get_new(&proc_inum_ida, &i);
-   spin_unlock(&proc_inum_lock);
+   spin_unlock_bh(&proc_inum_lock);
if (error == -EAGAIN)
goto retry;
else if (error)
return error;
 
if (i > UINT_MAX - PROC_DYNAMIC_FIRST) {
-   spin_lock(&proc_inum_lock);
+   spin_lock_bh(&proc_inum_lock);
ida_remove(&proc_inum_ida, i);
-   spin_unlock(&proc_inum_lock);
+   spin_unlock_bh(&proc_inum_lock);
return -ENOSPC;
}
*inum = PROC_DYNAMIC_FIRST + i;
@@ -379,9 +379,9 @@ retry:
 
 void proc_free_inum(unsigned int inum)
 {
-   spin_lock(&proc_inum_lock);
+   spin_lock_bh(&proc_inum_lock);
ida_remove(&proc_inum_ida, inum - PROC_DYNAMIC_FIRST);
-   spin_unlock(&proc_inum_lock);
+   spin_unlock_bh(&proc_inum_lock);
 

Re: [PATCH v3] of: Output devicetree alias names in uevent

[Grant Likely]

On Thu,  6 Dec 2012 14:55:41 -0800, Stepan Moskovchenko 
 wrote:
> In some situations, userspace may want to resolve a
> device by function and logical number (ie, "serial0")
> rather than by the base address or full device path. Being
> able to resolve a device by alias frees userspace from the
> burden of otherwise having to maintain a mapping between
> device addresses and their logical assignments on each
> platform when multiple instances of the same hardware block
> are present in the system.
> 
> Although the uevent device attribute contains devicetree
> compatible information and the full device path, the uevent
> does not list the alises that may have been defined for the
> device.
> 
> Signed-off-by: Stepan Moskovchenko 

I've picked this up into my devicetree/next branch. It will get pushed out to 
linux-next after the merge window closes.

Thanks,
g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/5] virtio-scsi: introduce multiqueue support

[Stefan Hajnoczi]

On Tue, Dec 18, 2012 at 01:32:52PM +0100, Paolo Bonzini wrote:
>  struct virtio_scsi_target_state {
> - /* Never held at the same time as vq_lock.  */
> + /* This spinlock ever held at the same time as vq_lock.  */

s/ever/is never/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/5] Multiqueue virtio-scsi, and API for piecewise buffer submission

[Michael S. Tsirkin]

On Wed, Dec 19, 2012 at 09:52:59AM +0100, Paolo Bonzini wrote:
> Il 18/12/2012 23:18, Rolf Eike Beer ha scritto:
> > Paolo Bonzini wrote:
> >> Hi all,
> >>
> >> this series adds multiqueue support to the virtio-scsi driver, based
> >> on Jason Wang's work on virtio-net.  It uses a simple queue steering
> >> algorithm that expects one queue per CPU.  LUNs in the same target always
> >> use the same queue (so that commands are not reordered); queue switching
> >> occurs when the request being queued is the only one for the target.
> >> Also based on Jason's patches, the virtqueue affinity is set so that
> >> each CPU is associated to one virtqueue.
> >>
> >> I tested the patches with fio, using up to 32 virtio-scsi disks backed
> >> by tmpfs on the host.  These numbers are with 1 LUN per target.
> >>
> >> FIO configuration
> >> -
> >> [global]
> >> rw=read
> >> bsrange=4k-64k
> >> ioengine=libaio
> >> direct=1
> >> iodepth=4
> >> loops=20
> >>
> >> overall bandwidth (MB/s)
> >> 
> >>
> >> # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 
> >> VCPUs
> >> 1  540   626 599
> >> 2  795   965 925
> >> 4  997  13761500
> >> 8 1136  21302060
> >> 161440  22692474
> >> 241408  21792436
> >> 321515  19782319
> >>
> >> (These numbers for single-queue are with 4 VCPUs, but the impact of adding
> >> more VCPUs is very limited).
> >>
> >> avg bandwidth per LUN (MB/s)
> >> 
> >>
> >> # of targetssingle-queuemulti-queue, 4 VCPUsmulti-queue, 8 
> >> VCPUs
> >> 1  540   626 599
> >> 2  397   482 462
> >> 4  249   344 375
> >> 8  142   266 257
> >> 16  90   141 154
> >> 24  5890 101
> >> 32  4761  72
> > 
> > Is there an explanation why 8x8 is slower then 4x8 in both cases?
> 
> Regarding the "in both cases" part, it's because the second table has
> the same data as the first, but divided by the first column.
> 
> In general, the "strangenesses" you find are probably within statistical
> noise or due to other effects such as host CPU utilization or contention
> on the big QEMU lock.
> 
> Paolo
> 

That's exactly what bothers me. If the IOPS divided by host CPU
goes down, then the win on lightly loaded host will become a regression
on a loaded host.

Need to measure that.

>  8x1 and 8x2
> > being slower than 4x1 and 4x2 is more or less expected, but 8x8 loses 
> > against 
> > 4x8 while 8x4 wins against 4x4 and 8x16 against 4x16.
> > 
> > Eike
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] pwm: atmel: add Timer Counter Block PWM driver

[Thierry Reding]

On Mon, Dec 17, 2012 at 12:13:30PM +0100, Boris BREZILLON wrote:
> Hello,
> 
> This patch adds a PWM driver based on Atmel Timer Counter Block.
> Timer Counter Block is used in Waveform generator mode.
> 
> A Timer Counter Block provides up to 6 PWM devices grouped by 2:
> * group 0 = PWM 0 and 1
> * group 1 = PWM 1 and 2
> * group 2 = PMW 3 and 4
> 
> PWM devices in a given group must be configured with the same
> period value.
> If a PWM device in a group tries to change the period value and
> the other device is already configured with a different value an
> error will be returned.
> 
> This driver requires device tree support.
> The Timer Counter Block number used to create a PWM chip is
> given by tc-block field in an "atmel,pwm-tcb" compatible node.

The device tree binding says that the compatible value should be
"atmel,tcb-pwm", not "atmel,pwm-tcb".

> diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt 
> b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> new file mode 100644
> index 000..bd99fdd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt
> @@ -0,0 +1,18 @@
> +Atmel TCB PWM controller
> +
> +Required properties:
> +- compatible: should be "atmel,tcb-pwm"
> +- #pwm-cells: should be 3.  The first cell specifies the per-chip index

"Should be 3." Capital S since you terminate the sentence with a full
stop.

> +  of the PWM to use, the second cell is the period in nanoseconds and
> +  bit 0 in the third cell is used to encode the polarity of PWM output.
> +  Set bit 0 of the third in PWM specifier to 1 for inverse polarity &

"of the third cell"

> +  set to 0 for normal polarity.
> +- tc-block: the Timer Counter block to use as a PWM chip.

Also: "The Timer Counter..." because of the terminating full stop.

> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index e513cd9..2f4941b 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -37,6 +37,18 @@ config PWM_AB8500
> To compile this driver as a module, choose M here: the module
> will be called pwm-ab8500.
>  
> +config PWM_ATMEL_TCB
> + tristate "TC Block PWM"
> + depends on ATMEL_TCLIB && OF
> + help
> +   Generic PWM framework driver for Atmel Timer Counter Block.
> +
> +   A Timer Counter Block provides 6 PWM devices grouped by 2.
> +   Devices in a given group must have the same period.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called pwm-atmel-tc.

The Makefile says it is called pwm-atmel-tc_b_.

> diff --git a/drivers/pwm/pwm-atmel-tcb.c b/drivers/pwm/pwm-atmel-tcb.c
[...]
> +static int atmel_tcb_pwm_set_polarity(struct pwm_chip *chip,
> +   struct pwm_device *pwm,
> +   enum pwm_polarity polarity)

The arguments are no longer properly aligned.

> +static int atmel_tcb_pwm_request(struct pwm_chip *chip,
> +   struct pwm_device *pwm)

Same here.

> + } else
> + cmr = 0;
> + cmr |= ATMEL_TC_WAVE | ATMEL_TC_WAVESEL_UP_AUTO | ATMEL_TC_EEVT_XC0;

There should be a blank line between the above two lines for better
readability.

> + /* If duty is 0 reverse polarity */
> + if (tcbpwm->duty == 0)
> + polarity = !polarity;
> +
> + if (polarity == PWM_POLARITY_INVERSED) {
> + if (index == 0)
> + newcmr |= ATMEL_TC_ASWTRG_CLEAR;
> + else
> + newcmr |= ATMEL_TC_BSWTRG_CLEAR;
> + } else {
> + if (index == 0)
> + newcmr |= ATMEL_TC_ASWTRG_SET;
> + else
> + newcmr |= ATMEL_TC_BSWTRG_SET;
> + }
> +
> + spin_lock(&tcbpwmc->lock);
> + cmr = __raw_readl(regs + ATMEL_TC_REG(group, CMR));
> +
> + /* flush old setting */
> + if (index == 0)
> + cmr &= ~(ATMEL_TC_ACPA | ATMEL_TC_ACPC |
> + ATMEL_TC_AEEVT | ATMEL_TC_ASWTRG);
> + else
> + cmr &= ~(ATMEL_TC_BCPB | ATMEL_TC_BCPC |
> + ATMEL_TC_BEEVT | ATMEL_TC_BSWTRG);

These should be aligned differently:

cmr &= ~(ATMEL_TC_ACPA | ATMEL_TC_ACPC | ATMEL_TC_AEEVT |
 ATMEL_TC_ASWTRG);

Although maybe you should define a mask for this since you reuse the
exact same sequence in atmel_tcb_pwm_enable().

> +
> + /* configure new setting */
> + cmr |= newcmr;
> + __raw_writel(cmr, regs + ATMEL_TC_REG(group, CMR));

I wonder why you bother setting newcmr and OR'ing it into cmr. Couldn't
you just mask all previous settings in cmr first, then OR the new bits?

> +
> + /*
> +  * Use software trigger to apply the new setting.
> +  * If both pwm devices in this group are disabled we stop the clock.

"both PWM devices"

> +  */
> + if (!(cmr & (ATMEL_TC_ACPC | ATMEL_TC_BCPC)))
> + __raw_writel

Re: [RFC 3/3] virtio-balloon: add auto-ballooning support

[Luiz Capitulino]

On Tue, 18 Dec 2012 14:53:30 -0800
Anton Vorontsov  wrote:

> Hello Luiz,
> 
> On Tue, Dec 18, 2012 at 06:16:55PM -0200, Luiz Capitulino wrote:
> > The auto-ballooning feature automatically performs balloon inflate
> > or deflate based on host and guest memory pressure. This can help to
> > avoid swapping or worse in both, host and guest.
> > 
> > Auto-ballooning has a host and a guest part. The host performs
> > automatic inflate by requesting the guest to inflate its balloon
> > when the host is facing memory pressure. The guest performs
> > automatic deflate when it's facing memory pressure itself. It's
> > expected that auto-inflate and auto-deflate will balance each
> > other over time.
> > 
> > This commit implements the host side of auto-ballooning.
> > 
> > To be notified of host memory pressure, this commit makes use of this
> > kernel API proposal being discussed upstream:
> > 
> >  http://marc.info/?l=linux-mm&m=135513372205134&w=2
> 
> Wow, you're fast! And I'm glad that it works for you, so we have two
> full-featured mempressure cgroup users already.

Thanks, although I think we need more testing to be sure this does what
we want. I mean, the basic mechanics does work, but my testing has been
very light so far.

> Even though it is a qemu patch, I think we should Cc linux-mm folks on it,
> just to let them know the great news.

I'll do it next time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 7/7] leds: leds-pwm: Add device tree bindings

[Grant Likely]

Hi Peter,

Thanks for this work. Comments below...

On Wed, 12 Dec 2012 10:04:52 +0100, Peter Ujfalusi  
wrote:
> Support for device tree booted kernel.
> 
> For usage see:
> Documentation/devicetree/bindings/leds/leds-pwm.txt
> 
> Signed-off-by: Peter Ujfalusi 

About commit text: Remember that commit text is the first thing people
are going to see when looking over what changed in a given subsystem. It
is also where maintainers like me look first when trying to decide if a
patch makes sense before applying it. When commit text is bare-bones
like the above and the patch is non-trivial, then I end up trying to
reconstruct your though process or rational for a patch.

So, please, if it is anything beyond a trivial patch then tell us more
than simply "support for device tree booted kernel". What platform did
you make the change for? How was it tested? Are there any notable design
decisions that you made when adding this support? Are there any missing
pieces or possible bugs?

I'm picking on you at the moment, but this is a general comment. The
commit text is where you get to convince me that the patch is needed and
tell me about how it was designed. This is really important information;
particularly for poor random user, bisecting his broken kernel and
landing on your commit. In this small way, you can make her Christmas
merrier this year.


> ---
>  .../devicetree/bindings/leds/leds-pwm.txt  |  48 +
>  drivers/leds/leds-pwm.c| 112 
> +
>  2 files changed, 140 insertions(+), 20 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-pwm.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt 
> b/Documentation/devicetree/bindings/leds/leds-pwm.txt
> new file mode 100644
> index 000..7297107
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
> @@ -0,0 +1,48 @@
> +LED connected to PWM
> +
> +Required properties:
> +- compatible : should be "pwm-leds".
> +
> +Each LED is represented as a sub-node of the pwm-leds device.  Each
> +node's name represents the name of the corresponding LED.
> +
> +LED sub-node properties:
> +- pwms : PWM property to point to the PWM device (phandle)/port (id) and to
> +  specify the period time to be used: <&phandle id period_ns>;
> +- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM 
> device
> +  For the pwms and pwm-names property please refer to:
> +  Documentation/devicetree/bindings/pwm/pwm.txt
> +- max-brightness : Maximum brightness possible for the LED
> +- label :  (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +- linux,default-trigger :  (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +
> +Example:
> +
> +twl_pwm: pwm {
> + /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */
> + compatible = "ti,twl6030-pwm";
> + #pwm-cells = <2>;
> +};
> +
> +twl_pwmled: pwmled {
> + /* provides one PWM (id 0 for Charing indicator LED) */
> + compatible = "ti,twl6030-pwmled";
> + #pwm-cells = <2>;
> +};
> +
> +pwmleds {
> + compatible = "pwm-leds";
> + kpad {
> + label = "omap4::keypad";
> + pwms = <&twl_pwm 0 7812500>;
> + max-brightness = <127>;
> + };
> +
> + charging {
> + label = "omap4:green:chrg";
> + pwms = <&twl_pwmled 0 7812500>;
> + max-brightness = <255>;
> + };

Acked-by: Grant Likely 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/2] virtio_balloon: move locking to the balloon thread

[Rafael Aquini]

On Tue, Dec 18, 2012 at 06:17:29PM -0200, Luiz Capitulino wrote:
> Today, the balloon_lock mutex is taken and released by fill_balloon()
> and leak_balloon() when both functions are entered and when they
> return.
> 
> This commit moves the locking to the caller instead, which is
> the balloon() thread. The balloon thread is the sole caller of those
> functions today.
> 
> The reason for this move is that the next commit will introduce
> a shrinker callback for the balloon driver, which will also call
> leak_balloon() but will require different locking semantics.
> 
> Signed-off-by: Luiz Capitulino 
> ---
>  drivers/virtio/virtio_balloon.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 2a70558..877e695 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -133,7 +133,6 @@ static void fill_balloon(struct virtio_balloon *vb, 
> size_t num)
>   /* We can only do one array worth at a time. */
>   num = min(num, ARRAY_SIZE(vb->pfns));
>  
> - mutex_lock(&vb->balloon_lock);
>   for (vb->num_pfns = 0; vb->num_pfns < num;
>vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
>   struct page *page = balloon_page_enqueue(vb_dev_info);
> @@ -155,7 +154,6 @@ static void fill_balloon(struct virtio_balloon *vb, 
> size_t num)
>   /* Did we get any? */
>   if (vb->num_pfns != 0)
>   tell_host(vb, vb->inflate_vq);
> - mutex_unlock(&vb->balloon_lock);
>  }
>

Since you're removing the locking scheme from within this function, I think it
would be a good idea introduce a comment stating its caller must held the mutex
vb->balloon_lock.

  
>  static void release_pages_by_pfn(const u32 pfns[], unsigned int num)
> @@ -177,7 +175,6 @@ static void leak_balloon(struct virtio_balloon *vb, 
> size_t num)
>   /* We can only do one array worth at a time. */
>   num = min(num, ARRAY_SIZE(vb->pfns));
>  
> - mutex_lock(&vb->balloon_lock);
>   for (vb->num_pfns = 0; vb->num_pfns < num;
>vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
>   page = balloon_page_dequeue(vb_dev_info);
> @@ -193,7 +190,6 @@ static void leak_balloon(struct virtio_balloon *vb, 
> size_t num)
>* is true, we *have* to do it in this order
>*/
>   tell_host(vb, vb->deflate_vq);
> - mutex_unlock(&vb->balloon_lock);
>   release_pages_by_pfn(vb->pfns, vb->num_pfns);
>  }
>

ditto

  
> @@ -306,11 +302,13 @@ static int balloon(void *_vballoon)
>|| freezing(current));
>   if (vb->need_stats_update)
>   stats_handle_request(vb);
> + mutex_lock(&vb->balloon_lock);
>   if (diff > 0)
>   fill_balloon(vb, diff);
>   else if (diff < 0)
>   leak_balloon(vb, -diff);
>   update_balloon_size(vb);
> + mutex_unlock(&vb->balloon_lock);
>   }
>   return 0;
>  }

Just a nitpick:
As leak_balloon() is also called at remove_common(), you'll need to introduce 
the
mutex there, similarly.


Thanks for move this forward.

Cheers!
-- Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 25/26] aio: use xchg() instead of completion_lock

[Hillf Danton]

>@@ -686,9 +685,10 @@ void aio_complete(struct kiocb *iocb, long res, long res2)
>* ctx->ctx_lock to prevent other code from messing with the tail
>* pointer since we might be called from irq context.
>*/

Well the comment is stale.

Hillf
>-  spin_lock_irqsave(&ctx->completion_lock, flags);
>+  local_irq_save(flags);
>+  while ((tail = xchg(&ctx->tail, UINT_MAX)) == UINT_MAX)
>+  cpu_relax();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] virtio: add functions for piecewise addition of buffers

[Paolo Bonzini]

Il 19/12/2012 11:47, Stefan Hajnoczi ha scritto:
> On Tue, Dec 18, 2012 at 01:32:48PM +0100, Paolo Bonzini wrote:
>> +/**
>> + * virtqueue_start_buf - start building buffer for the other end
>> + * @vq: the struct virtqueue we're talking about.
>> + * @buf: a struct keeping the state of the buffer
>> + * @data: the token identifying the buffer.
>> + * @count: the number of buffers that will be added
> 
> Perhaps count should be named count_bufs or num_bufs.

Ok.

>> + * @count_sg: the number of sg lists that will be added
> 
> What is the purpose of count_sg?

It is needed to decide whether to use an indirect or a direct buffer.
The idea is to avoid a memory allocation if the driver is providing us
with separate sg elements (under the assumption that they will be few).

Originally I wanted to use a mix of direct and indirect buffer (direct
if add_buf received a one-element scatterlist, otherwise indirect).  It
would have had the same effect, without having to specify count_sg in
advance.  The spec is not clear if that is allowed or not, but in the
end they do not work with either QEMU or vhost, so I chose this
alternative instead.

Paolo


> Stefan
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/26] aio: remove retry-based AIO

[Hillf Danton]

>@@ -52,15 +46,6 @@ struct kioctx;
>  * not ask the method again -- ki_retry must ensure forward progress.
>  * aio_complete() must be called once and only once in the future, multiple
>  * calls may result in undefined behaviour.
>- *
>- * If ki_retry returns -EIOCBRETRY it has made a promise that kick_iocb()
>- * will be called on the kiocb pointer in the future.  This may happen
>- * through generic helpers that associate kiocb->ki_wait with a wait
>- * queue head that ki_retry uses via current->io_wait.  It can also happen
>- * with custom tracking and manual calls to kick_iocb(), though that is
>- * discouraged.  In either case, kick_iocb() must be called once and only
>- * once.  ki_retry must ensure forward progress, the AIO core will wait
>- * indefinitely for kick_iocb() to be called.
>  */
> struct kiocb {
>   struct list_headki_run_list;

Then you can also erase ki_run_list if no longer used.

Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/26] aio: Kill return value of aio_complete()

[Hillf Danton]

>@@ -594,7 +591,7 @@ static struct kioctx *lookup_ioctx(unsigned long ctx_id)
>  *Returns true if this is the last user of the request.  The
>  *only other user of the request can be the cancellation code.
>  */

Well the comment is stale.

Hillf

>-int aio_complete(struct kiocb *iocb, long res, long res2)
>+void aio_complete(struct kiocb *iocb, long res, long res2)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] proc: fix inconsistent lock state

[Eric W. Biederman]

Xiaotian Feng  wrote:

>Lockdep found an inconsistent lock state when rcu is processing
>delayed work in softirq. Currently, kernel is using
>spin_lock/spin_unlock
>to protect proc_inum_ida, but proc_free_inum is called by rcu in
>softirq
>context.

Emarassing.  Thank you for finding this.

Something doesn't feel right.   I don't think there should be a path where we 
get to proc_free_inum from bh context.

Rcu callbacks should be running in process context (if a special one). 

I need to sleep on this one but do_softirq -> rcu_process_callbacks seems wrong.

I will dig into this more after I have finished sleeping.  What rcu options do 
you have selected?

Eric

>Use spin_lock_bh/spin_unlock_bh fix following lockdep warning.
>
>[   49.709127] =
>[   49.709360] [ INFO: inconsistent lock state ]
>[   49.709593] 3.7.0 #36 Not tainted
>[   49.709846] -
>[   49.710080] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
>[   49.710377] swapper/1/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
>[   49.710640]  (proc_inum_lock){+.?...}, at: []
>proc_free_inum+0x1c/0x50
>[   49.711287] {SOFTIRQ-ON-W} state was registered at:
>[   49.711540]   [] __lock_acquire+0x8ae/0xca0
>[   49.711896]   [] lock_acquire+0x199/0x200
>[   49.712242]   [] _raw_spin_lock+0x41/0x50
>[   49.712590]   [] proc_alloc_inum+0x4c/0xd0
>[   49.712941]   [] alloc_mnt_ns+0x49/0xc0
>[   49.713282]   [] create_mnt_ns+0x25/0x70
>[   49.713625]   [] mnt_init+0x161/0x1c7
>[   49.713962]   [] vfs_caches_init+0x107/0x11a
>[   49.714392]   [] start_kernel+0x348/0x38c
>[   49.714815]   []
>x86_64_start_reservations+0x131/0x136
>[   49.715279]   [] x86_64_start_kernel+0x103/0x112
>[   49.715728] irq event stamp: 2993422
>[   49.716006] hardirqs last  enabled at (2993422):
>[] _raw_spin_unlock_irqrestore+0x55/0x80
>[   49.716661] hardirqs last disabled at (2993421):
>[] _raw_spin_lock_irqsave+0x29/0x70
>[   49.717300] softirqs last  enabled at (2993394):
>[] _local_bh_enable+0x13/0x20
>[   49.717920] softirqs last disabled at (2993395):
>[] call_softirq+0x1c/0x30
>[   49.718528]
>[   49.718528] other info that might help us debug this:
>[   49.718992]  Possible unsafe locking scenario:
>[   49.718992]
>[   49.719433]CPU0
>[   49.719669]
>[   49.719902]   lock(proc_inum_lock);
>[   49.720308]   
>[   49.720548] lock(proc_inum_lock);
>[   49.720961]
>[   49.720961]  *** DEADLOCK ***
>[   49.720961]
>[   49.721477] no locks held by swapper/1/0.
>[   49.721769]
>[   49.721769] stack backtrace:
>[   49.722150] Pid: 0, comm: swapper/1 Not tainted 3.7.0 #36
>[   49.722555] Call Trace:
>[   49.722787][] ? vprintk_emit+0x471/0x510
>[   49.723307]  [] print_usage_bug+0x2a5/0x2c0
>[   49.723671]  [] mark_lock+0x33b/0x5e0
>[   49.724014]  [] __lock_acquire+0x813/0xca0
>[   49.724374]  [] ? trace_hardirqs_on+0xd/0x10
>[   49.724741]  [] lock_acquire+0x199/0x200
>[   49.725095]  [] ? proc_free_inum+0x1c/0x50
>[   49.725455]  [] _raw_spin_lock+0x41/0x50
>[   49.725806]  [] ? proc_free_inum+0x1c/0x50
>[   49.726165]  [] proc_free_inum+0x1c/0x50
>[   49.726519]  [] ? put_pid+0x42/0x60
>[   49.726857]  [] free_pid_ns+0x1c/0x50
>[   49.727201]  [] put_pid_ns+0x2e/0x50
>[   49.727540]  [] put_pid+0x4a/0x60
>[   49.727868]  [] delayed_put_pid+0x12/0x20
>[   49.728225]  [] rcu_process_callbacks+0x462/0x790
>[   49.728606]  [] __do_softirq+0x1b4/0x3b0
>[   49.728959]  [] ?
>clockevents_program_event+0xc2/0xf0
>[   49.729354]  [] call_softirq+0x1c/0x30
>[   49.729702]  [] do_softirq+0x59/0xd0
>[   49.730039]  [] irq_exit+0x54/0xd0
>[   49.730370]  [] smp_apic_timer_interrupt+0x95/0xa3
>[   49.730755]  [] apic_timer_interrupt+0x72/0x80
>[   49.731124][] ?
>retint_restore_args+0x13/0x13
>[   49.731658]  [] ? cpuidle_wrap_enter+0x55/0xa0
>[   49.732029]  [] ? cpuidle_wrap_enter+0x51/0xa0
>[   49.732399]  [] cpuidle_enter_tk+0x10/0x20
>[   49.732759]  [] cpuidle_enter_state+0x17/0x50
>[   49.733128]  [] cpuidle_idle_call+0x287/0x520
>[   49.733496]  [] cpu_idle+0xba/0x130
>[   49.733830]  [] start_secondary+0x2b3/0x2bc
>
>Signed-off-by: Xiaotian Feng 
>Cc: Andrew Morton 
>Cc: Al Viro 
>Cc: "Eric W. Biederman" 
>Cc: linux-kernel@vger.kernel.org
>---
> fs/proc/generic.c |   12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
>diff --git a/fs/proc/generic.c b/fs/proc/generic.c
>index 7b3ae3c..e659a0f 100644
>--- a/fs/proc/generic.c
>+++ b/fs/proc/generic.c
>@@ -359,18 +359,18 @@ retry:
>   if (!ida_pre_get(&proc_inum_ida, GFP_KERNEL))
>   return -ENOMEM;
> 
>-  spin_lock(&proc_inum_lock);
>+  spin_lock_bh(&proc_inum_lock);
>   error = ida_get_new(&proc_inum_ida, &i);
>-  spin_unlock(&proc_inum_lock);
>+  spin_unlock_bh(&proc_inum_lock);
>   if (error == -EAGAIN)
>   goto retry;
>   else if (error)
>   return error;
> 
>   if (i > UINT_MAX - PROC_DYNAMIC_FIRST) {
>-  spin_lock(&proc_inum_lock);
>+ 

Re: mm, ksm: NULL ptr deref in unstable_tree_search_insert

[Petr Holasek]

On Tue, 18 Dec 2012, Hugh Dickins wrote:
> On Tue, 18 Dec 2012, Sasha Levin wrote:
> 
> > Hi all,
> > 
> > While fuzzing with trinity inside a KVM tools guest, running latest 
> > linux-next kernel, I've
> > stumbled on the following:
> > 
> > [  127.959264] BUG: unable to handle kernel NULL pointer dereference at 
> > 0110
> > [  127.960379] IP: [] __lock_acquire+0xb0/0xa90
...

> > 88 e9 b9 09 00 00 90 <48> 81 3b 60 59 22 86 b8 01 00 00 00 44 0f 44 e8 41 
> > 83 fc 01 77
> > [  127.978032] RIP  [] __lock_acquire+0xb0/0xa90
> > [  127.978032]  RSP 
> > [  127.978032] CR2: 0110
> > [  127.978032] ---[ end trace 3dc1b0c5db8c1230 ]---
> > 
> > The relevant piece of code is:
> > 
> > static struct page *get_mergeable_page(struct rmap_item *rmap_item)
> > {
> > struct mm_struct *mm = rmap_item->mm;
> > unsigned long addr = rmap_item->address;
> > struct vm_area_struct *vma;
> > struct page *page;
> > 
> > down_read(&mm->mmap_sem);
> > 
> > Where 'mm' is NULL. I'm not really sure how it happens though.
> 
> Thanks, yes, I got that, and it's not peculiar to fuzzing at all:
> I'm testing the fix at the moment, but just hit something else too
> (ksmd oops on NULL p->mm in task_numa_fault i.e. task_numa_placement).
> 
> For the moment, you're safer not to run KSM: configure it out or don't
> set it to run.  Fixes to follow later, I'll try to remember to Cc you.
> 

Hello all,

I've also tried fuzzing with trinity inside of kvm guest when tested KSM
patch, but applied on top of 3.7-rc8, but didn't trigger that oops. So
going to do the same testing on linux-next.

Hugh, does it seem like bug in unstable_tree_search_insert() you mentioned
in yesterday email of something else?

Thank you for your testing && feedback!

Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] i2c-core: Add gpio based bus arbitration implementation

[Grant Likely]

On Fri, 14 Dec 2012 11:20:53 +0530, Naveen Krishna Chatradhi 
 wrote:
> The arbitrator is a general purpose function which uses two GPIOs to
> communicate with another device to claim/release a bus.
> 
> i2c_transfer()
>   if adapter->gpio_arbit
>   i2c_bus_claim();
>   __i2c_transfer();
>   i2c_bus_release();
> 
> Signed-off-by: Simon Glass 
> Cc: Grant Grundler 
> Signed-off-by: Naveen Krishna Chatradhi 

Hi Naveen,

I'm not convinced on the design of this protocol. It won't scale beyond
2 bus masters and it seems very specific to the design of a specific
piece of hardware. I don't think it is mature enough to bake into the
core i2c infrastructure or bindings. Nor do I think it will handle other
busses properly.

I can see two alternatives here.
1) build in hooks for doing i2c bus claim/release, but don't put this
specific implementation into the core infrastructure
2) Create an i2c bridge driver. This would kind of be like an i2c
multiplexer, but it would only have one bus and it would include the
knowledge of how to use the GPIO lines for bus arbitration.

I think option 2 would be the cleanest option. It would be straight
forward to design a binding for it by placing a node between the i2c
bus and all the i2c clients. For example:

i2c@6000 {
compatible = "acme,some-i2c-device";
#address-cells = <1>;
#size-cells = <0>;

i2c-bridge {
#address-cells = <1>;
#size-cells = <0>;
compatible = "samaung,i2c-gpio-arbitrate";

bus-arbitration-gpios = <&gpf0 3 1 0 0>, /* AP_CLAIM */
<&gpe0 4 0 3 0>; /* EC_CLAIM */

bus-arbitration-slew-delay-us = <10>;
bus-arbitration-wait-retry-us = <2000>;
bus-arbitration-wait-free-us = <5>;

i2c@52 {
// Normal i2c device
};
};
};

I don't know what the state of the i2c subsystem is with regard to
supporting i2c multiplexer devices, so there might be some changes
needed there, but I can't see it being particularly complex. It should
just be a device in the middle. Any i2c device that is a child of the
bridge would send transfers to the bridge, and the bridge would be
responsible to claim the bus and then pass the transfer through
unchanged.

That eliminates the problem of trying to design an arbitration scheme
that works for all.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dt: fix tegra SPI binding examples

[Grant Likely]

On Fri, 14 Dec 2012 11:05:12 -0800, Allen Martin  wrote:
> Fix name of slink binding and address of sflash example to make it
> self consistent.
> 
> Change-Id: Ia89c3017c958bdf670036caf516eabce6f893096

Applied, thanks.

g.

> Signed-off-by: Allen Martin 
> ---
>  Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt |2 +-
>  Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt  |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt 
> b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
> index 8cf24f6..7b53da5 100644
> --- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
> +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
> @@ -13,7 +13,7 @@ Recommended properties:
>  
>  Example:
>  
> -spi@7000d600 {
> +spi@7000c380 {
>   compatible = "nvidia,tegra20-sflash";
>   reg = <0x7000c380 0x80>;
>   interrupts = <0 39 0x04>;
> diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt 
> b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
> index f5b1ad1..eefe15e 100644
> --- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
> +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
> @@ -13,7 +13,7 @@ Recommended properties:
>  
>  Example:
>  
> -slink@7000d600 {
> +spi@7000d600 {
>   compatible = "nvidia,tegra20-slink";
>   reg = <0x7000d600 0x200>;
>   interrupts = <0 82 0x04>;
> -- 
> 1.7.10.4
> 
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] KVM: Alleviate mmu_lock hold time when we start dirty logging

[Takuya Yoshikawa]

Ccing Alex,

I tested kvm.git next branch before Alex's patch set was applied, and
did not see the bug.  Although I'm not 100% sure but it is possible
that something got broken by a patch in the following series:

[01/10] KVM: Restrict non-existing slot state transitions
[02/10] KVM: Check userspace_addr when modifying a memory slot
[03/10] KVM: Fix iommu map/unmap to handle memory slot moves
[04/10] KVM: Minor memory slot optimization
[05/10] KVM: Rename KVM_MEMORY_SLOTS -> KVM_USER_MEM_SLOTS
[06/10] KVM: Make KVM_PRIVATE_MEM_SLOTS optional
[07/10] KVM: struct kvm_memory_slot.user_alloc -> bool
[08/10] KVM: struct kvm_memory_slot.flags -> u32
[09/10] KVM: struct kvm_memory_slot.id -> short
[10/10] KVM: Increase user memory slots on x86 to 125

If I can get time, I will check which one caused the problem tomorrow.

Thanks,
Takuya


On Tue, 18 Dec 2012 16:25:58 +0900
Takuya Yoshikawa  wrote:

> IMPORTANT NOTE (not about this patch set):
> 
> I have hit the following bug many times with the current next branch,
> even WITHOUT my patches.  Although I do not know a way to reproduce this
> yet, it seems that something was broken around slot->dirty_bitmap.  I am
> now investigating the new code in __kvm_set_memory_region().
> 
> The bug:
> [  575.238063] BUG: unable to handle kernel paging request at 0002efe83a77
> [  575.238185] IP: [] mark_page_dirty_in_slot+0x19/0x20 
> [kvm]
> [  575.238308] PGD 0 
> [  575.238343] Oops: 0002 [#1] SMP 
> 
> The call trace:
> [  575.241207] Call Trace:
> [  575.241257]  [] kvm_write_guest_cached+0x91/0xb0 [kvm]
> [  575.241370]  [] kvm_arch_vcpu_ioctl_run+0x1109/0x12c0 
> [kvm]
> [  575.241488]  [] ? kvm_arch_vcpu_ioctl_run+0xa5/0x12c0 
> [kvm]
> [  575.241595]  [] ? mutex_lock_killable_nested+0x274/0x340
> [  575.241706]  [] ? kvm_set_ioapic_irq+0x20/0x20 [kvm]
> [  575.241813]  [] kvm_vcpu_ioctl+0x559/0x670 [kvm]
> [  575.241913]  [] ? kvm_vm_ioctl+0x1b8/0x570 [kvm]
> [  575.242007]  [] ? native_sched_clock+0x13/0x80
> [  575.242125]  [] ? sched_clock+0x9/0x10
> [  575.242208]  [] ? sched_clock_cpu+0xbd/0x110
> [  575.242298]  [] ? fget_light+0x3c/0x140
> [  575.242381]  [] do_vfs_ioctl+0x98/0x570
> [  575.242463]  [] ? fget_light+0xa1/0x140
> [  575.246393]  [] ? fget_light+0x3c/0x140
> [  575.250363]  [] sys_ioctl+0x91/0xb0
> [  575.254327]  [] system_call_fastpath+0x16/0x1b
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/2] virtio_balloon: move locking to the balloon thread

[Luiz Capitulino]

On Wed, 19 Dec 2012 09:55:58 -0200
Rafael Aquini  wrote:

> On Tue, Dec 18, 2012 at 06:17:29PM -0200, Luiz Capitulino wrote:
> > Today, the balloon_lock mutex is taken and released by fill_balloon()
> > and leak_balloon() when both functions are entered and when they
> > return.
> > 
> > This commit moves the locking to the caller instead, which is
> > the balloon() thread. The balloon thread is the sole caller of those
> > functions today.
> > 
> > The reason for this move is that the next commit will introduce
> > a shrinker callback for the balloon driver, which will also call
> > leak_balloon() but will require different locking semantics.
> > 
> > Signed-off-by: Luiz Capitulino 
> > ---
> >  drivers/virtio/virtio_balloon.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/virtio/virtio_balloon.c 
> > b/drivers/virtio/virtio_balloon.c
> > index 2a70558..877e695 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -133,7 +133,6 @@ static void fill_balloon(struct virtio_balloon *vb, 
> > size_t num)
> > /* We can only do one array worth at a time. */
> > num = min(num, ARRAY_SIZE(vb->pfns));
> >  
> > -   mutex_lock(&vb->balloon_lock);
> > for (vb->num_pfns = 0; vb->num_pfns < num;
> >  vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
> > struct page *page = balloon_page_enqueue(vb_dev_info);
> > @@ -155,7 +154,6 @@ static void fill_balloon(struct virtio_balloon *vb, 
> > size_t num)
> > /* Did we get any? */
> > if (vb->num_pfns != 0)
> > tell_host(vb, vb->inflate_vq);
> > -   mutex_unlock(&vb->balloon_lock);
> >  }
> >
> 
> Since you're removing the locking scheme from within this function, I think it
> would be a good idea introduce a comment stating its caller must held the 
> mutex
> vb->balloon_lock.

Will address all comments for v1 (or rfc v2), thanks Rafael.

> 
>   
> >  static void release_pages_by_pfn(const u32 pfns[], unsigned int num)
> > @@ -177,7 +175,6 @@ static void leak_balloon(struct virtio_balloon *vb, 
> > size_t num)
> > /* We can only do one array worth at a time. */
> > num = min(num, ARRAY_SIZE(vb->pfns));
> >  
> > -   mutex_lock(&vb->balloon_lock);
> > for (vb->num_pfns = 0; vb->num_pfns < num;
> >  vb->num_pfns += VIRTIO_BALLOON_PAGES_PER_PAGE) {
> > page = balloon_page_dequeue(vb_dev_info);
> > @@ -193,7 +190,6 @@ static void leak_balloon(struct virtio_balloon *vb, 
> > size_t num)
> >  * is true, we *have* to do it in this order
> >  */
> > tell_host(vb, vb->deflate_vq);
> > -   mutex_unlock(&vb->balloon_lock);
> > release_pages_by_pfn(vb->pfns, vb->num_pfns);
> >  }
> >
> 
> ditto
> 
>   
> > @@ -306,11 +302,13 @@ static int balloon(void *_vballoon)
> >  || freezing(current));
> > if (vb->need_stats_update)
> > stats_handle_request(vb);
> > +   mutex_lock(&vb->balloon_lock);
> > if (diff > 0)
> > fill_balloon(vb, diff);
> > else if (diff < 0)
> > leak_balloon(vb, -diff);
> > update_balloon_size(vb);
> > +   mutex_unlock(&vb->balloon_lock);
> > }
> > return 0;
> >  }
> 
> Just a nitpick:
> As leak_balloon() is also called at remove_common(), you'll need to introduce 
> the
> mutex there, similarly.
> 
> 
> Thanks for move this forward.
> 
> Cheers!
> -- Rafael
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] virtio: add functions for piecewise addition of buffers

[Stefan Hajnoczi]

On Wed, Dec 19, 2012 at 1:04 PM, Paolo Bonzini  wrote:
> Il 19/12/2012 11:47, Stefan Hajnoczi ha scritto:
>> On Tue, Dec 18, 2012 at 01:32:48PM +0100, Paolo Bonzini wrote:
>> What is the purpose of count_sg?
>
> It is needed to decide whether to use an indirect or a direct buffer.
> The idea is to avoid a memory allocation if the driver is providing us
> with separate sg elements (under the assumption that they will be few).

Ah, this makes sense now.  I saw it affects the decision whether to go
indirect or not but it wasn't obvious why.

> Originally I wanted to use a mix of direct and indirect buffer (direct
> if add_buf received a one-element scatterlist, otherwise indirect).  It
> would have had the same effect, without having to specify count_sg in
> advance.  The spec is not clear if that is allowed or not, but in the
> end they do not work with either QEMU or vhost, so I chose this
> alternative instead.

Okay.

Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/14] perf ui/hist: Add support for event group view

[Arnaldo Carvalho de Melo]

Em Mon, Dec 17, 2012 at 03:38:58PM +0900, Namhyung Kim escreveu:
> From: Namhyung Kim 
> 
> Show group members' overhead also when showing the leader's if event
> group is enabled.  Use macro for defining hpp functions which looks
> almost identical.
> 
> Thanks to Arnaldo for suggesting a better way to print group members
> without allocating temporary array.

I applied up to the previous patch (6/14), doing minor changes in some
due to clashes with other patches, but then this one isn't applying, can
you take a look?

I left what I did on the perf/group, so you can continue from there.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] of: Support a PCI device that is compatible with 'simple-bus'

[Grant Likely]

On Fri, 14 Dec 2012 14:58:14 -0700, Jason Gunthorpe 
 wrote:
> On Fri, Dec 14, 2012 at 08:26:29PM +, Grant Likely wrote:
> 
> > > > If the soc_devices are getting triggered on that and they shouldn't be,
> > > > then we need a mechanism in the soc_bridge node to kick out of that
> > > > behavoir for its children.
> > > 
> > > Is this what you were thinking?
> > 
> > Not really. I see what you're trying to do, but doing it this way forces
> > all children of PCI nodes to use the PCI addressing space. Others have
> > had simple children of PCI devices and didn't use the PCI address layout
> > at all. Those users would break with this approach.
> 
> Yes, that's right.
> 
> If you drop 'device_type=pci' from the PCI device (keep it on the host
> bridge), then you can setup a ranges down to a smaller width and
> things seem to work OK. That must be what other users are doing.
> 
> However, you can't stay at address-cells=3 for the children. That
> doesn't work.
> 
> So, if you have separate PCI regions, like MMIO and prefetch it looks
> like this works OK:
> 
>  pci_device@0 {
>ranges =
> // MMIO region, BAR 0
><0x2000 0x  0x0200 0x 0x  0x0 0x800
> // Prefetch region, BAR 1
> 0x4000 0x  0x4200 0x 0x  0x0 
> 0x800>;
> 
>#size-cells = <1>;
>#address-cells = <2>;
>sub {
>  // MMIO region at BAR 0 offset 0x2000
>  reg = <0x2000 0x2000 0x1000>;
>}
>sub2 {
>  // Prefetch region at BAR 1 offset 0x4000
>  reg = <0x4000 0x4000 0x1000>;
>}
>  }
> 
> Which is weird, but OK..
> 
> This is good enough for my application.. fixing up address-cells=3 to
> work generally seems pretty complicated at first blush?
> 
> > However, if you want to pass a unity mapping from the PCI device to the
> > a child of it, it should be sufficient to use an empty 'ranges;'
> > property in the PCI device node instead of listing out the ranges that
> > you want to translate.
> 
> It isn't a unity mapping - the children see address 0 as being the
> start of a BAR. The DTS has three levels of translation:
> 
> - platform device child - 0 is the start of a BAR in the pci device
> - pci device - 0 is the start of the host bridge memory window for the
>   BAR's type
> - pci controller - 0 is the start of physical memory

Then it sounds like you really don't want PCI addressing in the
children. It sounds like the children addresses need to be in the form
[bar#] [offset-from-base-of-bar]. In that case, you need the appropriate
ranges entries to translate from each bar to the PCI address space,
which is exactly what other users are doing. Whether your address format
uses 2 cells or 3, it shouldn't matter. The translation mechanism is the
same:

ranges = <[child-address1] [parent-address2] [child-size]>,
 <[child-address2] [parent-address2] [child-size]>,
 ...
 ;

I may still be missing something though. Here is what I've been
assuming:

- The PCI device has N BARs.
- The PCI bus assigns addresses to the BARs (exposed in assigned-addresses)
- Each BAR may use different address region (IO/mem) or have different
  behaviour (prefetch/non-prefetch)
- either:
  a) The PCI device has a separate local bus behind each BAR. Devices and/or
 memory are attached to those busses and must be accessed through the
 relevant BAR.
  --or--
  b) The PCI device has a single local bus which the BARs map onto.
 Internally, the BARs get mapped onto local bus regions and may
 possibly overlap.

Am I correct so far?

In the a) case, it would make sense for the address format for the
device to be 1 cell for the bar# and 1 or 2 cells for the offset off the
base of the bar. One ranges entry is needed for each bar to translate
from a PCI address range to the BAR region.

In the b) case, the address of the child devices should be the exact
address on the local bus. Again one ranges entry is needed for each BAR,
but this time it encodes the full mapping from PCI address to local
address.

In both cases, the type of transfer is encoded by the BAR address and
does not get exposed to the child device. Exposing the PCI flags into
the child bus(es) really isn't a very good idea because they don't make
sense in that context. It may seem expedient, but it will be fragile.

I apologize if I'm being dense here and missing something about why you
need to use PCI addressing on a non-PCI bus segment. Please let me know
if I'm missing something important.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/5] Input: Add ChromeOS EC keyboard driver

[Grant Likely]

On Fri, 14 Dec 2012 17:43:31 -0800, Dmitry Torokhov  
wrote:
> On Saturday, December 15, 2012 01:13:45 AM Grant Likely wrote:
> > On Wed, 12 Dec 2012 13:33:48 -0800, Simon Glass  wrote:
> > > Use the key-matrix layer to interpret key scan information from the EC
> > > and inject input based on the FDT-supplied key map. This driver registers
> > > itself with the ChromeOS EC driver to perform communications.
> > > 
> > > Additional FDT bindings are provided to specify rows/columns and the
> > > auto-repeat information.
> > > 
> > > Signed-off-by: Simon Glass 
> > > Signed-off-by: Luigi Semenzato 
> > > Signed-off-by: Vincent Palatin 
> > > ---
> > > 
> > >  .../devicetree/bindings/input/cros-ec-keyb.txt |   77 
> > >  drivers/input/keyboard/Kconfig |   10 +
> > >  drivers/input/keyboard/Makefile|1 +
> > >  drivers/input/keyboard/cros_ec_keyb.c  |  413
> > >   4 files changed, 501 insertions(+), 0 deletions(-)
> > >  create mode 100644
> > >  Documentation/devicetree/bindings/input/cros-ec-keyb.txt
> > >  create mode 100644 drivers/input/keyboard/cros_ec_keyb.c
> > > 
> > > diff --git a/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
> > > b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt new file mode
> > > 100644
> > > index 000..67f51d8
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/cros-ec-keyb.txt
> > > @@ -0,0 +1,77 @@
> > > +ChromeOS EC Keyboard
> > > +
> > > +Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
> > > +a separate EC (Embedded Controller) device. It provides a message for
> > > reading +key scans from the EC. These are then converted into keycodes
> > > for processing +by the kernel.
> > > +
> > > +Required properties:
> > > +- compatible: "google,cros-ec-keyb"
> > > +- google,key-rows: Number of keyboard rows (must be <= 8)
> > > +- google,key-columns: Number of keyboard columns (must be <= 13)
> > > +- google,repeat-delay-ms: Key repeat delay in milliseconds
> > > +- google,repeat-rate-ms: Key repeat rate in milliseconds
> > 
> > Hmmm, these should probably be in a common binding. Take a look at
> > the other input bindings and make a proposal for properties to add to
> > matrix-keymap.txt.
> 
> Actually these are not essentia for bringup and can be set from userspace,
> so I'd say simply drop them.

Aren't they needed for a working keyboard? If so, I would really think
they should be set correctly without userspace intervention.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Felipe Balbi]

Hi,

+Sricharan who commited that

On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
> >> Well, we still haven't got the foggiest idea what the actual problem is
> >> beyond that it's probably related to the 32kHz clock in some way (unless
> >> it was one of the other reverts that coincidentally made a difference,
> >> but we don't know what they were) so it's unlikely that just randomly
> >> implementing clock support is going to fix anything immediately here.
> > 
> > This is exactly what I had to revert (as I mentioned in the other email,
> > I had to revert the other patches otherwise compilation would break):
> > 
> > 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
> > e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
> > 029dd3ce "regulator: twl: Remove another unused variable warning"
> 
> Yeah. 32k clock is not provided by twl.
> 
> As I said I need to take a look at CCF to see if it already there. If it is
> clock driver + mapping + patch for wl12xx should fix the issue you are facing.
> 
> > Let me know if you need more info.
> 
> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
> added there:
> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
> 
> Which means that _essential_ clocks and pads are no longer configured.

anything essential you can list ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] serial: tegra: add serial driver

[Grant Likely]

On Mon, 17 Dec 2012 14:31:34 -0700, Stephen Warren  
wrote:
> On 12/17/2012 10:10 AM, Grant Likely wrote:
> > On Mon, 17 Dec 2012 17:40:49 +0530, Laxman Dewangan  
> > wrote:
> >> Nvidia's Tegra has multiple uart controller which supports:
> >> - APB dma based controller fifo read/write.
> >> - End Of Data interrupt in incoming data to know whether end
> >>   of frame achieve or not.
> >> - Hw controlled RTS and CTS flow control to reduce SW overhead.
> 
> >> +static int __devinit tegra_uart_probe(struct platform_device *pdev)
> >> +{
> >> +  struct tegra_uart_port *tup;
> >> +  struct uart_port *u;
> >> +  struct tegra_uart_platform_data *pdata = pdev->dev.platform_data;
> > 
> > Since this is a new driver, and all new board support will use device
> > tree, when would this platform_data pointer get set? Can you drop the
> > platform_data support code entirely?
> 
> Aren't we still supposed to support platform data so that it can
> override what's in DT in order to fix up bad DTs? Or, has that
> requirement been dropped. If it has, we can drop a bunch of code from a
> variety of Tegra-specific drivers, I expect.

Do you have an actual user for this? If not, then don't borrow trouble.
Just drop it. Things like platform_data can always be added later only
if it is needed.

g.

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: tegra: add serial driver

[Grant Likely]

On Mon, 17 Dec 2012 12:17:16 -1000, Mitch Bradley  wrote:
> On 12/17/2012 12:04 PM, Stephen Warren wrote:
> > On 12/17/2012 02:58 PM, Mitch Bradley wrote:
> >> On 12/17/2012 11:36 AM, Stephen Warren wrote:
> >>> On 12/17/2012 05:10 AM, Laxman Dewangan wrote:
>  Nvidia's Tegra has multiple uart controller which supports:
>  - APB dma based controller fifo read/write.
>  - End Of Data interrupt in incoming data to know whether end
>    of frame achieve or not.
>  - Hw controlled RTS and CTS flow control to reduce SW overhead.
> >>>
>  diff --git 
>  a/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt 
>  b/Documentation/devicetree/bindings/serial/nvidia,serial-tegra.txt
> >>>
>  +NVIDIA Tegra20/Tegra30 high speed (dma based) UART controller driver.
>  +
>  +Required properties:
>  +- compatible : should be "nvidia,tegra20-hsuart", 
>  "nvidia,tegra30-hsuart".
> >>>
> >>> One question that isn't addressed here is:
> >>>
> >>> Tegra has 5 UARTs. All of them can use the existing 8250.c by specifying
> >>> compatible = "nvidia,tegra20-uart".
> >>
> >> The way it is supposed to work is that the compatible property should
> >> list "nvidia,tegra30-hsuart" first, followed by a fallback name that
> >> refers to the generic 8250 compatibility.  Having the 8250.c driver bind
> >> to the more-specific tegra30-hsuart name is wrong.
> > 
> > 8250.c binds to nvidia,tegra20-uart, so that aspect is fine.
> > 
> > However, the real issue is that we probably want 4 of the 5 ports to use
> > the plain old 8250.c (so as not to use up too many DMA channels), but
> > just 1 of the ports to use the DMA-capable high-performance driver (e.g.
> > the one that a particular board has hooked up to a Bluetooth radio). The
> > only way to do that with DT that I know of would be to specify different
> > subsets of legal compatible values for each UART in the per-board .dts file.
> 
> 
> That's an okay way to do it.  The whole purpose of the compatible
> property is to support driver binding.  The mantra to "describe the
> hardware" is good, but shouldn't be taken to extremes.
> 
> It would be a good idea to comment the .dts file to explain why the
> compatible property differs between the otherwise-identical nodes.

+1

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] Capabilities still can't be inherited by normal programs

[Pádraig Brady]

On 12/12/2012 06:29 PM, Andy Lutomirski wrote:

On Sat, Dec 8, 2012 at 3:57 PM, Andy Lutomirski  wrote:


I just tried to search to find actual uses of pI/fI.  Here's what I found:


I downloaded all the Fedora spec files and searched for file
capabilities.  Assuming I didn't mess up, here's what I found:


Just pointing out a handy online search tool
for this sort of thing.

http://searchco.de/?q=%25caps+url:fedora+ext:spec

thanks,
Pǽdraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH - v2] spi: davinci: add OF support for the spi controller

[Grant Likely]

On Sat, 15 Dec 2012 00:27:58 +, Grant Likely  
wrote:
> On Tue, 11 Dec 2012 16:20:39 -0500, Murali Karicheri  
> wrote:
> > This adds OF support to DaVinci SPI controller to configure platform
> > data through device bindings. Also replaces clk_enable() with
> > of clk_prepare_enable() as well as clk_disable() with
> > clk_disable_unprepare().
> > 
> > Signed-off-by: Murali Karicheri 
> > Reviewed-by : Grant Likely 
> 
> Applied, thanks.
> 
> I did remove the OF_ALIAS_N property though. I know the COMPATIBLE one
> uses it, but it is actually kind of redundant since it can also be
> determined by counting the number of OF_ALIAS_* entries, and having the
> _N one in there means extra work needs to be done to filter it out.
> 
> Also, I had to add a #ifndef _LINUX_OF_PRIVATE_H wrapper around the
> whole header file. This is needed for all header files to protect
> against multiple includes.

Ummm oops. I replied to the wrong email when applying another patch.
Sorry for the noise.

But I have applied your patch now. It will appear in linux-next after
the merge window closes.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] checkpatch: Warn on uapi #includes that #include

[David Howells]

Joe Perches  wrote:

> Avoid specifying internal uapi #include paths with uapi/...
> as userspace should not use and never see that.
> 
> Neaten message line wrapping above.
> 
> Signed-off-by: Joe Perches 

Acked-by: David Howells 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] f2fs: request for tree inclusion

[Anca Emanuel]

Hi Linus,

An early prototype of this:
https://wiki.linaro.org/WorkingGroups/Kernel/Specs/flash-file-system-prototype

Are you still testing it ?

On Sun, Dec 16, 2012 at 1:19 AM, Jaegeuk Kim  wrote:
> Hi Linus,
>
> I'm seeing that f2fs has not been merged yet.
> Could you give me any notice for this?
> Management priority, or something else?
>
> BTW, I have added a couple of bug fixes since "for-3.8-merge".
> Which is better sending between [GIT PULL v2] or additional pull request
> after merge?
>
> Thanks,
> Jaegeuk Kim
>
> 2012-12-11 (화), 16:58 +0900, Jaegeuk Kim:
>> Hi Linus,
>>
>> This is the first pull request for tree inclusion of Flash-Friendly File
>> System (F2FS) towards the 3.8 merge window.
>>
>> http://lwn.net/Articles/518718/
>> http://lwn.net/Articles/518988/
>> http://en.wikipedia.org/wiki/F2FS
>>
>> The f2fs has been in the linux-next tree for a while, and several issues
>> have been cleared as described in the signed tag below.
>> And also, I've done testing f2fs successfully based on Linux 3.7 with
>> the following test scenarios.
>>
>> - Reliability test:
>>   Run fsstress on an SSD partition.
>>
>> - Robustness test:
>>   Conduct sudden-power-off and examine the fs consistency repeatedly,
>>   while running a reliability test.
>>
>> So, please pull the f2fs filesystem.
>> If I'm missing any issues or made mistakes, please let me know.
>>
>> Thanks,
>> Jaegeuk Kim
>>
>> The following changes since commit
>> 29594404d7fe73cd80eaa4ee8c43dcc53970c60e:
>>
>>   Linux 3.7 (2012-12-10 19:30:57 -0800)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git
>> tags/for-3.8-merge
>>
>> for you to fetch changes up to e6aa9f36b2bfd6b30072c07b34f2a24becf1:
>>
>>   f2fs: fix tracking parent inode number (2012-12-11 13:43:45 +0900)
>>
>> 
>> Introduce a new file system, Flash-Friendly File System (F2FS), to Linux
>> 3.8.
>>
>> Highlights:
>> - Add initial f2fs source codes
>> - Fix an endian conversion bug
>> - Fix build failures on random configs
>> - Fix the power-off-recovery routine
>> - Minor cleanup, coding style, and typos patches
>> 
>> Greg Kroah-Hartman (1):
>>   f2fs: move proc files to debugfs
>>
>> Huajun Li (1):
>>   f2fs: fix a typo in f2fs documentation
>>
>> Jaegeuk Kim (22):
>>   f2fs: add document
>>   f2fs: add on-disk layout
>>   f2fs: add superblock and major in-memory structure
>>   f2fs: add super block operations
>>   f2fs: add checkpoint operations
>>   f2fs: add node operations
>>   f2fs: add segment operations
>>   f2fs: add file operations
>>   f2fs: add address space operations for data
>>   f2fs: add core inode operations
>>   f2fs: add inode operations for special inodes
>>   f2fs: add core directory operations
>>   f2fs: add xattr and acl functionalities
>>   f2fs: add garbage collection functions
>>   f2fs: add recovery routines for roll-forward
>>   f2fs: update Kconfig and Makefile
>>   f2fs: update the f2fs document
>>   f2fs: fix endian conversion bugs reported by sparse
>>   f2fs: adjust kernel coding style
>>   f2fs: resolve build failures
>>   f2fs: cleanup the f2fs_bio_alloc routine
>>   f2fs: fix tracking parent inode number
>>
>> Namjae Jeon (10):
>>   f2fs: fix the compiler warning for uninitialized use of variable
>>   f2fs: show error in case of invalid mount arguments
>>   f2fs: remove unneeded memset from init_once
>>   f2fs: check read only condition before beginning write out
>>   f2fs: remove unneeded initialization
>>   f2fs: move error condition for mkdir at proper place
>>   f2fs: rewrite f2fs_bio_alloc to make it simpler
>>   f2fs: make use of GFP_F2FS_ZERO for setting gfp_mask
>>   f2fs: remove redundant call to f2fs_put_page in delete entry
>>   f2fs: introduce accessor to retrieve number of dentry slots
>>
>> Sachin Kamat (1):
>>   f2fs: remove unneeded version.h header file from f2fs.h
>>
>> Wei Yongjun (1):
>>   f2fs: remove unused variable
>>
>>  Documentation/filesystems/00-INDEX |2 +
>>  Documentation/filesystems/f2fs.txt |  421 +
>>  fs/Kconfig |1 +
>>  fs/Makefile|1 +
>>  fs/f2fs/Kconfig|   53 ++
>>  fs/f2fs/Makefile   |7 +
>>  fs/f2fs/acl.c  |  414 +
>>  fs/f2fs/acl.h  |   57 ++
>>  fs/f2fs/checkpoint.c   |  794 
>>  fs/f2fs/data.c |  702 ++
>>  fs/f2fs/debug.c|  361 
>>  fs/f2fs/dir.c  |  672 ++
>>  fs/f2fs/f2fs.h | 1083 ++
>>  fs/f2fs/file.c |  636 +
>>  fs/f2f

[PATCH 2/3] kcmp: Drop x86 dependancy

[Alexander Kartashov]

From: Cyrill Gorcunov 

Signed-off-by: Cyrill Gorcunov 
Signed-off-by: Alexander Kartashov 
---
 kernel/Makefile |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/Makefile b/kernel/Makefile
index 86e3285..9f7a139 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -25,9 +25,7 @@ endif
 obj-y += sched/
 obj-y += power/
 
-ifeq ($(CONFIG_CHECKPOINT_RESTORE),y)
-obj-$(CONFIG_X86) += kcmp.o
-endif
+obj-$(CONFIG_CHECKPOINT_RESTORE) += kcmp.o
 obj-$(CONFIG_FREEZER) += freezer.o
 obj-$(CONFIG_PROFILING) += profile.o
 obj-$(CONFIG_STACKTRACE) += stacktrace.o
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] kcmp: enable the kcmp syscall when C/R is enabled

[Alexander Kartashov]

Signed-off-by: Alexander Kartashov 
---
 arch/arm/include/uapi/asm/unistd.h |2 +-
 arch/arm/kernel/calls.S|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/uapi/asm/unistd.h 
b/arch/arm/include/uapi/asm/unistd.h
index ac03bdb..afe27b5 100644
--- a/arch/arm/include/uapi/asm/unistd.h
+++ b/arch/arm/include/uapi/asm/unistd.h
@@ -404,7 +404,7 @@
 #define __NR_setns (__NR_SYSCALL_BASE+375)
 #define __NR_process_vm_readv  (__NR_SYSCALL_BASE+376)
 #define __NR_process_vm_writev (__NR_SYSCALL_BASE+377)
-   /* 378 for kcmp */
+#define __NR_kcmp  (__NR_SYSCALL_BASE+378)
 
 /*
  * This may need to be greater than __NR_last_syscall+1 in order to
diff --git a/arch/arm/kernel/calls.S b/arch/arm/kernel/calls.S
index 831cd38..a2a62a8 100644
--- a/arch/arm/kernel/calls.S
+++ b/arch/arm/kernel/calls.S
@@ -387,7 +387,7 @@
 /* 375 */  CALL(sys_setns)
CALL(sys_process_vm_readv)
CALL(sys_process_vm_writev)
-   CALL(sys_ni_syscall)/* reserved for sys_kcmp */
+   CALL(sys_kcmp)  /* reserved for sys_kcmp */
 #ifndef syscalls_counted
 .equ syscalls_padding, ((NR_syscalls + 3) & ~3) - NR_syscalls
 #define syscalls_counted
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] kcmp: Include linux/ptrace.h

[Alexander Kartashov]

From: Cyrill Gorcunov 

This makes it compile on s390. After all the ptrace_may_access
(which we use this file) is declared exactly in linux/ptrace.h.

This is preparatory work to wire this syscall up on all archs.

Original-by: Heiko Carstens 
Signed-off-by: Cyrill Gorcunov 
CC: Andrew Morton 
CC: "H. Peter Anvin" 
CC: Eric W. Biederman 
CC: Pavel Emelyanov 
CC: Alexander Kartashov 
Signed-off-by: Alexander Kartashov 
---
 kernel/kcmp.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/kcmp.c b/kernel/kcmp.c
index 30b7b22..e30ac0f 100644
--- a/kernel/kcmp.c
+++ b/kernel/kcmp.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] checkpatch: Warn on uapi #includes that #include

[Andy Whitcroft]

On Tue, Dec 18, 2012 at 05:30:58PM -0800, Joe Perches wrote:
> Avoid specifying internal uapi #include paths with uapi/...
> as userspace should not use and never see that.
> 
> Neaten message line wrapping above.
> 
> Signed-off-by: Joe Perches 
> cc: David Howells 
> ---
>  scripts/checkpatch.pl |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 054a293..5eab67e 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -2238,8 +2238,11 @@ sub process {
>   my $path = $1;
>   if ($path =~ m{//}) {
>   ERROR("MALFORMED_INCLUDE",
> -   "malformed #include filename\n" .
> - $herecurr);
> +   "malformed #include filename\n" . 
> $herecurr);
> + }
> + if ($path =~ "^uapi/" && $realfile =~ 
> m@\binclude/uapi/@) {
> + ERROR("UAPI_INCLUDE",
> +   "No #include in ...include/uapi/... 
> should use a uapi/ path prefix\n" . $herecurr);
>   }
>   }
>  

Looks reasonable indeed.

Acked-by: Andy Whitcroft 

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] f2fs: request for tree inclusion

[Arnd Bergmann]

On Wednesday 19 December 2012, Anca Emanuel wrote:
> 
> Hi Linus,
> 
> An early prototype of this:
> https://wiki.linaro.org/WorkingGroups/Kernel/Specs/flash-file-system-prototype
> 
> Are you still testing it ?

The prototype was an earlier and independent work done as an internship
in Linaro. It resulted in very valuable insights, some of which ended
up being integrated into f2fs, but we decided not to follow up on that
work since f2fs is far superior overall and has a dedicated team working
on it. There are a few features from the prototype that we might want
to add in f2fs, but those can be implemented as compatible changes
later.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] dma: tegra: implement flags parameters for cyclic transfer

[Laxman Dewangan]

The flag parameter is added in the cyclic transfer request.
Use the flag option of:
- DMA_PREP_INTERRUPT for enabling interrupt.
- DMA_CTRL_ACK for deciding whether ack is requred or not for
  descriptor.

Signed-off-by: Laxman Dewangan 
---
 drivers/dma/tegra20-apb-dma.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
index efdfffa..bf58bb8 100644
--- a/drivers/dma/tegra20-apb-dma.c
+++ b/drivers/dma/tegra20-apb-dma.c
@@ -266,6 +266,7 @@ static struct tegra_dma_desc *tegra_dma_desc_get(
if (async_tx_test_ack(&dma_desc->txd)) {
list_del(&dma_desc->node);
spin_unlock_irqrestore(&tdc->lock, flags);
+   dma_desc->txd.flags = 0;
return dma_desc;
}
}
@@ -1050,7 +1051,9 @@ struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic(
TEGRA_APBDMA_AHBSEQ_WRAP_SHIFT;
ahb_seq |= TEGRA_APBDMA_AHBSEQ_BUS_WIDTH_32;
 
-   csr |= TEGRA_APBDMA_CSR_FLOW | TEGRA_APBDMA_CSR_IE_EOC;
+   csr |= TEGRA_APBDMA_CSR_FLOW;
+   if (flags & DMA_PREP_INTERRUPT)
+   csr |= TEGRA_APBDMA_CSR_IE_EOC;
csr |= tdc->dma_sconfig.slave_id << TEGRA_APBDMA_CSR_REQ_SEL_SHIFT;
 
apb_seq |= TEGRA_APBDMA_APBSEQ_WRAP_WORD_1;
@@ -1095,7 +1098,8 @@ struct dma_async_tx_descriptor *tegra_dma_prep_dma_cyclic(
mem += len;
}
sg_req->last_sg = true;
-   dma_desc->txd.flags = 0;
+   if (flags & DMA_CTRL_ACK)
+   dma_desc->txd.flags = DMA_CTRL_ACK;
 
/*
 * Make sure that mode should not be conflicting with currently
-- 
1.7.1.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] usb: phy: samsung: Add support to set pmu isolation

[Vivek Gautam]

Hi Sylwester,


On Wed, Dec 19, 2012 at 11:05 AM, Vivek Gautam
 wrote:
> CC: Doug Anderson
>
>
> On Wed, Dec 19, 2012 at 4:49 AM, Sylwester Nawrocki
>  wrote:
>> Hi Vivek,
>>
>>
>> On 12/18/2012 02:56 PM, Vivek Gautam wrote:
>>>
>>> Adding support to parse device node data in order to get
>>> required properties to set pmu isolation for usb-phy.
>>>
>>> Signed-off-by: Vivek Gautam
>>> ---
>>>
>>> Changes from v1:
>>>   - Changed the name of property for phy handler from'samsung,usb-phyctrl'
>>> to 'samsung,usb-phyhandle' to make it look more generic.
>>>   - Similarly 'samsung,phyctrl-reg' is changed to 'samsung,phyhandle-reg'
>>>   - Added a check for 'samsung,usb-phyhandle' before getting node from
>>> phandle.
>>>   - Putting the node using 'of_node_put()' which had been missed.
>>>   - Adding necessary check for the pointer in
>>> 'samsung_usbphy_set_isolation()'
>>> to avoid any NULL pointer dereferencing.
>>>   - Unmapping the register ioremapped in
>>> 'samsung_usbphy_parse_dt_param()'.
>>>
>>>
>>>   .../devicetree/bindings/usb/samsung-usbphy.txt |   12 +++
>>>   drivers/usb/phy/samsung-usbphy.c   |   94
>>> ++--
>>>   2 files changed, 98 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>>> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>>> index 7b26e2d..a7b28b2 100644
>>> --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>>> +++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
>>> @@ -9,3 +9,15 @@ Required properties:
>>>   - compatible : should be "samsung,exynos4210-usbphy"
>>>   - reg : base physical address of the phy registers and length of memory
>>> mapped
>>> region.
>>> +
>>> +Optional properties:
>>> +- samsung,usb-phyhandle : should point to usb-phyhandle sub-node which
>>> provides
>>> +   binding data to enable/disable device PHY handled
>>> by
>>> +   PMU register.
>>> +
>>> +   Required properties:
>>> +   - compatible : should be "samsung,usbdev-phyctrl"
>>> for
>>> +   DEVICE type phy.
>>> +   - samsung,phyhandle-reg: base physical address of
>>> +   PHY_CONTROL register in
>>> PMU.
>>> +- samsung,enable-mask : should be '1'
>>
>>
>> This should only be 1 for Exynos4210+ SoCs, right ?

Yes that's true Exynso4210+ SoCs have only single PHY for both host and device
which gets enabled by single bit.

>> S5PV210 uses bit 0 for OTG and bit1 for USB host, doesn't it ? And for
>> s3c64xx
>> it seems to be bit 16.
>>
True, S5PV210 uses two bits separately for OTG and HOST, so in that
case we would
require to set both these bits. Thanks for pointing out !!

I couldn't see device tree support for S5PV210 and S3C64xx so thought
of going for
4210+ SoCs. Better we make this more generic so that once these SoCs
are moved to
device tree we don't face any issue. Right ??

>> How about deriving this information from 'compatible' property instead ?
>>

It will definitely be good to use the compatible property to derive
such information,
Need to amend the current approach.

>> Maybe you could just encode the USB PMU registers (I assume those aren't
>> touched by anything but the usb drivers) in a regular 'reg' property in
>> an usbphy subnode. Then the driver could interpret it also with help
>> of 'compatible' property. And you could just use of_iomap(). E.g.
>>
>>  usbphy@1213 {
>> compatible = "samsung,exynos5250-usbphy";
>> reg = <0x1213 0x100>, <0x1210 0x100>;
>> usbphy-pmu {
>> /* USB device and host PHY_CONTROL registers */
>> reg = <0x10040704 8>;
>> };
>>  };
>>

This approach seems nice.

>> Your "samsung,usb-phyhandle" approach seems over-engineered to me.
>> I might be missing something though.
>>

The idea behind using phandles for usb-phy was to get the multiple
registers (2 in PMU
and 1 in SYSREG) and program them separately as required.

>>
>>> diff --git a/drivers/usb/phy/samsung-usbphy.c
>>> b/drivers/usb/phy/samsung-usbphy.c
>>> index 5c5e1bb5..4ceabe3 100644
>>> --- a/drivers/usb/phy/samsung-usbphy.c
>>> +++ b/drivers/usb/phy/samsung-usbphy.c
>>> @@ -72,6 +72,8 @@ enum samsung_cpu_type {
>>>* @dev: The parent device supplied to the probe function
>>>* @clk: usb phy clock
>>>* @regs: usb phy register memory base
>>> + * @devctrl_reg: usb device phy-control pmu register memory base
>>
>>
>> hum, this name is not really helpful in understanding what's going
>> on here.
>>
>> Looking at arch/arm/mach-s5pv210/setup-usb-phy.c, there is only one
>> PHY_CONTROL (Power Management Unit) register for both OTG and USB host
>> PHYs. So are you really taking care of that case as well ?
>>
This doesn't take care of s3pv210. Will  amend this to ensure that.

>>
>>> + * @en_mask: enable

Re: [RFC PATCH] Fix Intel IOMMU support for Marvell 88SE91xx SATA controllers.

[Chu Ying]

On 2012-12-19, at 18:58, Andrew Cooks  wrote:

> This is my second attempt to make Marvell 88SE91xx SATA controllers work when 
> IOMMU is enabled.[1][2] 
> As suggested, it no longer tries to add support for phantom functions.
> 
> What's missing:
> * No AMD support. I need some help with this.
> * Table of affected chip IDs is incomplete. I think 0x9123, 0x9125, 0x9128 
> are also affected.

That's not that simple, those devices with 2 functions( one for sata and the 
other for pata) work well under Intel IOMMU, so I need comfirm what devices 
should be involved the latest patch.

> Patch is against 3.7.1
> 
> Review and feedback would be appreciated.
> 
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=757166
> 2. https://bugzilla.kernel.org/show_bug.cgi?id=42679
> 
> Signed-off-by: Andrew Cooks 
> ---
> drivers/iommu/intel-iommu.c |   36 ++--
> drivers/pci/quirks.c|   34 ++
> include/linux/pci.h |1 +
> 3 files changed, 66 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 0badfa4..17e64c0 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -1672,6 +1674,31 @@ static int domain_context_mapping_one(struct 
> dmar_domain *domain, int segment,
>return 0;
> }
> 
> +/* For buggy devices like Marvell 88SE91xx chips that use unclaimed
> + * functions.
> + */
> +static int map_quirky_dma_fn(struct dmar_domain *domain,
> +struct pci_dev *pdev,
> +int translation)
> +{
> +u8 fn;
> +int err = 0;
> +
> +for (fn = 1; fn < 8; fn++) {
> +if (pci_func_is_dma_source(pdev, fn)) {
> +err = domain_context_mapping_one(domain,
> +pci_domain_nr(pdev->bus),
> +pdev->bus->number,
> +PCI_DEVFN(PCI_SLOT(pdev->devfn), fn),
> +translation);
> +if (err)
> +return err;
> +dev_dbg(&pdev->dev, "func: %d mapped dma quirk", fn);
> +}
> +}
> +return 0;
> +}
> +
> static int
> domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev,
>int translation)
> @@ -1685,6 +1712,11 @@ domain_context_mapping(struct dmar_domain *domain, 
> struct pci_dev *pdev,
>if (ret)
>return ret;
> 
> +/* quirk for undeclared pci functions */
> +ret = map_quirky_dma_fn(domain, pdev, translation);
> +if (ret)
> +return ret;
> +
>/* dependent device mapping */
>tmp = pci_find_upstream_pcie_bridge(pdev);
>if (!tmp)
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 7a451ff..8d02bac 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3227,6 +3227,40 @@ static const struct pci_dev_dma_source {
>{ 0 }
> };
> 
> +static const struct pci_dev_dma_source_funcs {
> +u16 vendor;
> +u16 device;
> +u8 func_map;/* bit map. lsb is fn 0. */
> +} pci_dev_dma_source_funcs[] = {
> + {0x1b4b, 0x9172, (1<<0)|(1<<1)},
> + { 0 },
> +};

Can you confirm function 0 should be marked? Per my PCIe trace, I found no 
function 0 involved in DMA access?

> +static u8 pci_get_dma_source_map(struct pci_dev *dev)
> +{
> +const struct pci_dev_dma_source_funcs *i;
> +
> +for (i = pci_dev_dma_source_funcs; i->func_map; i++) {
> +if ((i->vendor == dev->vendor ||
> + i->vendor == (u16)PCI_ANY_ID) &&
> +(i->device == dev->device ||
> + i->device == (u16)PCI_ANY_ID)) {
> +return i->func_map;
> +}
> +}
> +return 0;
> +}
> +
> +int pci_func_is_dma_source(struct pci_dev *dev, int fn)
> +{
> +u8 fn_map = pci_get_dma_source_map(dev);
> +
> +if (fn_map & (1 << fn))
> +return 1;
> +
> +return 0;
> +}
> +
> /*
>  * IOMMUs with isolation capabilities need to be programmed with the
>  * correct source ID of a device.  In most cases, the source ID matches
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index ee21795..8f0fa7f 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1546,6 +1546,7 @@ enum pci_fixup_pass {
> #ifdef CONFIG_PCI_QUIRKS
> void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
> struct pci_dev *pci_get_dma_source(struct pci_dev *dev);
> +int pci_func_is_dma_source(struct pci_dev *dev, int fn);
> int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
> #else
> static inline void pci_fixup_device(enum pci_fixup_pass pass,
> -- 
> 1.7.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device

[Vivek Gautam]

CC: Doug Anderson


On Thu, Dec 13, 2012 at 9:39 PM, Vivek Gautam  wrote:
> On Thu, Dec 13, 2012 at 8:22 PM, Vivek Gautam  
> wrote:
>> Using specific chip in compatible strings. Newer SOCs can claim
>> device by using older string in the compatible list.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/usb/host/ehci-s5p.c|2 +-
>>  drivers/usb/host/ohci-exynos.c |2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
>> index 319dcfa..f18e6ac 100644
>> --- a/drivers/usb/host/ehci-s5p.c
>> +++ b/drivers/usb/host/ehci-s5p.c
>> @@ -266,7 +266,7 @@ static const struct dev_pm_ops s5p_ehci_pm_ops = {
>>
>>  #ifdef CONFIG_OF
>>  static const struct of_device_id exynos_ehci_match[] = {
>> -   { .compatible = "samsung,exynos-ehci" },
>> +   { .compatible = "samsung,exynos4210-ehci" },
>> {},
>>  };
>>  MODULE_DEVICE_TABLE(of, exynos_ehci_match);
>> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
>> index aa3b884..77f2017 100644
>> --- a/drivers/usb/host/ohci-exynos.c
>> +++ b/drivers/usb/host/ohci-exynos.c
>> @@ -267,7 +267,7 @@ static const struct dev_pm_ops exynos_ohci_pm_ops = {
>>
>>  #ifdef CONFIG_OF
>>  static const struct of_device_id exynos_ohci_match[] = {
>> -   { .compatible = "samsung,exynos-ohci" },
>> +   { .compatible = "samsung,exynos4210-ohci" },
>> {},
>>  };
>>  MODULE_DEVICE_TABLE(of, exynos_ohci_match);
>> --
>> 1.7.6.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Thanks & Regards
> Vivek



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] usb: dwc3-exynos: Fix compatible strings for the device

[Vivek Gautam]

CC: Doug Anderson


On Thu, Dec 13, 2012 at 9:40 PM, Vivek Gautam  wrote:
> CC: LKML
>
> On Thu, Dec 13, 2012 at 8:22 PM, Vivek Gautam  
> wrote:
>> Using specific chip in compatible strings. Newer SOCs can claim
>> device by using older string in the compatible list.
>>
>> Signed-off-by: Vivek Gautam 
>> ---
>>  drivers/usb/dwc3/dwc3-exynos.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index aae5328..9dce99a 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -188,7 +188,7 @@ static int dwc3_exynos_remove(struct platform_device 
>> *pdev)
>>
>>  #ifdef CONFIG_OF
>>  static const struct of_device_id exynos_dwc3_match[] = {
>> -   { .compatible = "samsung,exynos-dwc3" },
>> +   { .compatible = "samsung,exynos5250-dwc3" },
>> {},
>>  };
>>  MODULE_DEVICE_TABLE(of, exynos_dwc3_match);
>> --
>> 1.7.6.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Thanks & Regards
> Vivek



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] of: Fix export of of_find_matching_node_and_match()

[Rob Herring]

On 12/19/2012 05:02 AM, Grant Likely wrote:
> On Wed, Dec 19, 2012 at 10:58 AM, Grant Likely
>  wrote:
>> Commit 50c8af4cf9, "of: introduce for_each_matching_node_and_match()"
>> renamed of_find_matching_node() to of_find_matching_node_and_match() and
>> created a new static inline of_find_matching_node() wrapper around the
>> new name. However, the change neglected to change the EXPORT_SYMBOL()
>> reference causing build errors for modules.
>>
>> This patch fixes the EXPORT_SYMBOL() statement. Discovered on a PowerPC
>> Efika build with the mpc52xx_uart driver being built as a module.
>>
>> Reported-by: Benjamin Herrenschmidt 
>> Signed-off-by: Grant Likely 
>> Cc: Stephen Warren 
>> Cc: Rob Herring 
>> Cc: Anatolij Gustschin 
> 
> Rob, I've just pushed this out to my devicetree/merge branch. If
> you've got any fixes queued up for Linus, then please pull this in
> before sending them on to him. Otherwise I'll send Linus a pull req
> for this fix this evening. Ether way, please reply to let me know what
> you're going to do.
> 

The only item on my todo is this one:

"of: define struct device in of_platform.h if !OF_DEVICE and !OF_ADDRESS"

But I'm not going to get to it today if you want to pick it up.

Rob

> g.
> 
> The following changes since commit 752451f01c4567b506bf4343082682dbb8fb30dd:
> 
>   Merge branch 'i2c-embedded/for-next' of
> git://git.pengutronix.de/git/wsa/linux (2012-12-18 16:51:10 -0800)
> 
> are available in the git repository at:
> 
>   git://git.secretlab.ca/git/linux-2.6 devicetree/merge
> 
> for you to fetch changes up to 80c2022e5645a1a789531d13010292c5c18bf1db:
> 
>   of: Fix export of of_find_matching_node_and_match() (2012-12-19
> 10:58:53 +)
> 
> 
> Grant Likely (1):
>   of: Fix export of of_find_matching_node_and_match()
> 
>  drivers/of/base.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
>> ---
>>
>> I'll push this patch out to my tree ASAP.
>>
>>  drivers/of/base.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/base.c b/drivers/of/base.c
>> index db8d211..2390ddb 100644
>> --- a/drivers/of/base.c
>> +++ b/drivers/of/base.c
>> @@ -629,7 +629,7 @@ struct device_node 
>> *of_find_matching_node_and_match(struct device_node *from,
>> read_unlock(&devtree_lock);
>> return np;
>>  }
>> -EXPORT_SYMBOL(of_find_matching_node);
>> +EXPORT_SYMBOL(of_find_matching_node_and_match);
>>
>>  /**
>>   * of_modalias_node - Lookup appropriate modalias for a device node
>> --
>> 1.7.10.4
>>
> 
> 
> 
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/2] ARM: Exynos5250: Enabling ehci-s5p driver

[Vivek Gautam]

CC: Doug Anderson


On Sat, Dec 15, 2012 at 12:53 PM, Grant Likely
 wrote:
> On Thu, 13 Dec 2012 22:06:01 +0530, Vivek Gautam  
> wrote:
>> Adding EHCI device tree node for Exynos5250 along with
>> the device base adress and gpio line for vbus.
>>
>> Signed-off-by: Vivek Gautam 
>> Acked-by: Jingoo Han 
>> ---
>>  .../devicetree/bindings/usb/exynos-usb.txt |   25 
>> 
>>  arch/arm/boot/dts/exynos5250-smdk5250.dts  |4 +++
>>  arch/arm/boot/dts/exynos5250.dtsi  |6 
>>  arch/arm/mach-exynos/include/mach/map.h|1 +
>>  arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
>>  5 files changed, 38 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/usb/exynos-usb.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
>> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> new file mode 100644
>> index 000..e8bbb47
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> @@ -0,0 +1,25 @@
>> +Samsung Exynos SoC USB controller
>> +
>> +The USB devices interface with USB controllers on Exynos SOCs.
>> +The device node has following properties.
>> +
>> +EHCI
>> +Required properties:
>> + - compatible: should be "samsung,exynos4210-ehci" for USB 2.0
>> +   EHCI controller in host mode.
>> + - reg: physical base address of the controller and length of memory mapped
>> +   region.
>> + - interrupts: interrupt number to the cpu.
>> +
>> +Optional properties:
>> + - samsung,vbus-gpio:  if present, specifies the GPIO that
>> +   needs to be pulled up for the bus to be powered.
>> +
>> +Example:
>> +
>> + usb@1211 {
>> + compatible = "samsung,exynos4210-ehci";
>> + reg = <0x1211 0x100>;
>> + interrupts = <0 71 0>;
>> + samsung,vbus-gpio = <&gpx2 6 1 3 3>;
>> + };
>> diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
>> b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> index 711b55f..f990086 100644
>> --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
>> @@ -218,4 +218,8 @@
>>   i2s_2: i2s@12D7 {
>>   status = "disabled";
>>   };
>> +
>> + usb@1211 {
>> + samsung,vbus-gpio = <&gpx2 6 1 3 3>;
>> + };
>>  };
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 581e57a..584bb9a 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -299,6 +299,12 @@
>>   rx-dma-channel = <&pdma0 11>; /* preliminary */
>>   };
>>
>> + usb@1211 {
>> + compatible = "samsung,exynos4210-ehci";
>> + reg = <0x1211 0x100>;
>> + interrupts = <0 71 0>;
>> + };
>> +
>>   amba {
>>   #address-cells = <1>;
>>   #size-cells = <1>;
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h 
>> b/arch/arm/mach-exynos/include/mach/map.h
>> index cbb2852..b2c662f 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -201,6 +201,7 @@
>>  #define EXYNOS4_PA_EHCI  0x1258
>>  #define EXYNOS4_PA_OHCI  0x1259
>>  #define EXYNOS4_PA_HSPHY 0x125B
>> +#define EXYNOS5_PA_EHCI  0x1211
>>  #define EXYNOS4_PA_MFC   0x1340
>>
>>  #define EXYNOS4_PA_UART  0x1380
>> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c 
>> b/arch/arm/mach-exynos/mach-exynos5-dt.c
>> index 462e5ac..b3b9af1 100644
>> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
>> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
>> @@ -110,6 +110,8 @@ static const struct of_dev_auxdata 
>> exynos5250_auxdata_lookup[] __initconst = {
>>   "samsung-i2s.1", NULL),
>>   OF_DEV_AUXDATA("samsung,samsung-i2s", 0x12D7,
>>   "samsung-i2s.2", NULL),
>> + OF_DEV_AUXDATA("samsung,exynos4210-ehci", EXYNOS5_PA_EHCI,
>> + "s5p-ehci", NULL),
>
> I'm assuming the above change is temporary. What is left to be done to
> drop the auxdata in theses two patches?
>
> Otherwise the patch looks fine.
>
> Acked-by: Grant Likely 
> --
> 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/



-- 
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 32kHz clock removal causes problems omap_hsmmc

[Benoit Cousson]

On 12/19/2012 02:01 PM, Felipe Balbi wrote:
> Hi,
> 
> +Sricharan who commited that
> 
> On Wed, Dec 19, 2012 at 11:56:20AM +0100, Peter Ujfalusi wrote:
>> On 12/19/2012 11:45 AM, Luciano Coelho wrote:
 Well, we still haven't got the foggiest idea what the actual problem is
 beyond that it's probably related to the 32kHz clock in some way (unless
 it was one of the other reverts that coincidentally made a difference,
 but we don't know what they were) so it's unlikely that just randomly
 implementing clock support is going to fix anything immediately here.
>>>
>>> This is exactly what I had to revert (as I mentioned in the other email,
>>> I had to revert the other patches otherwise compilation would break):
>>>
>>> 0e8e5c34 "regulator: twl: Remove references to 32kHz clock from DT bindings"
>>> e76ab829 "regulator: twl: Remove references to the twl4030 regulator"
>>> 029dd3ce "regulator: twl: Remove another unused variable warning"
>>
>> Yeah. 32k clock is not provided by twl.
>>
>> As I said I need to take a look at CCF to see if it already there. If it is
>> clock driver + mapping + patch for wl12xx should fix the issue you are 
>> facing.
>>
>>> Let me know if you need more info.
>>
>> BTW: have you happened to ubdate u-boot recently? There is a nice easter egg
>> added there:
>> f3f98bb ARM: OMAP4/5: Do not configure non essential pads, clocks, dplls.
>>
>> Which means that _essential_ clocks and pads are no longer configured.
> 
> anything essential you can list ?

Yeah, that u-boot version is just unusable at all with any mainline
kernel, since we are still missing pads conf for every drivers.

Regarding the 32k clock, I noticed as well that the OMAP4460 panda
u-boot is the only one to enable it at boot time, and thus this is the
only board that can probe the wilink chip properly as of today.

Regards,
Benoit

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] ARM: Exynos5250: Enabling dwc3-exynos driver

[Vivek Gautam]

CC: Doug Anderson


On Thu, Dec 13, 2012 at 10:17 PM, Vivek Gautam  wrote:
> Adding DWC3 device tree node for Exynos5250 along with the
> device address and clock support needed for the controller.
>
> Signed-off-by: Vivek Gautam 
> ---
> Changes from v2:
>  - Changed the compatible string to chip specific(samsung,exynos5250),
>since dwc3-exynos is being used from exynso5250 onwards.
>  - Based on changes for USB 2.0:
>
> https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-December/024413.html
>
> Changes from v1:
>  - Changed the device node name from 'dwc3' to 'usb@1200'.
>  - Added the documentation for device tree bindings for dwc3 controller.
>
>
>  .../devicetree/bindings/usb/exynos-usb.txt |   14 +++
>  arch/arm/boot/dts/exynos5250.dtsi  |6 +
>  arch/arm/mach-exynos/Kconfig   |1 +
>  arch/arm/mach-exynos/clock-exynos5.c   |   24 
> 
>  arch/arm/mach-exynos/include/mach/map.h|1 +
>  arch/arm/mach-exynos/mach-exynos5-dt.c |2 +
>  6 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index f66fcdd..d660410 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -38,3 +38,17 @@ Example:
> reg = <0x1212 0x100>;
> interrupts = <0 71 0>;
> };
> +
> +DWC3
> +Required properties:
> + - compatible: should be "samsung,exynos5250-dwc3" for USB 3.0 DWC3 
> controller.
> + - reg: physical base address of the controller and length of memory mapped
> +   region.
> + - interrupts: interrupt number to the cpu.
> +
> +Example:
> +   usb@1200 {
> +   compatible = "samsung,exynos5250-dwc3";
> +   reg = <0x1200 0x1>;
> +   interrupts = <0 72 0>;
> +   };
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index 75510d1..001a31b 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -299,6 +299,12 @@
> rx-dma-channel = <&pdma0 11>; /* preliminary */
> };
>
> +   usb@1200 {
> +   compatible = "samsung,exynos5250-dwc3";
> +   reg = <0x1200 0x1>;
> +   interrupts = <0 72 0>;
> +   };
> +
> usb@1211 {
> compatible = "samsung,exynos4210-ehci";
> reg = <0x1211 0x100>;
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 91d5b6f..09f9587 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -426,6 +426,7 @@ config MACH_EXYNOS5_DT
> depends on ARCH_EXYNOS5
> select ARM_AMBA
> select USE_OF
> +   select USB_ARCH_HAS_XHCI
> help
>   Machine support for Samsung EXYNOS5 machine with device tree 
> enabled.
>   Select this if a fdt blob is available for the EXYNOS5 SoC based 
> board.
> diff --git a/arch/arm/mach-exynos/clock-exynos5.c 
> b/arch/arm/mach-exynos/clock-exynos5.c
> index 5c63bc7..f2214a0 100644
> --- a/arch/arm/mach-exynos/clock-exynos5.c
> +++ b/arch/arm/mach-exynos/clock-exynos5.c
> @@ -768,6 +768,11 @@ static struct clk exynos5_init_clocks_off[] = {
> .enable = exynos5_clk_ip_fsys_ctrl ,
> .ctrlbit= (1 << 18),
> }, {
> +   .name   = "usbdrd30",
> +   .parent = &exynos5_clk_aclk_200.clk,
> +   .enable = exynos5_clk_ip_fsys_ctrl,
> +   .ctrlbit= (1 << 19),
> +   }, {
> .name   = "usbotg",
> .enable = exynos5_clk_ip_fsys_ctrl,
> .ctrlbit= (1 << 7),
> @@ -1121,6 +1126,16 @@ static struct clksrc_sources exynos5_clkset_group = {
> .nr_sources = ARRAY_SIZE(exynos5_clkset_group_list),
>  };
>
> +struct clk *exynos5_clkset_usbdrd30_list[] = {
> +   [0] = &exynos5_clk_mout_mpll.clk,
> +   [1] = &exynos5_clk_mout_cpll.clk,
> +};
> +
> +struct clksrc_sources exynos5_clkset_usbdrd30 = {
> +   .sources= exynos5_clkset_usbdrd30_list,
> +   .nr_sources = ARRAY_SIZE(exynos5_clkset_usbdrd30_list),
> +};
> +
>  /* Possible clock sources for aclk_266_gscl_sub Mux */
>  static struct clk *clk_src_gscl_266_list[] = {
> [0] = &clk_ext_xtal_mux,
> @@ -1415,6 +1430,15 @@ static struct clksrc_clk exynos5_clksrcs[] = {
> .parent = &exynos5_clk_mout_cpll.clk,
> },
> .reg_div = { .reg = EXYNOS5_CLKDIV_GEN, .shift = 4, .size = 3 
> },
> +   }, {
> +   .clk= {
> +   .name   = "sclk_usbdrd30",
> +   .enable 

Re: [PATCH] rtc: tx4939: Kill get_tx4939rtc_plat_data() function

[Atsushi Nemoto]

On Wed, 19 Dec 2012 17:29:04 +0800, Axel Lin  wrote:
> Simply use dev_get_drvdata() instead.
> 
> Signed-off-by: Axel Lin 
> ---
>  drivers/rtc/rtc-tx4939.c |   21 -
>  1 file changed, 8 insertions(+), 13 deletions(-)

Hi Axel,

Thank you for cleanup, but, a platform driver should use
platform_get_drvdata / platform_set_drvdata, no?

I think using dev_get_drvdata() in platform_get_drvdata() is an
implementation detail of the platform device framework, so we should
not depends on such an internal detail.

If there was any reason to use dev_get_drvdata, please convert all
platform_get_drvdata and platform_set_drvdata to dev_get_drvdata and
dev_set_drvdata.  We should avoid mixing two APIs.

---
Atsushi Nemoto
--
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/