Re: [PATCH v3 13/15] cpufreq: Add cpufreq driver for Tegra124

[Viresh Kumar]

On 19 August 2014 09:03, Tuomas Tynkkynen  wrote:
> From: Tuomas Tynkkynen 
>
> Add a new cpufreq driver for Tegra124. Instead of using the PLLX as
> the CPU clocksource, switch immediately to the DFLL. It allows the use
> of higher clock rates, and will automatically scale the CPU voltage as
> well. Besides the CPU clocksource switch, we let the cpufreq-cpu0 driver
> for all the cpufreq operations.
>
> This driver also relies on the DFLL driver to fill the OPP table for the
> CPU0 device, so that the cpufreq-cpu0 driver knows what frequencies to
> use.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
> v3:
>  - separate Kconfig entry

Gud..

>  - use 'select GENERIC_CPUFREQ_CPU0', not depends

Bad :(

It *has* to be a depends here, its not optional. That was outcome of the
chat we had last time, if I remember it well..

>  - support unbinding of the platform device
>  - allocate a state structure instead of globals
>  - use of_match_machine()
>  - various style nits fixed
> ---

You don't need to add these --- here, just add a blank line and git
will take care of things for you :)

>  drivers/cpufreq/Kconfig.arm|   8 ++
>  drivers/cpufreq/Makefile   |   1 +
>  drivers/cpufreq/tegra124-cpufreq.c | 206 
> +
>  3 files changed, 215 insertions(+)
>  create mode 100644 drivers/cpufreq/tegra124-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 3795a16..07bfed1 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -247,3 +247,11 @@ config ARM_TEGRA20_CPUFREQ
> default y
> help
>   This adds the CPUFreq driver support for Tegra20 SOCs.
> +
> +config ARM_TEGRA124_CPUFREQ
> +   bool "Tegra124 CPUFreq support"
> +   depends on ARCH_TEGRA
> +   select GENERIC_CPUFREQ_CPU0

So it will become: depends on ARCH_TEGRA && GENERIC_CPUFREQ_CPU0

> +static int tegra124_cpufreq_probe(struct platform_device *pdev)
> +{

> +   priv->vdd_cpu_reg = regulator_get(get_cpu_device(0), "vdd-cpu");

get_cpu_device() can fail as well, and so you may want to check its return
value as well..

> +static int __init tegra_cpufreq_init(void)
> +{
> +   int ret;
> +   struct platform_device *pdev;
> +
> +   if (!of_match_machine(soc_of_matches))
> +   return -ENODEV;

You may want to add a comment here on why you chose to add another layer
of platform device/driver.. i.e. to catch -EPROBE_DEFER from clk-APIs..

> +   ret = platform_driver_register(_cpufreq_platdrv);
> +   if (ret)
> +   return ret;
> +
> +   pdev = platform_device_register_simple("cpufreq-tegra124", -1, NULL, 
> 0);
> +   if (IS_ERR(pdev)) {
> +   platform_driver_unregister(_cpufreq_platdrv);
> +   return PTR_ERR(pdev);
> +   }
> +
> +   return 0;
> +}
> +module_init(tegra_cpufreq_init);
> +
> +MODULE_AUTHOR("Tuomas Tynkkynen ");
> +MODULE_DESCRIPTION("cpufreq driver for NVIDIA Tegra124");
> +MODULE_LICENSE("GPL v2");
> --
> 1.8.1.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 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 01:40 PM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 10:19 PM, Xiao Guangrong
>  wrote:
>> On 08/19/2014 01:00 PM, David Matlack wrote:
>>> On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
>>>  wrote:
 On 08/19/2014 12:31 PM, David Matlack wrote:
> The single line patch I suggested was only intended to fix the "forever
> incorrectly exit mmio".

 My patch also fixes this case and that does not doubly increase the
 number. I think this is the better one.
>>>
>>> I prefer doubly increasing the generation for this reason: the updated 
>>> boolean
>>> requires extra code on the "client-side" to check if there's an update in
>>> progress. And that makes it easy to get wrong. In fact, your patch
>>> forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
>>> generation requires no "client-side" code to work.
>>
>> No, the updated patch is used to fix case 2 which i draw the scenario in
>> the last mail. I mean the original patch in this patchset which just
>> increase the number after srcu-sync.
>>
>> Then could you tell me that your approach can do but my original patch can 
>> not?
> 
> It avoids publishing new memslots with an old generation number attached to
> them (even if it only lasts for a short period of time). 

I can not see the problem if that happen, could you please draw the scenario?

> Do you have a reason
> why you don't want to doubly increase the generation?

That more easily causes the number wrap-around.

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

Re: [PATCH 3/3] perf callchain: Prune misleading callchains for self entries

[Namhyung Kim]

Hi Jiri,

On Mon, 18 Aug 2014 13:31:47 +0200, Jiri Olsa wrote:
> On Sat, Aug 16, 2014 at 11:26:31AM +0900, Namhyung Kim wrote:
>
> SNIP
>
>> > 
>> > hum, where is it callee/caller mixed?  with following example:
>> > 
>> > ---
>> > void c(void)
>> > {
>> > }
>> > 
>> > void b(void)
>> > {
>> > c();
>> > }
>> > 
>> > void a(void)
>> > {
>> > b();
>> > }
>> > 
>> > int main(void)
>> > {
>> > while(1) {
>> > a();
>> > b();
>> > c();
>> > }
>> > }
>> > ---
>> > 
>> > for 'c' the current code will display:
>> > 
>> > -   43.74%43.74%  tt [.] c 
>> >▒
>> >- __libc_start_main 
>> >▒
>> >   - 86.33% main
>> >▒
>> >67.08% c
>> >▒
>> >  - 32.91% a
>> >▒
>> >   99.44% c 
>> >▒
>> > - 0.56% b  
>> >▒
>> >  c 
>> >▒
>> > 13.67% c   
>> >▒
>> > 
>> > and with this patch:
>> > 
>> > -   43.74%43.74%  tt [.] c 
>> >▒
>> >  c 
>> >▒
>> > 
>> > 
>> > The 'c' callchain is still in caller order. IMO we should
>> > keep whole callchain here.
>> 
>> The problem is not in pure self entry (that has self overhead = children
>> overhead) and pure cumulative entry (self overhead = 0).  It's in mixed
>> entries, please see last two examples in the description 0/3.
>
> right, but it still affects pure entries as well
> anyway, let's see the mixed entry
>
> for 'a' the current code will display:
> -   31.97%17.16%  tt  [.] a   
>  ▒
>- __libc_start_main
>  ◆
> 81.08% a  
>  ▒
>   - 18.92% main   
>  ▒
>a  
>  ▒
>- a
>  ▒
> 85.05% c  
>  ▒
>   - 14.91% b  
>  ▒
>100.00% c  
>  ▒
>
> and with this patch:
> -   31.97%17.16%  tt  [.] a   
>  ▒
>- a
>  ▒
> 85.05% c  
>  ▒
>   - 14.91% b  
>  ▒
>100.00% c  
>  ▒
>
> so we'll miss the 'self' callchain of 'a' symbol
>
> if we want to avoid the confusion about 2 different callchains, how
> about marking them with 'self' and 'children' tags, instead of removing
> one of them, like:
>
> for 'a' the current code will display:
> -   31.97%17.16%  tt  [.] a   
>  ▒
>- [self]
>  __libc_start_main
>  ◆
> 81.08% a

Re: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

[Li, ZhenHua]

I found there are more data need to be cleared for the dump kernel.
So please ignore this patch, I will send out another one.

Thanks
Zhenhua

On 08/19/2014 07:59 AM, Li, Zhen-Hua wrote:

My debugging result is this:

1. Clear the old root entry table, dump kernel will choose another
  memory region for root entry.
2. Do NOT clear the old root entry, when dump kernel initializing
the iommu data structure, it  will allocate memory for root entry,
this is different from the old address.

If not clear old entry , the error message appears before dump kernel
finishes the iommu init works, and also appears in other places(before
device inits).

If I clear the old root entry, the error message disappears before iommu
init work finish, but still appears in other places.

-Original Message-
From: Li, Zhen-Hua
Sent: Tuesday, August 19, 2014 7:48 AM
To: Li, Zhen-Hua; Joerg Roedel
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

When the dump kernel boots, it will initialize iommu again, and the root entry 
will be allocted
in another memory region.

That means, no matter kernel clears the old root entry table or not,  the dump 
kernel will use
another memory region when iommu initializing.

-Original Message-
From: Li, Zhen-Hua
Sent: Tuesday, August 19, 2014 7:27 AM
To: 'Joerg Roedel'
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

: [fault reason 01] Present bit in root entry is clear
It appears when iommu initializing in the kdump kernel.

-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Tuesday, August 19, 2014 7:23 AM
To: Li, Zhen-Hua
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

On Mon, Aug 18, 2014 at 11:01:56PM +, Li, Zhen-Hua wrote:

There is a bug when Linux running on an HP large system:
when kdump kernel runs, the hardware is still using the old
root entry. This causes error message when iommu not finished initialization.

What error message are you seeing? When the kdump kernel boots the iommu
should be still enabled from the old kernel with the old root-entry. So
any in-flight DMA initiated from the old kernel can still pass and there
should be no error messages.

When you clear the root-entry that in-flight DMA might go to another
random location in system memory or just fail, no?


Joerg



--
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] builddeb: put the dbg files into the correct directory

[Darrick J. Wong]

Since the conversion of objtree to use relative pathnames (commit
7e1c04779e, "kbuild: Use relative path for $(objtree)"), the debug
info files have been ending up in /debian/dbgtmp/ in the regular
linux-image package instead of the debug files package.  Fix up the
paths so that the debug files end up in the -dbg package.

Signed-off-by: Darrick J. Wong 
---
 scripts/package/builddeb |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 5707466..0456322 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -153,15 +153,16 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
fi
if [ -n "$BUILD_DEBUG" ] ; then
(
+   old_dir="$(pwd)"
cd $tmpdir
for module in $(find lib/modules/ -name *.ko); do
-   mkdir -p $(dirname 
$dbg_dir/usr/lib/debug/$module)
+   mkdir -p $(dirname 
$old_dir/$dbg_dir/usr/lib/debug/$module)
# only keep debug symbols in the debug file
-   $OBJCOPY --only-keep-debug $module 
$dbg_dir/usr/lib/debug/$module
+   $OBJCOPY --only-keep-debug $module 
$old_dir/$dbg_dir/usr/lib/debug/$module
# strip original module from debug symbols
$OBJCOPY --strip-debug $module
# then add a link to those
-   $OBJCOPY 
--add-gnu-debuglink=$dbg_dir/usr/lib/debug/$module $module
+   $OBJCOPY 
--add-gnu-debuglink=$old_dir/$dbg_dir/usr/lib/debug/$module $module
done
)
fi
--
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] zram: add num_discards for discarded pages stat

[Chao Yu]

> -Original Message-
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of 
> Sergey
> Senozhatsky
> Sent: Friday, August 15, 2014 2:12 PM
> To: Chao Yu
> Cc: minc...@kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org; 
> ngu...@vflare.org;
> 'Jerome Marchand'; 'Sergey Senozhatsky'; 'Andrew Morton'
> Subject: Re: [PATCH] zram: add num_discards for discarded pages stat
> 
> On (08/15/14 11:27), Chao Yu wrote:
> > Now we have supported handling discard request which is sended by 
> > filesystem,
> > but no interface could be used to show information of discard.
> > This patch adds num_discards to stat discarded pages, then export it to 
> > sysfs
> > for displaying.
> >
> 
> a side question: we account discarded pages via slot free notify in
> notify_free and via req_discard in num_discards. how about accounting
> both of them in num_discards? because, after all, they account a number
> of discarded pages (zram_free_page()). or there any particular reason we
> want to distinguish.

Yeah, I agree with you as I have no such reason unless there are our users'
explicitly requirement for showing notify_free/num_discards separately later.

How do you think of sending another patch to merge these two counts?

One more thing is that I am missing to update document of zram, sorry about
that, let me update it in v2.

Thanks,
Yu

> 
>   -ss
> 
> > Signed-off-by: Chao Yu 
> > ---
> >  Documentation/ABI/testing/sysfs-block-zram | 10 ++
> >  drivers/block/zram/zram_drv.c  |  3 +++
> >  drivers/block/zram/zram_drv.h  |  1 +
> >  3 files changed, 14 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> b/Documentation/ABI/testing/sysfs-block-zram
> > index 70ec992..fa8936e 100644
> > --- a/Documentation/ABI/testing/sysfs-block-zram
> > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > @@ -57,6 +57,16 @@ Description:
> > The failed_writes file is read-only and specifies the number of
> > failed writes happened on this device.
> >
> > +
> > +What:  /sys/block/zram/num_discards
> > +Date:  August 2014
> > +Contact:   Chao Yu 
> > +Description:
> > +   The num_discards file is read-only and specifies the number of
> > +   physical blocks which are discarded by this device. These blocks
> > +   are included in discard request which is sended by filesystem as
> > +   the blocks are no longer used.
> > +
> >  What:  /sys/block/zram/max_comp_streams
> >  Date:  February 2014
> >  Contact:   Sergey Senozhatsky 
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index d00831c..904e7a5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -606,6 +606,7 @@ static void zram_bio_discard(struct zram *zram, u32 
> > index,
> > bit_spin_lock(ZRAM_ACCESS, >table[index].value);
> > zram_free_page(zram, index);
> > bit_spin_unlock(ZRAM_ACCESS, >table[index].value);
> > +   atomic64_inc(>stats.num_discards);
> > index++;
> > n -= PAGE_SIZE;
> > }
> > @@ -866,6 +867,7 @@ ZRAM_ATTR_RO(num_reads);
> >  ZRAM_ATTR_RO(num_writes);
> >  ZRAM_ATTR_RO(failed_reads);
> >  ZRAM_ATTR_RO(failed_writes);
> > +ZRAM_ATTR_RO(num_discards);
> >  ZRAM_ATTR_RO(invalid_io);
> >  ZRAM_ATTR_RO(notify_free);
> >  ZRAM_ATTR_RO(zero_pages);
> > @@ -879,6 +881,7 @@ static struct attribute *zram_disk_attrs[] = {
> > _attr_num_writes.attr,
> > _attr_failed_reads.attr,
> > _attr_failed_writes.attr,
> > +   _attr_num_discards.attr,
> > _attr_invalid_io.attr,
> > _attr_notify_free.attr,
> > _attr_zero_pages.attr,
> > diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
> > index e0f725c..2994aaf 100644
> > --- a/drivers/block/zram/zram_drv.h
> > +++ b/drivers/block/zram/zram_drv.h
> > @@ -86,6 +86,7 @@ struct zram_stats {
> > atomic64_t num_writes;  /* --do-- */
> > atomic64_t failed_reads;/* can happen when memory is too low */
> > atomic64_t failed_writes;   /* can happen when memory is too low */
> > +   atomic64_t num_discards;/* no. of discarded pages */
> > atomic64_t invalid_io;  /* non-page-aligned I/O requests */
> > atomic64_t notify_free; /* no. of swap slot free notifications */
> > atomic64_t zero_pages;  /* no. of zero filled pages */
> > --
> > 2.0.1.474.g72c7794
> >
> >
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

--
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  

Re: [RFC PATCH 2/9] ACPI: Document ACPI device specific properties

[Darren Hart]

On Mon, Aug 18, 2014 at 11:54:29AM +0100, Mark Rutland wrote:
> Hi Mika,
> 
> While I am very much in favour of having a structured way of describing
> device specific data in ACPI I am very concerned by the idea of assuming
> (a false) equivalence with DT. More on that below.

Hi Mark,

The equivalence is intended in the sense that we should be able to represent any
of the existing schemas with the same properties in ACPI as in DT.

...

> > +An example device where we might need properties is a GPIO keys device.
> > +In addition to the GpioIo/GpioInt resources the driver needs to know how
> > +to map each GpioIo resource to the corresponding Linux input event.
> > +
> > +To solve this we add the following ACPI device properties from the
> > +gpio-keys schema:
> > +
> > +   Device (KEYS) {
> > +   Name (_DSD, Package () {
> > +   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > +   Package () {
> > +   Package () {"poll-interval", 100},
> > +   Package () {"autorepeat", 1}
> > +   }
> > +   })
> > +
> > +   Device (BTN0) {
> > +   Name (_DSD, Package () {
> > +   
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > +   Package () {
> > +   Package () {"linux,code", 105},
> > +   Package () {"linux,input-type", 1},
> 
> The leakage of Linux implementation details into DTBs is bad enough. I
> would really not like to see this kind of thing in ACPI tables.
> 
> Leaking this into HW description of any sort completely rids said
> description of any OS independence, and it's usually short-sighted,
> nonsensical, or ill-defined (what does 'autorepeat' actually mean?).
> 
> I am very worried by the prospect of _DSD making it harder rather than
> easier for an arbitrary OS to use ACPI data due to assumptions being
> made about (a particular revision of) a particular OS.

This is perhaps not the best example to include in the documentation. A guiding
principle has been to only represent in the DSD that which is an actual property
of the hardware.

It is also a goal of the mechanism to enable ACPI systems to reuse the 200+
existing OF-aware drivers in the kernel today. If those schemas are
ill-conceived, we should work to improve the schemas.

On the point of OS-independence, while I agree that using something like the USB
keycodes here would be better, the namespacing employed in these properties
makes it possible to use the same DSD for muliple OSes as another OS could add
it's own keycode, for example, without conflict. Again, that is really an issue
with the schemas, not the _DSD mechanism itself.

Perhaps we should use a different example in the documentation as I would agree
this is not a model schema.

> > +Of course the device driver then needs to iterate over these devices but
> > +it can be done easily via the ->children field of the companion ACPI
> > +device. This will be demonstrated later on in the document.
> > +
> > +If there is an existing Device Tree binding for a device, it is expected
> > +that the same bindings are used with ACPI properties, so that the driver
> > +dealing with the device needs only minor modifications if any.
> 
> For simple devices like a UART which just has a "clock-frequency"
> property in DT, importing both the concept of the property and the key
> name itself is a sensible approach.
> 
> However, I do not think this makes sense as a general design rule. ACPI
> and DT already have different idioms for describing certain things (e.g.
> GPIOs, interrupts) and care needs to be taken to distinguish simple
> device-specific properties from class-specific properties or implied
> linkages between devices.

I believe we have GPIO handled well in this series. In DT terms, ACPI is the
controller, providing a list of GpioIO|GpioInt resources in the CRS of the
referenced object. Arguments are Resource Index, Pin Index, Polarity. The rest
of the properties are handled via the GpioIO|GpioInt resources in the _CRS.

> 
> The "#clock-cells" and "#pwm-cells" _DSD examples in ACPI 5.1 are
> complete nonsense. They import an idiom from DT into ACPI without

Yeah... coming up with good examples for a generic mechanism which are both
descriptive and universally unobjectionable. Good point. We might be able to
improve this via an errata update. What would you recommend?

> considering the surrounding context (cells, lack of typing, phandles,

How are the phandles not covered via the ACPI namespace references?

The point on cells is a good one, and I believe some of this can be mitigated by
providing subsystem specific accessors as we have for GPIO, for example.

> etc). As an example, I worry that why it may be trivial to map pinctrl
> bindings into ACPI _DSD, there is no clear way that 

RE: [PATCH] regmap: fix of_regmap_get_endian()

[li.xi...@freescale.com]

Hi,

I found this patch has some confliction with the Mark's newest Remgap-Tree's
origin/topic/dt-endian branch.

Javier Martinez has already fix some of these.

Thanks,

BRs
Xiubo



> -Original Message-
> From: Thierry Reding [mailto:thierry.red...@gmail.com]
> Sent: Tuesday, August 19, 2014 1:22 PM
> To: Stephen Warren
> Cc: Mark Brown; Thierry Reding; linux-kernel@vger.kernel.org; linux-
> n...@vger.kernel.org; Stephen Warren; Xiubo Li-B47053
> Subject: Re: [PATCH] regmap: fix of_regmap_get_endian()
> 
> On Mon, Aug 18, 2014 at 04:14:04PM -0600, Stephen Warren wrote:
> > From: Stephen Warren 
> >
> > Commit d647c199510c ("regmap: add DT endianness binding support") has
> > some issues. Specifically, if config->reg_format_endian is not explicitly
> > set, it will be zero, i.e. REGMAP_ENDIAN_DEFAULT. The switch statement
> > that looks up the *endian from DT for the type==REGMAP_ENDIAN_VAL case
> > doesn't change *endian in the type==REGMAP_ENDIAN_REG case. However, the
> > test immediately following, compares *endian against REGMAP_ENDIAN_NATIVE,
> > and if not equal, returns *endian as is. This ends up returning
> > REGMAP_ENDIAN_DEFAULT, which the calling code does not expect, eventually
> > leading to e.g.:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 0024
> > ...
> > [] (regcache_cache_only) from []
> (tegra30_ahub_probe+0x1b8/0x430)
> > [] (tegra30_ahub_probe) from []
> (platform_drv_probe+0x2c/0x5c)
> > [] (platform_drv_probe) from []
> (driver_probe_device+0x10c/0x22c)
> > [] (driver_probe_device) from []
> (__driver_attach+0x8c/0x90)
> >
> > This patch solves this by:
> > * When looking up the endianness from DT, don't change *endian at all if
> >   there is no DT property; leave it set to REGMAP_ENDIAN_DEFAULT so the
> >   code falls through to other data sources in the same way as before.
> >   Now, the "unspecified" case acts the same for both REGMAP_ENDIAN_REG and
> >   REGMAP_ENDIAN_VAL.
> > * After potentially looking up the endianness from DT, check *endian
> >   against REGMAP_ENDIAN_DEFAULT instead of REGMAP_ENDIAN_NATIVE to avoid
> >   returning unexpected values.
> >
> > Also, clean up the code a bit:
> >
> > * Make the comments briefer, and only refer to the specific action taken
> >   at their location. This makes most of the comments independent of DT,
> >   and easier to follow.
> > * Restore the overall default of REGMAP_ENDIAN_BIG if none of the config,
> >   DT, or the bus specify any endianness. Since all busses specify an
> >   endianness now, this makes no difference, but I saw no justification in
> >   the patch description for changing the default default.
> > * s/of_regmap_get_endian/regmap_get_endian/ since the function isn't DT-
> >   specific, even if the reason it was originally added was to add some
> >   DT-specific features.
> >
> > Reported-by: Thierry Reding 
> > Fixes: d647c199510c ("regmap: add DT endianness binding support")
> > Cc: Xiubo Li 
> > Signed-off-by: Stephen Warren 
> > ---
> >  drivers/base/regmap/regmap.c | 58 ++---
> ---
> >  1 file changed, 18 insertions(+), 40 deletions(-)
> 
> Thanks for fixing this, Stephen.
> 
> Tested-by: Thierry Reding 
--
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] KVM: fix cache stale memslot info with correct mmio generation number

[David Matlack]

On Mon, Aug 18, 2014 at 10:19 PM, Xiao Guangrong
 wrote:
> On 08/19/2014 01:00 PM, David Matlack wrote:
>> On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
>>  wrote:
>>> On 08/19/2014 12:31 PM, David Matlack wrote:
 The single line patch I suggested was only intended to fix the "forever
 incorrectly exit mmio".
>>>
>>> My patch also fixes this case and that does not doubly increase the
>>> number. I think this is the better one.
>>
>> I prefer doubly increasing the generation for this reason: the updated 
>> boolean
>> requires extra code on the "client-side" to check if there's an update in
>> progress. And that makes it easy to get wrong. In fact, your patch
>> forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
>> generation requires no "client-side" code to work.
>
> No, the updated patch is used to fix case 2 which i draw the scenario in
> the last mail. I mean the original patch in this patchset which just
> increase the number after srcu-sync.
>
> Then could you tell me that your approach can do but my original patch can 
> not?

It avoids publishing new memslots with an old generation number attached to
them (even if it only lasts for a short period of time). Do you have a reason
why you don't want to doubly increase the generation?
--
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] tty: serial: serial_core.c: printk replacement

[Sudip Mukherjee]

>
> Hi, that will not work either, as there is put_device(tty_dev) before
> you use tty_dev.
>
> --
> js
> suse labs
>
Hi,
i missed that. I put my test message to test tty_dev immediately after
tty_dev was initialized and so never got the error when the port was
suspended.
Will change it to pr_err and resend the patch for you to review.

Thanks
Sudip
--
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/

[Question]: redundant interrupts for broadcast timer

[Leo Yan]

hi,

We observed the redundant interrupts for broadcast timer, so want to 
confirm here firstly; pls see below flow:


1. Thread_A starts a hrtimer with 100ms timeout, and then thread_A will 
remove from the runqueue to sleep;
2. The CPU which thread_A runs on will enter idle and call notify 
CLOCK_EVT_NOTIFY_BROADCAST_ENTER, so the CPU will shutdown its local 
timer and set broadcast timer's next event with delta for 100ms;
3. After 70ms later, the CPU is waken up by other peripheral's interrupt 
and thread_A will be waken up as well; thread_A will cancel the hrtimer 
at this point, kernel will remove the timer event from the event queue 
but it will not disable broadcast timer;
4. So after 30ms later, the broadcast timer interrupt will be triggered 
even though the timer has been cancelled by s/w in step 3.


With current timer framework, is upper behaviour expected? Or maybe we 
miss something so that introduce such kind issue?


And i'm interesting now if have some idea to optimize such issue, very 
appreciate for suggestion and comment.


Thanks,
Leo Yan
--
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: PANIC: ata_qc_new_init crashes at boot

[Dan Williams]

On Mon, Aug 18, 2014 at 2:21 PM, Tejun Heo  wrote:
> Hello,
>
> Sorry about the delay.  Cc'ing Dan.
>
> On Wed, Aug 06, 2014 at 02:02:47PM -0400, Nick Krause wrote:
>> On Wed, Jul 23, 2014 at 4:39 AM, Peter Zijlstra  wrote:
>> > On Tue, Jul 22, 2014 at 03:48:02PM -0400, Peter Hurley wrote:
>> >> [ +cc Tejun ]
>> >>
>> >> On 07/22/2014 03:26 PM, Jesse Brandeburg wrote:
>> >> > This is a repeatable panic, happens every boot (and prevents starting 
>> >> > my system)
>> >> >
>> >> > [8.732993] sd 6:0:1:0: [sdb] Attached SCSI disk
>> >> > [8.733857]  sda: sda1 sda2 sda3
>> >> > [8.734318] sd 6:0:0:0: [sda] Attached SCSI disk
>> >> > [8.737943] BUG: unable to handle kernel NULL pointer dereference at 
>> >> > 0058
>> >> > [8.737947] IP: [] ata_qc_new_init+0x188/0x1b0
>> >
>> > I too have this problem on one of my machines. Let me know if there's
>> > anything you need.
>
> Are you still seeing this on every boot?  ISTR this getting fixed but
> I could be confused.  Dan, the original thread is
>
>   
> http://lkml.kernel.org/g/CAEuXFEy5=0xkqpiwqnigbpi5ehszq5f_u7sj0t2bho_1lqe...@mail.gmail.com
>

This is the last I heard:

http://marc.info/?l=linux-ide=140630768020241=2

But I never saw a follow up.

Hmmm, commit 1a112d10f03e libata: introduce ata_host->n_tags to avoid
oops on SAS controllers

...doesn't fix this?  Jesse reported positive results here:

http://marc.info/?l=linux-ide=140624094731542=2
--
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] doc: dt/bindings: input: introduce palmas power button description

[Dmitry Torokhov]

On Mon, Aug 18, 2014 at 03:13:29PM -0500, Nishanth Menon wrote:
> Many palmas family of PMICs have support for interrupt based power
> button. This allows the device to notify the processor of external
> push button events over the shared palmas interrupt.
> 
> Document the hardware support for the same.
> 
> Signed-off-by: Nishanth Menon 
> ---
>  .../bindings/input/ti,palmas-pwrbutton.txt |   32 
> 
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt 
> b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
> new file mode 100644
> index 000..6a89bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments Palmas family power button module
> +
> +This module is part of the Palmas family of PMICs. For more details
> +about the whole chip see:
> +Documentation/devicetree/bindings/mfd/palmas.txt.
> +
> +This module provides a simple power button event via an Interrupt.
> +
> +Required properties:
> +- compatible: should be one of the following
> +   - "ti,palmas-pwrbutton": For Palmas compatible power on button
> +- interrupt-parent: Parent interrupt device, must be handle of palmas node.
> +- interrupts: Interrupt number of power button submodule on device.
> +
> +Optional Properties:
> +
> +- ti,palmas-long-press-seconds: Duration in seconds which the power
> +  button should be kept pressed for Palmas to power off automatically.
> +  NOTE: This depends on OTP support and POWERHOLD signal configuration
> +  on platform.

Only a few values are valid for this property, I think you should mention that.

> +
> +Example:
> +
> + {
> + palmas_pwr_button: pwrbutton {
> + compatible = "ti,palmas-pwrbutton";
> + interrupt-parent = <>;
> + interrupts = <1 IRQ_TYPE_NONE>;

Why none? Can we specify appropriate trigger here instead of hard-coding in the
driver?

> + wakeup-source;

What handles this attribute? I do not see it handled in the driver.

> + ti,palmas-long-press-seconds = <12>;
> + };
> +};
> -- 
> 1.7.9.5
> 

Thanks.

-- 
Dmitry
--
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] Input: misc: introduce palmas-pwrbutton

[Dmitry Torokhov]

Hi NIshanth,

On Mon, Aug 18, 2014 at 03:13:30PM -0500, Nishanth Menon wrote:
> Many palmas family of PMICs have support for interrupt based power
> button. This allows the device to notify the processor of external
> push button events over the shared palmas interrupt. However, this
> event is generated only during a "press" operation. Software is
> supposed to poll(sigh!) for detecting a release event.
> 
> The PMIC also supports ability to power off independent of the
> software decisions when the button is pressed for a long duration if
> the PMIC is appropriately configured on the platform.
> 
> Even though the function is similar to twl4030_pwrbutton, it is
> substantially different in operation to belong to a new driver of it's
> own.
> 
> Based on original work done by Girish S Ghongdemath 
> 
> Signed-off-by: Nishanth Menon 
> ---
>  drivers/input/misc/Kconfig|   10 ++
>  drivers/input/misc/Makefile   |1 +
>  drivers/input/misc/palmas-pwrbutton.c |  314 
> +
>  3 files changed, 325 insertions(+)
>  create mode 100644 drivers/input/misc/palmas-pwrbutton.c
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 2ff4425..0224dcf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -451,6 +451,16 @@ config HP_SDC_RTC
> Say Y here if you want to support the built-in real time clock
> of the HP SDC controller.
>  
> +config INPUT_PALMAS_PWRBUTTON
> + tristate "Palmas Power button Driver"
> + depends on MFD_PALMAS
> + help
> +   Say Y here if you want to enable power key reporting via the
> +   Palmas family of PMICs.
> +
> +   To compile this driver as a module, choose M here. The module will
> +   be called palmas_pwrbutton.
> +
>  config INPUT_PCF50633_PMU
>   tristate "PCF50633 PMU events"
>   depends on MFD_PCF50633
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 4955ad3..e3d5efb 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_INPUT_MAX8997_HAPTIC)  += max8997_haptic.o
>  obj-$(CONFIG_INPUT_MC13783_PWRBUTTON)+= mc13783-pwrbutton.o
>  obj-$(CONFIG_INPUT_MMA8450)  += mma8450.o
>  obj-$(CONFIG_INPUT_MPU3050)  += mpu3050.o
> +obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON) += palmas-pwrbutton.o
>  obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
>  obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o
>  obj-$(CONFIG_INPUT_PCF8574)  += pcf8574_keypad.o
> diff --git a/drivers/input/misc/palmas-pwrbutton.c 
> b/drivers/input/misc/palmas-pwrbutton.c
> new file mode 100644
> index 000..35f3d68
> --- /dev/null
> +++ b/drivers/input/misc/palmas-pwrbutton.c
> @@ -0,0 +1,314 @@
> +/*
> + * Texas Instruments' Palmas Power Button Input Driver
> + *
> + * Copyright (C) 2012-2014 Texas Instruments Incorporated - 
> http://www.ti.com/
> + *   Girish S Ghongdemath
> + *   Nishanth Menon
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PALMAS_LPK_TIME_MASK 0x0c
> +#define PALMAS_PWR_KEY_PRESS 0x01
> +#define PALMAS_PWR_KEY_Q_TIME_MS 20
> +
> +/**
> + * struct palmas_pwron - Palmas power on data
> + * @palmas:  pointer to palmas device
> + * @input_dev:   pointer to input device
> + * @irq: irq that we are hooked on to
> + * @input_work:  work for detecting release of key
> + * @current_state:   key current state
> + * @key_recheck_ms:  duration for recheck of key (in milli-seconds)
> + */
> +struct palmas_pwron {
> + struct palmas *palmas;
> + struct input_dev *input_dev;
> + int irq;
> + struct delayed_work input_work;
> + int current_state;
> + u32 key_recheck_ms;
> +};
> +
> +/**
> + * struct palmas_pwron_config - configuration of palmas power on
> + * @long_press_time_val: value for long press h/w shutdown event
> + */
> +struct palmas_pwron_config {
> + u8 long_press_time_val;
> +};
> +
> +/**
> + * palmas_get_pwr_state() - read button state
> + * @pwron: pointer to pwron struct
> + */
> +static int palmas_get_pwr_state(struct palmas_pwron *pwron)
> +{
> + struct input_dev *input_dev = pwron->input_dev;
> + struct device *dev = input_dev->dev.parent;
> + unsigned int reg = 0;
> + int ret;
> +
> + ret = palmas_read(pwron->palmas, 

Re: [PATCH] regmap: fix of_regmap_get_endian()

[Thierry Reding]

On Mon, Aug 18, 2014 at 04:14:04PM -0600, Stephen Warren wrote:
> From: Stephen Warren 
> 
> Commit d647c199510c ("regmap: add DT endianness binding support") has
> some issues. Specifically, if config->reg_format_endian is not explicitly
> set, it will be zero, i.e. REGMAP_ENDIAN_DEFAULT. The switch statement
> that looks up the *endian from DT for the type==REGMAP_ENDIAN_VAL case
> doesn't change *endian in the type==REGMAP_ENDIAN_REG case. However, the
> test immediately following, compares *endian against REGMAP_ENDIAN_NATIVE,
> and if not equal, returns *endian as is. This ends up returning
> REGMAP_ENDIAN_DEFAULT, which the calling code does not expect, eventually
> leading to e.g.:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 0024
> ...
> [] (regcache_cache_only) from [] 
> (tegra30_ahub_probe+0x1b8/0x430)
> [] (tegra30_ahub_probe) from [] 
> (platform_drv_probe+0x2c/0x5c)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x10c/0x22c)
> [] (driver_probe_device) from [] 
> (__driver_attach+0x8c/0x90)
> 
> This patch solves this by:
> * When looking up the endianness from DT, don't change *endian at all if
>   there is no DT property; leave it set to REGMAP_ENDIAN_DEFAULT so the
>   code falls through to other data sources in the same way as before.
>   Now, the "unspecified" case acts the same for both REGMAP_ENDIAN_REG and
>   REGMAP_ENDIAN_VAL.
> * After potentially looking up the endianness from DT, check *endian
>   against REGMAP_ENDIAN_DEFAULT instead of REGMAP_ENDIAN_NATIVE to avoid
>   returning unexpected values.
> 
> Also, clean up the code a bit:
> 
> * Make the comments briefer, and only refer to the specific action taken
>   at their location. This makes most of the comments independent of DT,
>   and easier to follow.
> * Restore the overall default of REGMAP_ENDIAN_BIG if none of the config,
>   DT, or the bus specify any endianness. Since all busses specify an
>   endianness now, this makes no difference, but I saw no justification in
>   the patch description for changing the default default.
> * s/of_regmap_get_endian/regmap_get_endian/ since the function isn't DT-
>   specific, even if the reason it was originally added was to add some
>   DT-specific features.
> 
> Reported-by: Thierry Reding 
> Fixes: d647c199510c ("regmap: add DT endianness binding support")
> Cc: Xiubo Li 
> Signed-off-by: Stephen Warren 
> ---
>  drivers/base/regmap/regmap.c | 58 
> ++--
>  1 file changed, 18 insertions(+), 40 deletions(-)

Thanks for fixing this, Stephen.

Tested-by: Thierry Reding 


pgp2QcQpV9mbJ.pgp
Description: PGP signature

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 01:00 PM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
>  wrote:
>> On 08/19/2014 12:31 PM, David Matlack wrote:
>>> But it looks like you basically said the same thing earlier, so I think
>>> we're on the same page.
>>>
>>
>> Yes, that is what i try to explain in previous mails. :(
> 
> I'm glad we understand each other now! Sorry again for my confusion.

Yup, me too. :)

> 
>>> The single line patch I suggested was only intended to fix the "forever
>>> incorrectly exit mmio".
>>
>> My patch also fixes this case and that does not doubly increase the
>> number. I think this is the better one.
> 
> I prefer doubly increasing the generation for this reason: the updated boolean
> requires extra code on the "client-side" to check if there's an update in
> progress. And that makes it easy to get wrong. In fact, your patch
> forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
> generation requires no "client-side" code to work.

No, the updated patch is used to fix case 2 which i draw the scenario in
the last mail. I mean the original patch in this patchset which just
increase the number after srcu-sync.

Then could you tell me that your approach can do but my original patch can not?

--
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/4] net: allow large number of rx queues

[Pankaj Gupta]

> Hello.
> 
> On 08/18/2014 05:37 PM, Pankaj Gupta wrote:
> 
> > netif_alloc_rx_queues() uses kcalloc() to allocate memory
> > for "struct netdev_queue *_rx" array.
> > If we are doing large rx queue allocation kcalloc() might
> > fail, so this patch does a fallback to vzalloc().
> > Similar implementation is done for tx queue allocation in
> > netif_alloc_netdev_queues().
> 
> > We avoid failure of high order memory allocation
> > with the help of vzalloc(), this allows us to do large
> > rx and tx queue allocation which in turn helps us to
> > increase the number of queues in tun.
> 
> > As vmalloc() adds overhead on a critical network path,
> > __GFP_REPEAT flag is used with kzalloc() to do this fallback
> > only when really needed.
> 
> > Signed-off-by: Pankaj Gupta 
> > Reviewed-by: Michael S. Tsirkin 
> > Reviewed-by: David Gibson 
> > ---
> >   net/core/dev.c | 20 +---
> >   1 file changed, 13 insertions(+), 7 deletions(-)
> 
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 1c15b18..a455a02 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -5942,17 +5942,24 @@ void netif_stacked_transfer_operstate(const struct
> > net_device *rootdev,
> >   EXPORT_SYMBOL(netif_stacked_transfer_operstate);
> >
> >   #ifdef CONFIG_SYSFS
> > +static void netif_free_rx_queues(struct net_device *dev)
> > +{
> > +   kvfree(dev->_rx);
> > +}
> > +
> >   static int netif_alloc_rx_queues(struct net_device *dev)
> >   {
> > unsigned int i, count = dev->num_rx_queues;
> > struct netdev_rx_queue *rx;
> > -
> > +   size_t sz = count * sizeof(*rx);
> 
>Please keep an empty line after declarations.
 Yes, I will add it. Thanks
> 
> > BUG_ON(count < 1);
> >
> 
> WBR, Sergei
> 
> 
--
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] mmc: dw_mmc: move rockchip related code to a separate file

[Jaehoon Chung]

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

On 08/19/2014 01:36 PM, Addy Ke wrote:
> To support HS200 and UHS-1, we need add a big hunk of code,
> as shown in the following patches. So a separate file for
> rockchip SOCs is suitable.
> 
> Signed-off-by: Addy Ke 
> ---
> Changes in v2:
> - Kconfig: depend on ARCH_ROCKCHIP, suggested by Bartlomiej Zolnierkiewicz
> - Kconfig: depend on OF, suggested by Doug Anderson
> - Not change suspend/resume code, suggested by Doug Anderson
> - If pdev->dev.of_node is NULL, then return -ENODEV, suggested by Heiko 
> Stübner
> 
>  drivers/mmc/host/Kconfig   |   9 +++
>  drivers/mmc/host/Makefile  |   1 +
>  drivers/mmc/host/dw_mmc-pltfm.c|  57 
>  drivers/mmc/host/dw_mmc-rockchip.c | 136 
> +
>  4 files changed, 146 insertions(+), 57 deletions(-)
>  create mode 100644 drivers/mmc/host/dw_mmc-rockchip.c
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index a565254..f6095f6 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -621,6 +621,15 @@ config MMC_DW_PCI
>  
> If unsure, say N.
>  
> +config MMC_DW_ROCKCHIP
> + tristate "Rockchip specific extensions for Synopsys DW Memory Card 
> Interface"
> + depends on MMC_DW && ARCH_ROCKCHIP && OF
> + select MMC_DW_PLTFM
> + help
> +   This selects support for Rockchip SoC specific extensions to the
> +   Synopsys DesignWare Memory Card Interface driver. Select this option
> +   for platforms based on RK3066, RK3188 and RK3288 SoC's.
> +
>  config MMC_SH_MMCIF
>   tristate "SuperH Internal MMCIF support"
>   depends on MMC_BLOCK
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 7f81ddf..5fce465 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_MMC_DW_PLTFM)  += dw_mmc-pltfm.o
>  obj-$(CONFIG_MMC_DW_EXYNOS)  += dw_mmc-exynos.o
>  obj-$(CONFIG_MMC_DW_K3)  += dw_mmc-k3.o
>  obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
> +obj-$(CONFIG_MMC_DW_ROCKCHIP)+= dw_mmc-rockchip.o
>  obj-$(CONFIG_MMC_SH_MMCIF)   += sh_mmcif.o
>  obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
>  obj-$(CONFIG_MMC_VUB300) += vub300.o
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index b547f7a..0c56c41 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -26,64 +26,11 @@
>  #include "dw_mmc.h"
>  #include "dw_mmc-pltfm.h"
>  
> -#define RK3288_CLKGEN_DIV2
> -
>  static void dw_mci_pltfm_prepare_command(struct dw_mci *host, u32 *cmdr)
>  {
>   *cmdr |= SDMMC_CMD_USE_HOLD_REG;
>  }
>  
> -static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
> -{
> - host->bus_hz /= RK3288_CLKGEN_DIV;
> -
> - return 0;
> -}
> -
> -static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
> -{
> - int ret;
> - unsigned int cclkin;
> - u32 bus_hz;
> -
> - /*
> -  * cclkin: source clock of mmc controller.
> -  * bus_hz: card interface clock generated by CLKGEN.
> -  * bus_hz = cclkin / RK3288_CLKGEN_DIV;
> -  * ios->clock = (div == 0) ? bus_hz : (bus_hz / (2 * div))
> -  *
> -  * Note: div can only be 0 or 1
> -  *   if DDR50 8bit mode(only emmc work in 8bit mode),
> -  *   div must be set 1
> -  */
> - if ((ios->bus_width == MMC_BUS_WIDTH_8) &&
> - (ios->timing == MMC_TIMING_MMC_DDR52))
> - cclkin = 2 * ios->clock * RK3288_CLKGEN_DIV;
> - else
> - cclkin = ios->clock * RK3288_CLKGEN_DIV;
> -
> - ret = clk_set_rate(host->ciu_clk, cclkin);
> - if (ret)
> - dev_warn(host->dev, "failed to set rate %uHz\n", ios->clock);
> -
> - bus_hz = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
> - if (bus_hz != host->bus_hz) {
> - host->bus_hz = bus_hz;
> - /* force dw_mci_setup_bus() */
> - host->current_speed = 0;
> - }
> -}
> -
> -static const struct dw_mci_drv_data rk2928_drv_data = {
> - .prepare_command= dw_mci_pltfm_prepare_command,
> -};
> -
> -static const struct dw_mci_drv_data rk3288_drv_data = {
> - .prepare_command= dw_mci_pltfm_prepare_command,
> - .set_ios= dw_mci_rk3288_set_ios,
> - .setup_clock= dw_mci_rk3288_setup_clock,
> -};
> -
>  static const struct dw_mci_drv_data socfpga_drv_data = {
>   .prepare_command= dw_mci_pltfm_prepare_command,
>  };
> @@ -144,10 +91,6 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
>  
>  static const struct of_device_id dw_mci_pltfm_match[] = {
>   { .compatible = "snps,dw-mshc", },
> - { .compatible = "rockchip,rk2928-dw-mshc",
> - .data = _drv_data },
> - { .compatible = "rockchip,rk3288-dw-mshc",
> - .data = _drv_data },
>   { .compatible = "altr,socfpga-dw-mshc",
>   .data = _drv_data },
>   

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[David Matlack]

On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
 wrote:
> On 08/19/2014 12:31 PM, David Matlack wrote:
>> But it looks like you basically said the same thing earlier, so I think
>> we're on the same page.
>>
>
> Yes, that is what i try to explain in previous mails. :(

I'm glad we understand each other now! Sorry again for my confusion.

>> The single line patch I suggested was only intended to fix the "forever
>> incorrectly exit mmio".
>
> My patch also fixes this case and that does not doubly increase the
> number. I think this is the better one.

I prefer doubly increasing the generation for this reason: the updated boolean
requires extra code on the "client-side" to check if there's an update in
progress. And that makes it easy to get wrong. In fact, your patch
forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
generation requires no "client-side" code to work.
--
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/

[mm] f7b5d647946: -3.0% dbench.throughput-MB/sec

[Fengguang Wu]

Hi Mel,

We noticed a minor dbench throughput regression on commit
f7b5d647946aae1647bf5cd26c16b3a793c1ac49 ("mm: page_alloc: abort fair
zone allocation policy when remotes nodes are encountered").

testcase: ivb44/dbench/100%

bb0b6dffa2ccfbd  f7b5d647946aae1647bf5cd26
---  -
 25692 ± 0%  -3.0%  24913 ± 0%  dbench.throughput-MB/sec
   6974259 ± 6% -12.1%6127616 ± 0%  meminfo.DirectMap2M
 18.43 ± 0%  -4.6%  17.59 ± 0%  turbostat.RAM_W
  9302 ± 0%  -3.6%   8965 ± 1%  time.user_time
   1425791 ± 1%  -2.0%1396598 ± 0%  time.involuntary_context_switches

Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.

Thanks,
Fengguang
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu11/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu12/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu14/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu16/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu17/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu18/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu19/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu20/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu21/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu22/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu23/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu24/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu25/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu26/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu27/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu28/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu29/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu30/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu31/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu32/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu33/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu34/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu35/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu36/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu37/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu38/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu39/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu40/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu41/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu42/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu43/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu44/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu45/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu46/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu47/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu8/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu9/cpufreq/scaling_governor
dbench 48 -c /usr/share/dbench/client.txt

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 12:31 PM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 8:50 PM, Xiao Guangrong
>  wrote:
>> On 08/19/2014 05:15 AM, David Matlack wrote:
>>> On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
>>>  wrote:
 @@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 
 *sptep, gfn_t gfn,

  static bool check_mmio_spte(struct kvm *kvm, u64 spte)
  {
 +   struct kvm_memslots *slots = kvm_memslots(kvm);
 unsigned int kvm_gen, spte_gen;

 -   kvm_gen = kvm_current_mmio_generation(kvm);
 +   if (slots->updated)
 +   return false;
 +
 +   smp_rmb();
 +
 +   kvm_gen = __kvm_current_mmio_generation(slots);
 spte_gen = get_mmio_spte_generation(spte);

>>>
>>> What does this fix? Case 2 can still happen. (Case 2 is unavoidable unless 
>>> we
>>> block during memslot updates, which I don't think we should :).
>>
>> This exactly fixes case 2, slots->updated just acts as the "low bit"
>> but avoid generation number wrap-around and trick handling of the number.
>> More details please see below.
>>
>>>
 trace_check_mmio_spte(spte, kvm_gen, spte_gen);
 diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
 index 4b6c01b..1d4e78f 100644
 --- a/virt/kvm/kvm_main.c
 +++ b/virt/kvm/kvm_main.c
 @@ -96,7 +96,7 @@ static void hardware_disable_all(void);

  static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
  static void update_memslots(struct kvm_memslots *slots,
 -   struct kvm_memory_slot *new, u64 
 last_generation);
 +   struct kvm_memory_slot *new);

  static void kvm_release_pfn_dirty(pfn_t pfn);
  static void mark_page_dirty_in_slot(struct kvm *kvm,
 @@ -685,8 +685,7 @@ static void sort_memslots(struct kvm_memslots *slots)
  }

  static void update_memslots(struct kvm_memslots *slots,
 -   struct kvm_memory_slot *new,
 -   u64 last_generation)
 +   struct kvm_memory_slot *new)
  {
 if (new) {
 int id = new->id;
 @@ -697,8 +696,6 @@ static void update_memslots(struct kvm_memslots *slots,
 if (new->npages != npages)
 sort_memslots(slots);
 }
 -
 -   slots->generation = last_generation + 1;
  }

  static int check_memory_region_flags(struct kvm_userspace_memory_region 
 *mem)
 @@ -720,10 +717,17 @@ static struct kvm_memslots 
 *install_new_memslots(struct kvm *kvm,
  {
 struct kvm_memslots *old_memslots = kvm->memslots;

 -   update_memslots(slots, new, kvm->memslots->generation);
 +   /* ensure generation number is always increased. */
 +   slots->updated = true;
 +   slots->generation = old_memslots->generation;
 +   update_memslots(slots, new);
 rcu_assign_pointer(kvm->memslots, slots);
 synchronize_srcu_expedited(>srcu);

 +   slots->generation++;
 +   smp_wmb();
 +   slots->updated = false;
 +
 kvm_arch_memslots_updated(kvm);

 return old_memslots;

>>>
>>> This is effectively the same as the first approach.
>>>
>>> I just realized how simple Paolo's idea is. I think it can be a one line
>>> patch (without comments):
>>>
>>> [...]
>>> update_memslots(slots, new, kvm->memslots->generation);
>>> rcu_assign_pointer(kvm->memslots, slots);
>>> synchronize_srcu_expedited(>srcu);
>>> +   slots->generation++;
>>>
>>> kvm_arch_memslots_updated(kvm);
>>> [...]
>>
>> Really? Unfortunately no. :)
>>
>> See this scenario:
>>
>> CPU 0  CPU 1
>> ioctl registering a new memslot which
>> contains GPA:
>>page-fault handler:
>>  see it'a mmio access on GPA;
>>
>>  assign the new memslots with generation number increased
>>  cache the generation-number into spte;
>>  fix the access and comeback to guest;
>> SRCU-sync
>>  page-fault again and check the spte is a valid 
>> mmio-spte(*)
>> generation-number++;
>> return to userspace;
>>  do mmio-emulation and inject mmio-exit;
>>
>> !!! userspace receives a unexpected mmio-exit, that is case 2 i exactly
>> said in the last mail.
>>
>>
>> Note in the step *, my approach detects the invalid generation-number which
>> will invalidate the mmio spte properly .
> 
> Sorry I didn't explain myself very well: Since we can get a single wrong
> mmio exit no matter what, it has to be handled in userspace. So my point
> was, it doesn't really help to fix that one very specific way that it can
> happen, because it can just happen in other ways. 

[GIT PULL] PCI changes for v3.17 (part 3)

[Bjorn Helgaas]

Hi Linus,

I screwed up.  I intended these changes for v3.17, and I put them in my
'next' branch just before leaving on vacation, but I forgot to include them
in my merge window pull request when I returned.  They're low-risk, so I'm
sending them to you now (late), but the world won't end if they wait until
v3.18.

The main reason to include them would be to support the TI DRA7xx.

Bjorn


The following changes since commit 792688fde431b4fdb2cf10a6f7589a8176b6b14a:

  Merge branches 'pci/host-generic', 'pci/host-mvebu', 'pci/host-rcar', 
'pci/host-tegra', 'pci/msi', 'pci/misc', 'pci/resource' and 
'pci/virtualization' into next (2014-07-16 17:09:47 -0600)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v3.17-changes-3

for you to fetch changes up to 981c191778a4f92bc82456205a444d522843a630:

  Merge branches 'pci/host-designware', 'pci/host-mvebu' and 'pci/host-tegra' 
into next (2014-07-22 17:55:50 -0600)


PCI changes for v3.17 (part 3):

  Marvell MVEBU
- Remove ARCH_KIRKWOOD dependency (Andrew Lunn)

  NVIDIA Tegra
- Add debugfs support (Thierry Reding)

  Synopsys DesignWare
- Look for configuration space in 'reg', not 'ranges' (Kishon Vijay Abraham 
I)
- Program ATU with untranslated address (Kishon Vijay Abraham I)
- Add config access-related pcie_host_ops for v3.65 hardware (Murali 
Karicheri)
- Add MSI-related pcie_host_ops for v3.65 hardware (Murali Karicheri)

  TI DRA7xx
- Add TI DR7xx PCIe driver (Kishon Vijay Abraham I)


Andrew Lunn (1):
  PCI: mvebu: Remove ARCH_KIRKWOOD dependency

Bjorn Helgaas (1):
  Merge branches 'pci/host-designware', 'pci/host-mvebu' and 
'pci/host-tegra' into next

Kishon Vijay Abraham I (3):
  PCI: designware: Look for configuration space in 'reg', not 'ranges'
  PCI: designware: Program ATU with untranslated address
  PCI: dra7xx: Add TI DRA7xx PCIe driver

Murali Karicheri (2):
  PCI: designware: Add config access-related pcie_host_ops for v3.65 
hardware
  PCI: designware: Add MSI-related pcie_host_ops for v3.65 hardware

Thierry Reding (1):
  PCI: tegra: Add debugfs support

 .../devicetree/bindings/pci/designware-pcie.txt|   4 +
 Documentation/devicetree/bindings/pci/ti-pci.txt   |  59 +++
 MAINTAINERS|   8 +
 drivers/pci/host/Kconfig   |  11 +-
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pci-dra7xx.c  | 458 +
 drivers/pci/host/pci-tegra.c   | 118 ++
 drivers/pci/host/pcie-designware.c | 134 --
 drivers/pci/host/pcie-designware.h |  11 +
 9 files changed, 771 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
 create mode 100644 drivers/pci/host/pci-dra7xx.c
--
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] mmc: dw_mmc: move rockchip related code to a separate file

[Addy Ke]

To support HS200 and UHS-1, we need add a big hunk of code,
as shown in the following patches. So a separate file for
rockchip SOCs is suitable.

Signed-off-by: Addy Ke 
---
Changes in v2:
- Kconfig: depend on ARCH_ROCKCHIP, suggested by Bartlomiej Zolnierkiewicz
- Kconfig: depend on OF, suggested by Doug Anderson
- Not change suspend/resume code, suggested by Doug Anderson
- If pdev->dev.of_node is NULL, then return -ENODEV, suggested by Heiko Stübner

 drivers/mmc/host/Kconfig   |   9 +++
 drivers/mmc/host/Makefile  |   1 +
 drivers/mmc/host/dw_mmc-pltfm.c|  57 
 drivers/mmc/host/dw_mmc-rockchip.c | 136 +
 4 files changed, 146 insertions(+), 57 deletions(-)
 create mode 100644 drivers/mmc/host/dw_mmc-rockchip.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index a565254..f6095f6 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -621,6 +621,15 @@ config MMC_DW_PCI
 
  If unsure, say N.
 
+config MMC_DW_ROCKCHIP
+   tristate "Rockchip specific extensions for Synopsys DW Memory Card 
Interface"
+   depends on MMC_DW && ARCH_ROCKCHIP && OF
+   select MMC_DW_PLTFM
+   help
+ This selects support for Rockchip SoC specific extensions to the
+ Synopsys DesignWare Memory Card Interface driver. Select this option
+ for platforms based on RK3066, RK3188 and RK3288 SoC's.
+
 config MMC_SH_MMCIF
tristate "SuperH Internal MMCIF support"
depends on MMC_BLOCK
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 7f81ddf..5fce465 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MMC_DW_PLTFM)+= dw_mmc-pltfm.o
 obj-$(CONFIG_MMC_DW_EXYNOS)+= dw_mmc-exynos.o
 obj-$(CONFIG_MMC_DW_K3)+= dw_mmc-k3.o
 obj-$(CONFIG_MMC_DW_PCI)   += dw_mmc-pci.o
+obj-$(CONFIG_MMC_DW_ROCKCHIP)  += dw_mmc-rockchip.o
 obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
 obj-$(CONFIG_MMC_JZ4740)   += jz4740_mmc.o
 obj-$(CONFIG_MMC_VUB300)   += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index b547f7a..0c56c41 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -26,64 +26,11 @@
 #include "dw_mmc.h"
 #include "dw_mmc-pltfm.h"
 
-#define RK3288_CLKGEN_DIV  2
-
 static void dw_mci_pltfm_prepare_command(struct dw_mci *host, u32 *cmdr)
 {
*cmdr |= SDMMC_CMD_USE_HOLD_REG;
 }
 
-static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
-{
-   host->bus_hz /= RK3288_CLKGEN_DIV;
-
-   return 0;
-}
-
-static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
-{
-   int ret;
-   unsigned int cclkin;
-   u32 bus_hz;
-
-   /*
-* cclkin: source clock of mmc controller.
-* bus_hz: card interface clock generated by CLKGEN.
-* bus_hz = cclkin / RK3288_CLKGEN_DIV;
-* ios->clock = (div == 0) ? bus_hz : (bus_hz / (2 * div))
-*
-* Note: div can only be 0 or 1
-*   if DDR50 8bit mode(only emmc work in 8bit mode),
-*   div must be set 1
-*/
-   if ((ios->bus_width == MMC_BUS_WIDTH_8) &&
-   (ios->timing == MMC_TIMING_MMC_DDR52))
-   cclkin = 2 * ios->clock * RK3288_CLKGEN_DIV;
-   else
-   cclkin = ios->clock * RK3288_CLKGEN_DIV;
-
-   ret = clk_set_rate(host->ciu_clk, cclkin);
-   if (ret)
-   dev_warn(host->dev, "failed to set rate %uHz\n", ios->clock);
-
-   bus_hz = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
-   if (bus_hz != host->bus_hz) {
-   host->bus_hz = bus_hz;
-   /* force dw_mci_setup_bus() */
-   host->current_speed = 0;
-   }
-}
-
-static const struct dw_mci_drv_data rk2928_drv_data = {
-   .prepare_command= dw_mci_pltfm_prepare_command,
-};
-
-static const struct dw_mci_drv_data rk3288_drv_data = {
-   .prepare_command= dw_mci_pltfm_prepare_command,
-   .set_ios= dw_mci_rk3288_set_ios,
-   .setup_clock= dw_mci_rk3288_setup_clock,
-};
-
 static const struct dw_mci_drv_data socfpga_drv_data = {
.prepare_command= dw_mci_pltfm_prepare_command,
 };
@@ -144,10 +91,6 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
 
 static const struct of_device_id dw_mci_pltfm_match[] = {
{ .compatible = "snps,dw-mshc", },
-   { .compatible = "rockchip,rk2928-dw-mshc",
-   .data = _drv_data },
-   { .compatible = "rockchip,rk3288-dw-mshc",
-   .data = _drv_data },
{ .compatible = "altr,socfpga-dw-mshc",
.data = _drv_data },
{},
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c 
b/drivers/mmc/host/dw_mmc-rockchip.c
new file mode 100644
index 000..f0c2cb1
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -0,0 +1,136 @@
+/*
+ * Copyright (c) 2014, Fuzhou 

Re: [PATCH v3 03/15] clk: tegra: Add closed loop support for the DFLL

[Vince Hsu]

Hi,

On 08/19/2014 11:33 AM, Tuomas Tynkkynen wrote:

From: Tuomas Tynkkynen 

With closed loop support, the clock rate of the DFLL can be adjusted.

The oscillator itself in the DFLL is a free-running oscillator whose
rate is directly determined the supply voltage. However, the DFLL
module contains logic to compare the DFLL output rate to a fixed
reference clock (51 MHz) and make a decision to either lower or raise
the DFLL supply voltage. The DFLL module can then autonomously change
the supply voltage by communicating with an off-chip PMIC via either I2C
or PWM signals. This driver currently supports only I2C.

Signed-off-by: Tuomas Tynkkynen 

---
v3: Fix incorrect order of arguments to dfll_scale_dvco_rate
---
  drivers/clk/tegra/clk-dfll.c | 656 ++-
  1 file changed, 653 insertions(+), 3 deletions(-)

...

+
+/**
+ * dfll_init_out_if - prepare DFLL-to-PMIC interface
+ * @td: DFLL instance
+ *
+ * During DFLL driver initialization or resume from context loss,
+ * disable the I2C command output to the PMIC, set safe voltage and
+ * output limits, and disable and clear limit interrupts.
+ */
+static void dfll_init_out_if(struct tegra_dfll *td)
+{
+   u32 val;
+
+   td->lut_min = 0;
+   td->lut_max = td->i2c_lut_size - 1;
+   td->lut_safe = td->lut_min + 1;
+
+   dfll_i2c_writel(td, 0, DFLL_OUTPUT_CFG);
+   val = (td->lut_safe << DFLL_OUTPUT_CFG_SAFE_SHIFT) |
+   (td->lut_max << DFLL_OUTPUT_CFG_MAX_SHIFT) |
+   (td->lut_min << DFLL_OUTPUT_CFG_MIN_SHIFT);
+   dfll_writel(td, val, DFLL_OUTPUT_CFG);
+   dfll_wmb(td);
Sorry that I forgot to mention this in v2's comment. Could you squash 
the change below in this patch? And actually it's pretty easy to misuse 
the dfll read/write/wmb functions. We might want to have some generic 
functions for these, and let the generic functions handle the offset to 
different register blocks.


commit 4a1fdd54141b4f8f9425d54cdad13c42763e6186
Author: Vince Hsu 
Date:   Thu Aug 14 18:19:20 2014 +0800

clk: tegra: use the correct write funtion for DFLL_OUTPUT_CFG

Signed-off-by: Vince Hsu 

diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index 9b3eded6b880..71e4b256ea0d 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -645,7 +645,7 @@ static void dfll_init_out_if(struct tegra_dfll *td)
val = (td->lut_safe << DFLL_OUTPUT_CFG_SAFE_SHIFT) |
(td->lut_max << DFLL_OUTPUT_CFG_MAX_SHIFT) |
(td->lut_min << DFLL_OUTPUT_CFG_MIN_SHIFT);
-   dfll_writel(td, val, DFLL_OUTPUT_CFG);
+   dfll_i2c_writel(td, val, DFLL_OUTPUT_CFG);
-dfll_wmb(td);
+dfll_i2c_wmb(td);

dfll_writel(td, 0, DFLL_OUTPUT_FORCE);
@@ -1146,7 +1146,8 @@ static int attr_registers_show(struct seq_file *s, 
void *data)

seq_puts(s, "CONTROL REGISTERS:\n");
for (offs = 0; offs <= DFLL_MONITOR_DATA; offs += 4)
seq_printf(s, "[0x%02x] = 0x%08x\n", offs,
-  dfll_readl(td, offs));
+   offs == DFLL_OUTPUT_CFG ? 
dfll_i2c_readl(td, offs) :

+   dfll_readl(td, offs));

seq_puts(s, "\nI2C and INTR REGISTERS:\n");
for (offs = DFLL_I2C_CFG; offs <= DFLL_I2C_STS; offs += 4)



Thanks,
Vince

















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

[mm] 3484b2de949: -56.2% vm-scalability.throughput, +9.3% turbostat.Pkg_W

[Fengguang Wu]

Hi Mel,

We noticed the below vm-scalability performance/power regressions on
commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone
fields into read-only, page alloc, statistics and page reclaim lines").

24b7e5819ad5cbe  3484b2de9499df23c4604a513  testbox/testcase/testparams
---  -  ---
 %stddev%change   %stddev
\  | /
  9.95 ± 2% +69.1%  16.83 ± 5%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  2.32 ± 6%+229.4%   7.63 ± 5%  
brickland3/vm-scalability/300s-lru-file-readonce
 12.27 ± 3% +99.4%  24.46 ± 5%  TOTAL vm-scalability.stddev

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  13882598 ± 0% -35.8%8915310 ± 1%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  36379953 ± 1% -64.0%   13093373 ± 0%  
brickland3/vm-scalability/300s-lru-file-readonce
  50262551 ± 0% -56.2%   22008683 ± 0%  TOTAL vm-scalability.throughput

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1138 ±46% -94.7% 60 ±23%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  1138 ±46% -94.7% 60 ±23%  TOTAL proc-vmstat.compact_success

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  0.95 ±20% -87.5%   0.12 ±12%  
brickland3/vm-scalability/300s-lru-file-readonce
  0.95 ±20% -87.5%   0.12 ±12%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get.clockevents_program_event.tick_program_event.hrtimer_interrupt

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.40 ±17% -96.1%   0.05 ±27%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  2.70 ±36% -95.0%   0.13 ± 8%  
brickland3/vm-scalability/300s-lru-file-readonce
  4.10 ±29% -95.4%   0.19 ±14%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock_irqsave.pagevec_lru_move_fn.__lru_cache_add.lru_cache_add.add_to_page_cache_lru

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.46 ±12% -89.1%   0.16 ±18%  
brickland3/vm-scalability/300s-lru-file-readonce
  1.46 ±12% -89.1%   0.16 ±18%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get.tick_sched_timer.__run_hrtimer.hrtimer_interrupt

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.18 ±23% -82.5%   0.21 ±22%  
brickland3/vm-scalability/300s-lru-file-readonce
  1.18 ±23% -82.5%   0.21 ±22%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get_update_offsets_now.hrtimer_interrupt.local_apic_timer_interrupt.smp_apic_timer_interrupt

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
   763 ±31% -84.5%118 ±11%  
brickland3/vm-scalability/300s-lru-file-mmap-read
   763 ±31% -84.5%118 ±11%  TOTAL 
proc-vmstat.kswapd_low_wmark_hit_quickly

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.59 ±12% -85.1%   0.24 ±19%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  1.59 ±12% -85.1%   0.24 ±19%  TOTAL 
perf-profile.cpu-cycles.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.__do_page_cache_readahead

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
 19972 ±45% -71.3%   5725 ±16%  
brickland3/vm-scalability/300s-lru-file-mmap-read
 19972 ±45% -71.3%   5725 ±16%  TOTAL proc-vmstat.pgmigrate_success

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
   543 ±28% -62.1%205 ±14%  
brickland3/vm-scalability/300s-lru-file-mmap-read
47 ±16%+828.5%443 ± 7%  
brickland3/vm-scalability/300s-lru-file-readonce
   590 ±27% +10.0%649 ± 9%  TOTAL 
proc-vmstat.kswapd_high_wmark_hit_quickly

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
518176 ± 5%-100.0%  0 ± 0%  
brickland3/vm-scalability/300s-lru-file-mmap-read
687557 ± 0% -53.8% 317522 ± 2%  
brickland3/vm-scalability/300s-lru-file-readonce
   1205734 ± 2% -73.7% 317522 ± 2%  TOTAL 
numa-vmstat.node1.workingset_nodereclaim

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  2.61 ± 5% -52.7%   1.24 ±25%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  1.29 ±10% -91.0%   0.12 ±15%  
brickland3/vm-scalability/300s-lru-file-readonce
  3.91 ± 7% -65.4%   1.35 ±24%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get.sched_clock_tick.scheduler_tick.update_process_times

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[David Matlack]

On Mon, Aug 18, 2014 at 8:50 PM, Xiao Guangrong
 wrote:
> On 08/19/2014 05:15 AM, David Matlack wrote:
>> On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
>>  wrote:
>>> @@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep, 
>>> gfn_t gfn,
>>>
>>>  static bool check_mmio_spte(struct kvm *kvm, u64 spte)
>>>  {
>>> +   struct kvm_memslots *slots = kvm_memslots(kvm);
>>> unsigned int kvm_gen, spte_gen;
>>>
>>> -   kvm_gen = kvm_current_mmio_generation(kvm);
>>> +   if (slots->updated)
>>> +   return false;
>>> +
>>> +   smp_rmb();
>>> +
>>> +   kvm_gen = __kvm_current_mmio_generation(slots);
>>> spte_gen = get_mmio_spte_generation(spte);
>>>
>>
>> What does this fix? Case 2 can still happen. (Case 2 is unavoidable unless we
>> block during memslot updates, which I don't think we should :).
>
> This exactly fixes case 2, slots->updated just acts as the "low bit"
> but avoid generation number wrap-around and trick handling of the number.
> More details please see below.
>
>>
>>> trace_check_mmio_spte(spte, kvm_gen, spte_gen);
>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>> index 4b6c01b..1d4e78f 100644
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -96,7 +96,7 @@ static void hardware_disable_all(void);
>>>
>>>  static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
>>>  static void update_memslots(struct kvm_memslots *slots,
>>> -   struct kvm_memory_slot *new, u64 
>>> last_generation);
>>> +   struct kvm_memory_slot *new);
>>>
>>>  static void kvm_release_pfn_dirty(pfn_t pfn);
>>>  static void mark_page_dirty_in_slot(struct kvm *kvm,
>>> @@ -685,8 +685,7 @@ static void sort_memslots(struct kvm_memslots *slots)
>>>  }
>>>
>>>  static void update_memslots(struct kvm_memslots *slots,
>>> -   struct kvm_memory_slot *new,
>>> -   u64 last_generation)
>>> +   struct kvm_memory_slot *new)
>>>  {
>>> if (new) {
>>> int id = new->id;
>>> @@ -697,8 +696,6 @@ static void update_memslots(struct kvm_memslots *slots,
>>> if (new->npages != npages)
>>> sort_memslots(slots);
>>> }
>>> -
>>> -   slots->generation = last_generation + 1;
>>>  }
>>>
>>>  static int check_memory_region_flags(struct kvm_userspace_memory_region 
>>> *mem)
>>> @@ -720,10 +717,17 @@ static struct kvm_memslots 
>>> *install_new_memslots(struct kvm *kvm,
>>>  {
>>> struct kvm_memslots *old_memslots = kvm->memslots;
>>>
>>> -   update_memslots(slots, new, kvm->memslots->generation);
>>> +   /* ensure generation number is always increased. */
>>> +   slots->updated = true;
>>> +   slots->generation = old_memslots->generation;
>>> +   update_memslots(slots, new);
>>> rcu_assign_pointer(kvm->memslots, slots);
>>> synchronize_srcu_expedited(>srcu);
>>>
>>> +   slots->generation++;
>>> +   smp_wmb();
>>> +   slots->updated = false;
>>> +
>>> kvm_arch_memslots_updated(kvm);
>>>
>>> return old_memslots;
>>>
>>
>> This is effectively the same as the first approach.
>>
>> I just realized how simple Paolo's idea is. I think it can be a one line
>> patch (without comments):
>>
>> [...]
>> update_memslots(slots, new, kvm->memslots->generation);
>> rcu_assign_pointer(kvm->memslots, slots);
>> synchronize_srcu_expedited(>srcu);
>> +   slots->generation++;
>>
>> kvm_arch_memslots_updated(kvm);
>> [...]
>
> Really? Unfortunately no. :)
>
> See this scenario:
>
> CPU 0  CPU 1
> ioctl registering a new memslot which
> contains GPA:
>page-fault handler:
>  see it'a mmio access on GPA;
>
>  assign the new memslots with generation number increased
>  cache the generation-number into spte;
>  fix the access and comeback to guest;
> SRCU-sync
>  page-fault again and check the spte is a valid 
> mmio-spte(*)
> generation-number++;
> return to userspace;
>  do mmio-emulation and inject mmio-exit;
>
> !!! userspace receives a unexpected mmio-exit, that is case 2 i exactly
> said in the last mail.
>
>
> Note in the step *, my approach detects the invalid generation-number which
> will invalidate the mmio spte properly .

Sorry I didn't explain myself very well: Since we can get a single wrong
mmio exit no matter what, it has to be handled in userspace. So my point
was, it doesn't really help to fix that one very specific way that it can
happen, because it can just happen in other ways. (E.g. update memslots
occurs after is_noslot_pfn() and before mmio exit).

But it looks like you basically said the same thing earlier, so I think
we're on the same page.

The single line 

[PATCH v3 0/17] arcmsr: change note since v13 or v2

[Ching Huang]

Change note:
1,5,7~17/17 since v1.3 are not change.
2,3,4/17 since v2 are not change.

6/17 since v2:
1. pre-define adapter_type value in private data of pci_device_id.
2. remove the arcmsr_define_adapter_type function.

Ching Huang 

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

[writeback] 952648324b9: xfstests.xfs.026.fail

[Fengguang Wu]

Hi Jan,

We find more xfstests changes on "writeback: Per-sb dirty tracking".

008 seems improved, the others are regressions.
063 failure is not 100% reproducible.

df3be46bdbab23e  952648324b969f3fc22d3a2a7  
---  -  
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.026.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.027.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.061.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.281.fail
 0   +Inf%  0 ±200%  TOTAL xfstests.xfs.063.fail
 0 ±489%-100.0%  0 ± 0%  TOTAL xfstests.xfs.008.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.056.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.059.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.060.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.266.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.282.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.283.fail

Thanks,
Fengguang
--
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/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

[Luis R. Rodriguez]

On Mon, Aug 18, 2014 at 10:19 AM, Oleg Nesterov  wrote:
> And, again, I do not really know which version is better.

In Chicago right now -- feedback was it seems the that generally
splitting up probe from init might be good in the end, if we do this
we won't need a work around for drivers that wait until our
grandmothers die on probe, but we certainly will then be penalizing
drivers who's init does take over 30 seconds. I'm waiting to see an
alternative version of the solution provided as an example on the
other thread, maybe it will fix my keyboard issue :)

 Luis
--
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 tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups

[Paul E. McKenney]

On Mon, Aug 18, 2014 at 11:23:45PM +0530, Amit Shah wrote:
> On (Fri) 15 Aug 2014 [08:04:05], Paul E. McKenney wrote:
> > On Fri, Aug 15, 2014 at 10:54:11AM +0530, Amit Shah wrote:
> > > On (Wed) 13 Aug 2014 [06:00:49], Paul E. McKenney wrote:
> > > > On Wed, Aug 13, 2014 at 11:14:39AM +0530, Amit Shah wrote:
> > > > > On (Tue) 12 Aug 2014 [14:41:51], Paul E. McKenney wrote:
> > > > > > On Tue, Aug 12, 2014 at 02:39:36PM -0700, Paul E. McKenney wrote:
> > > > > > > On Tue, Aug 12, 2014 at 09:06:21AM -0700, Paul E. McKenney wrote:
> > > > > > > > On Tue, Aug 12, 2014 at 11:03:21AM +0530, Amit Shah wrote:
> > > > > > > 
> > > > > > > [ . . . ]
> > > > > > > 
> > > > > > > > > I know of only virtio-console doing this (via userspace only,
> > > > > > > > > though).
> > > > > > > > 
> > > > > > > > As in userspace within the guest?  That would not work.  The 
> > > > > > > > userspace
> > > > > > > > that the qemu is running in might.  There is a way to extract 
> > > > > > > > ftrace info
> > > > > > > > from crash dumps, so one approach would be "sendkey 
> > > > > > > > alt-sysrq-c", then
> > > > > > > > pull the buffer from the resulting dump.  For all I know, there 
> > > > > > > > might also
> > > > > > > > be some script that uses the qemu "x" command to get at the 
> > > > > > > > ftrace buffer.
> > > > > > > > 
> > > > > > > > Again, I cannot reproduce this, and I have been through the 
> > > > > > > > code several
> > > > > > > > times over the past few days, and am not seeing it.  I could 
> > > > > > > > start
> > > > > > > > sending you random diagnostic patches, but it would be much 
> > > > > > > > better if
> > > > > > > > we could get the trace data from the failure.
> > > > > 
> > > > > I think the only recourse I now have is to dump the guest state from
> > > > > qemu, and attempt to find the ftrace buffers by poking pages and
> > > > > finding some ftrace-like struct... and then dumping the buffers.
> > > > 
> > > > The data exists in the qemu guest state, so it would be good to have
> > > > it one way or another.  My current (perhaps self-serving) guess is that
> > > > you have come up with a way to trick qemu into dropping IPIs.
> > > 
> > > I didn't get around to doing this yet; will get to it next week.
> > > 
> > > In the meantime, I tried this on RHEL6 (with RHEL6 qemu and gcc and
> > > seabios), and that exhibits the problem similarly with my .config.
> > 
> > And I am running my tests successfully on an x86_64 system running
> > Ubuntu 12.04.  Some testing on 14.04 seems to require booting with
> > acpi=off, leading to my perhaps self-serving guess above.
> 
> It looks like Ubuntu 12.04 has a choice of multiple kernels.  Which
> one are you running?

3.2.0-67-generic-pae and 3.13.0-30-generic for the host.

> Also, is there a chance you could try this on a RHEL6 box?

The odds are low over the next few days.  I am adding nastier rcutorture
testing, however.  It would still be very good to get debug information
from your setup.  One approach would be to convert the trace function
calls into printk(), if that would help.

Thanx, Paul

--
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: slub/debugobjects: lockup when freeing memory

[Paul E. McKenney]

On Mon, Aug 18, 2014 at 10:44:34PM -0500, Christoph Lameter wrote:
> On Mon, 18 Aug 2014, Paul E. McKenney wrote:
> 
> > > > So call rcu activates the object, but the object has no reference in
> > > > the debug objects code so the fixup code is called which inits the
> > > > object and allocates a reference 
> > >
> > > So we need to init the object in the page struct before the __call_rcu?
> >
> > And the needed APIs are now in mainline:
> >
> > void init_rcu_head(struct rcu_head *head);
> > void destroy_rcu_head(struct rcu_head *head);
> >
> > Over to you, Christoph!  ;-)
> 
> The field we are using for the rcu head serves other purposes before
> the free action. We cannot init the field at slab creation as we
> thought since it is used for the queueing of slabs on the partial, free
> and full lists. The kmem_cache information is not available when doing
> the freeing so we must force the allocation of reserve fields and the
> use of the reserved areas for rcu on all kmem_caches.

Yow!  I am glad I didn't try doing this myself!

> I made this conditional on CONFIG_RCU_XYZ. This needs to be the actual
> Debug options that will require allocations when initializing rcu heads.
> 
> Also note that the allocations in the rcu head initialization must be
> restricted to non RCU slabs otherwise the recursion may not terminate.
> 
> 
> Subject RFC: Allow allocations on initializing rcu fields in slub.
> 
> Signed-off-by: Christoph Lameter 
> 
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c
> +++ linux/mm/slub.c
> @@ -1308,6 +1308,41 @@ static inline struct page *alloc_slab_pa
>   return page;
>  }
> 
> +#ifdef CONFIG_RCU_DEBUG_XYZ

If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
then it will automatically show up when it needs to.

The rest looks plausible, for whatever that is worth.

Thanx, Paul

> +/*
> + * We may have to do alloations during the initialization of the
> + * debug portion of the rcu structure for a slab. It must therefore
> + * be separately allocated and initized on allocation.
> + * We cannot overload the lru field in the page struct at all.
> + */
> +#define need_reserve_slab_rcu 1
> +#else
> +/*
> + * Overload the lru field in struct page if it fits.
> + * Should struct rcu_head grow due to debugging fields etc then
> + * additional space will be allocated from the end of the slab to
> + * store the rcu_head.
> + */
> +#define need_reserve_slab_rcu
> \
> + (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
> +#endif
> +
> +static struct rcu_head *get_rcu_head(struct kmem_cache *s, struct page *page)
> +{
> + if (need_reserve_slab_rcu) {
> + int order = compound_order(page);
> + int offset = (PAGE_SIZE << order) - s->reserved;
> +
> + VM_BUG_ON(s->reserved != sizeof(struct rcu_head));
> + return page_address(page) + offset;
> + } else {
> + /*
> +  * RCU free overloads the RCU head over the LRU
> +  */
> + return (void *)>lru;
> + }
> +}
> +
>  static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int 
> node)
>  {
>   struct page *page;
> @@ -1357,6 +1392,21 @@ static struct page *allocate_slab(struct
>   kmemcheck_mark_unallocated_pages(page, pages);
>   }
> 
> +#ifdef CONFIG_RCU_DEBUG_XYZ
> + if (unlikely(s->flags & SLAB_DESTROY_BY_RCU) && page)
> + /*
> +  * Initialize rcu_head and potentially do other
> +  * allocations. Note that this is still a recursive
> +  * call into the allocator which may recurse endlessly
> +  * if the same kmem_cache is used for allocation here.
> +  *
> +  * So in order to be safe the slab caches used
> +  * in init_rcu_head must be restricted to be of the
> +  * non rcu kind only.
> +  */
> + init_rcu_head(get_rcu_head(s, page));
> +#endif
> +
>   if (flags & __GFP_WAIT)
>   local_irq_disable();
>   if (!page)
> @@ -1452,13 +1502,13 @@ static void __free_slab(struct kmem_cach
>   memcg_uncharge_slab(s, order);
>  }
> 
> -#define need_reserve_slab_rcu
> \
> - (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
> -
>  static void rcu_free_slab(struct rcu_head *h)
>  {
>   struct page *page;
> 
> +#ifdef CONFIG_RCU_DEBUG_XYZ
> + destroy_rcu_head(h);
> +#endif
>   if (need_reserve_slab_rcu)
>   page = virt_to_head_page(h);
>   else
> @@ -1469,24 +1519,9 @@ static void rcu_free_slab(struct rcu_hea
> 
>  static void free_slab(struct kmem_cache *s, struct page *page)
>  {
> - if (unlikely(s->flags & SLAB_DESTROY_BY_RCU)) {
> -   

Re: [PATCH v2 05/18] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

On 2014-8-18 22:27, Catalin Marinas wrote:
> On Mon, Aug 04, 2014 at 04:28:12PM +0100, Hanjun Guo wrote:
>> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
>> the former signals to the OS that the hardware is PSCI compliant.
> 
> Actually it signals that the firmware is PSCI compliant. The hardware
> doesn't care much.

Right, I will update it.

> 
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 6400312..6e04868 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,18 @@ extern int acpi_disabled;
>>  extern int acpi_noirq;
>>  extern int acpi_pci_disabled;
>>  
>> +/* 1 to indicate PSCI 0.2+ is implemented */
>> +static inline bool acpi_psci_present(void)
>> +{
>> +return !!(acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT);
>> +}
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +static inline bool acpi_psci_use_hvc(void)
>> +{
>> +return !!(acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC);
>> +}
> 
> Do we actually need !! here? Shouldn't the compiler figure out
> conversion to bool automatically?

I thought !! will explicitly show that it's a bool value and
improve the readability of the code, but I'm ok to remove !!
here.

> 
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 9cf9127..69a315d 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -11,6 +11,8 @@
>>   *  published by the Free Software Foundation.
>>   */
>>  
>> +#define pr_fmt(fmt) "ACPI: " fmt
>> +
>>  #include 
>>  #include 
>>  #include 
>> @@ -47,6 +49,26 @@ void __init __acpi_unmap_table(char *map, unsigned long 
>> size)
>>  early_memunmap(map, size);
>>  }
>>  
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +/*
>> + * Revision in table header is the FADT Major version,
>> + * and there is a minor version of FADT which was introduced
>> + * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> + * to get arm boot flags, or we will disable ACPI.
>> + */
>> +if (table->revision < 5 || fadt->minor_revision < 1) {
> 
> If we ever get revision 6.0, this would trigger.

Yes, good catch, actually I already fixed that in my local git repo,

+   if (table->revision > 5 ||
+   (table->revision == 5 && fadt->minor_revision >= 1)) {
+   return 0;
+   } else {
+   pr_info("FADT revision is %d.%d, no PSCI support, should be 5.1
or higher\n",
+   table->revision, fadt->minor_revision);
+   disable_acpi();
+   return -EINVAL;
+   }

> 
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 85c6326..dfc4e4f3 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -395,6 +395,8 @@ void __init setup_arch(char **cmdline_p)
>>  efi_idmap_init();
>>  
>>  cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> +acpi_boot_init();
>> +
>>  unflatten_device_tree();
> 
> Unless that's changed in a subsequent patch, do we still need to call
> unflatten_device_tree() if ACPI was successful?

No, we don't. in [PATCH v2 16/18], we will not call unflatten_device_tree()
if ACPI is successful. Since the CONFIG_ACPI is not enabled for ARM64 (will
enable it in the last patch), so acpi_boot_init() is a stub empty function
here.

> 
>>  psci_init();
> 
> I would also rename this to something like psci_dt_init() and move the
> acpi_disabled check here rather than in the callee.

thanks for the suggestion, I will update my patch :)

Thanks
Hanjun


--
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] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 05:15 AM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
>  wrote:
>> @@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep, 
>> gfn_t gfn,
>>
>>  static bool check_mmio_spte(struct kvm *kvm, u64 spte)
>>  {
>> +   struct kvm_memslots *slots = kvm_memslots(kvm);
>> unsigned int kvm_gen, spte_gen;
>>
>> -   kvm_gen = kvm_current_mmio_generation(kvm);
>> +   if (slots->updated)
>> +   return false;
>> +
>> +   smp_rmb();
>> +
>> +   kvm_gen = __kvm_current_mmio_generation(slots);
>> spte_gen = get_mmio_spte_generation(spte);
>>
> 
> What does this fix? Case 2 can still happen. (Case 2 is unavoidable unless we
> block during memslot updates, which I don't think we should :).

This exactly fixes case 2, slots->updated just acts as the "low bit"
but avoid generation number wrap-around and trick handling of the number.
More details please see below.

> 
>> trace_check_mmio_spte(spte, kvm_gen, spte_gen);
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 4b6c01b..1d4e78f 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -96,7 +96,7 @@ static void hardware_disable_all(void);
>>
>>  static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
>>  static void update_memslots(struct kvm_memslots *slots,
>> -   struct kvm_memory_slot *new, u64 
>> last_generation);
>> +   struct kvm_memory_slot *new);
>>
>>  static void kvm_release_pfn_dirty(pfn_t pfn);
>>  static void mark_page_dirty_in_slot(struct kvm *kvm,
>> @@ -685,8 +685,7 @@ static void sort_memslots(struct kvm_memslots *slots)
>>  }
>>
>>  static void update_memslots(struct kvm_memslots *slots,
>> -   struct kvm_memory_slot *new,
>> -   u64 last_generation)
>> +   struct kvm_memory_slot *new)
>>  {
>> if (new) {
>> int id = new->id;
>> @@ -697,8 +696,6 @@ static void update_memslots(struct kvm_memslots *slots,
>> if (new->npages != npages)
>> sort_memslots(slots);
>> }
>> -
>> -   slots->generation = last_generation + 1;
>>  }
>>
>>  static int check_memory_region_flags(struct kvm_userspace_memory_region 
>> *mem)
>> @@ -720,10 +717,17 @@ static struct kvm_memslots 
>> *install_new_memslots(struct kvm *kvm,
>>  {
>> struct kvm_memslots *old_memslots = kvm->memslots;
>>
>> -   update_memslots(slots, new, kvm->memslots->generation);
>> +   /* ensure generation number is always increased. */
>> +   slots->updated = true;
>> +   slots->generation = old_memslots->generation;
>> +   update_memslots(slots, new);
>> rcu_assign_pointer(kvm->memslots, slots);
>> synchronize_srcu_expedited(>srcu);
>>
>> +   slots->generation++;
>> +   smp_wmb();
>> +   slots->updated = false;
>> +
>> kvm_arch_memslots_updated(kvm);
>>
>> return old_memslots;
>>
> 
> This is effectively the same as the first approach.
> 
> I just realized how simple Paolo's idea is. I think it can be a one line
> patch (without comments):
> 
> [...]
> update_memslots(slots, new, kvm->memslots->generation);
> rcu_assign_pointer(kvm->memslots, slots);
> synchronize_srcu_expedited(>srcu);
> +   slots->generation++;
> 
> kvm_arch_memslots_updated(kvm);
> [...]

Really? Unfortunately no. :)

See this scenario:

CPU 0  CPU 1
ioctl registering a new memslot which
contains GPA:
   page-fault handler:
 see it'a mmio access on GPA;

 assign the new memslots with generation number increased
 cache the generation-number into spte;
 fix the access and comeback to guest;
SRCU-sync
 page-fault again and check the spte is a valid 
mmio-spte(*)
generation-number++;
return to userspace;
 do mmio-emulation and inject mmio-exit;

!!! userspace receives a unexpected mmio-exit, that is case 2 i exactly
said in the last mail.


Note in the step *, my approach detects the invalid generation-number which
will invalidate the mmio spte properly .

--
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 12/15] cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq

[Viresh Kumar]

On 19 August 2014 09:03, Tuomas Tynkkynen  wrote:
> From: Tuomas Tynkkynen 
>
> The Tegra124 will use a different driver for frequency scaling, so
> rename the old driver (which handles only Tegra20) appropriately.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
> v3: New patch
> ---
>  drivers/cpufreq/Kconfig.arm| 6 +++---
>  drivers/cpufreq/Makefile   | 2 +-
>  drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} | 0
>  3 files changed, 4 insertions(+), 4 deletions(-)
>  rename drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} (100%)

Acked-by: Viresh Kumar 
--
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 v3 09/15] ARM: tegra: Add the DFLL to Tegra124 device tree

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The DFLL clocksource is a separate IP block from the usual
clock-and-reset controller, so it gets its own device tree node.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/boot/dts/tegra124.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 03916ef..8ff4332 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -544,6 +544,28 @@
status = "disabled";
};
 
+   dfll: dfll@0,7011 {
+   compatible = "nvidia,tegra124-dfll";
+   reg = <0 0x7011 0 0x100>, /* DFLL control */
+ <0 0x7011 0 0x100>, /* I2C output control */
+ <0 0x70110100 0 0x100>, /* Integrated I2C controller */
+ <0 0x70110200 0 0x100>; /* Look-up table RAM */
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_DFLL_SOC>,
+<_car TEGRA124_CLK_DFLL_REF>,
+<_car TEGRA124_CLK_I2C5>;
+   clock-names = "soc", "ref", "i2c";
+   #clock-cells = <0>;
+   clock-output-names = "dfllCPU_out";
+   nvidia,sample-rate = <12500>;
+   nvidia,droop-ctrl = <0x0f00>;
+   nvidia,force-mode = <1>;
+   nvidia,cf = <10>;
+   nvidia,ci = <0>;
+   nvidia,cg = <2>;
+   status = "disabled";
+   };
+
ahub@0,7030 {
compatible = "nvidia,tegra124-ahub";
reg = <0x0 0x7030 0x0 0x200>,
-- 
1.8.1.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 v3 04/15] clk: tegra: Add functions for parsing CVB tables

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Tegra CVB tables encode the relationship between operating voltage
and optimal frequency as a function of the so-called speedo value.
The speedo value is written to the on-chip fuses at the factory,
which allows the voltage-frequency operating points to be calculated
on an per-chip basis.

Add utility functions to parse the Tegra-specific tables and export the
voltage-frequency pairs to the generic OPP framework for other drivers
to use.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/mach-tegra/Kconfig |   1 +
 drivers/clk/tegra/cvb.c | 133 
 drivers/clk/tegra/cvb.h |  67 ++
 3 files changed, 201 insertions(+)
 create mode 100644 drivers/clk/tegra/cvb.c
 create mode 100644 drivers/clk/tegra/cvb.h

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 0953996..0d5832f 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -7,6 +7,7 @@ menuconfig ARCH_TEGRA
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select PINCTRL
+   select PM_OPP
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
diff --git a/drivers/clk/tegra/cvb.c b/drivers/clk/tegra/cvb.c
new file mode 100644
index 000..69c74ee
--- /dev/null
+++ b/drivers/clk/tegra/cvb.c
@@ -0,0 +1,133 @@
+/*
+ * Utility functions for parsing Tegra CVB voltage tables
+ *
+ * Copyright (C) 2012-2014 NVIDIA Corporation.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include "cvb.h"
+
+/* cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) */
+static inline int get_cvb_voltage(int speedo, int s_scale,
+ const struct cvb_coefficients *cvb)
+{
+   int mv;
+
+   /* apply only speedo scale: output mv = cvb_mv * v_scale */
+   mv = DIV_ROUND_CLOSEST(cvb->c2 * speedo, s_scale);
+   mv = DIV_ROUND_CLOSEST((mv + cvb->c1) * speedo, s_scale) + cvb->c0;
+   return mv;
+}
+
+static int round_cvb_voltage(int mv, int v_scale,
+const struct rail_alignment *align)
+{
+   /* combined: apply voltage scale and round to cvb alignment step */
+   int uv;
+   int step = (align->step_uv ? : 1000) * v_scale;
+   int offset = align->offset_uv * v_scale;
+
+   uv = max(mv * 1000, offset) - offset;
+   uv = DIV_ROUND_UP(uv, step) * align->step_uv + align->offset_uv;
+   return uv / 1000;
+}
+
+enum {
+   DOWN,
+   UP
+};
+
+static int round_voltage(int mv, const struct rail_alignment *align, int up)
+{
+   if (align->step_uv) {
+   int uv;
+
+   uv = max(mv * 1000, align->offset_uv) - align->offset_uv;
+   uv = (uv + (up ? align->step_uv - 1 : 0)) / align->step_uv;
+   return (uv * align->step_uv + align->offset_uv) / 1000;
+   }
+   return mv;
+}
+
+static int build_opp_table(const struct cvb_table *d,
+  int speedo_value,
+  unsigned long max_freq,
+  struct device *opp_dev)
+{
+   int i, ret, dfll_mv, min_mv, max_mv;
+   const struct cvb_table_freq_entry *table = NULL;
+   const struct rail_alignment *align = >alignment;
+
+   min_mv = round_voltage(d->min_millivolts, align, UP);
+   max_mv = round_voltage(d->max_millivolts, align, DOWN);
+
+   for (i = 0; i < MAX_DVFS_FREQS; i++) {
+   table = >cvb_table[i];
+   if (!table->freq || (table->freq > max_freq))
+   break;
+
+   dfll_mv = get_cvb_voltage(
+   speedo_value, d->speedo_scale, >coefficients);
+   dfll_mv = round_cvb_voltage(dfll_mv, d->voltage_scale, align);
+   dfll_mv = clamp(dfll_mv, min_mv, max_mv);
+
+   ret = dev_pm_opp_add(opp_dev, table->freq, dfll_mv * 1000);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+/**
+ * tegra_cvb_build_opp_table - build OPP table from Tegra CVB tables
+ * @cvb_tables: array of CVB tables
+ * @sz: size of the previously mentioned array
+ * @process_id: process id of the HW module
+ * @speedo_id: speedo id of the HW module
+ * @speedo_value: speedo value of the HW module
+ * @max_rate: highest safe clock rate
+ * @opp_dev: the struct device * for which the OPP table is built
+ *
+ * On Tegra, a CVB table encodes the relationship between operating voltage
+ * and safe maximal 

[PATCH v3 01/15] clk: tegra: Add binding for the Tegra124 DFLL clocksource

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The DFLL is the main clocksource for the fast CPU cluster on Tegra124
and also provides automatic CPU rail voltage scaling as well. The DFLL
is a separate IP block from the usual Tegra124 clock-and-reset
controller, so it gets its own node in the device tree.

Signed-off-by: Tuomas Tynkkynen 
---
 .../bindings/clock/nvidia,tegra124-dfll.txt| 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt

diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt 
b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
new file mode 100644
index 000..54c62ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
@@ -0,0 +1,69 @@
+NVIDIA Tegra124 DFLL FCPU clocksource
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The DFLL IP block on Tegra is a root clocksource designed for clocking
+the fast CPU cluster. It consists of a free-running voltage controlled
+oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
+control module that will automatically adjust the VDD_CPU voltage by
+communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
+
+Required properties:
+- compatible : should be "nvidia,tegra124-dfll-fcpu"
+- reg : Defines the following set of registers, in the order listed:
+- registers for the DFLL control logic.
+- registers for the I2C output logic.
+- registers for the integrated I2C master controller.
+- look-up table RAM for voltage register values.
+- interrupts: Should contain the DFLL block interrupt.
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - soc: Clock source for the DFLL control logic.
+  - ref: The closed loop reference clock
+  - i2c: Clock source for the integrated I2C master.
+- #clock-cells: Must be 0.
+- clock-output-names: Name of the clock output.
+- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL
+  hardware will start controlling.
+
+Required properties for the control loop parameters:
+- nvidia,sample-rate: Sample rate of the DFLL control loop.
+- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM.
+- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM.
+- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM.
+- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM.
+- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM.
+- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the 
TRM.
+
+Required properties for I2C mode:
+- nvidia,i2c-fs-rate: I2C transfer rate, if using FS mode.
+
+Example:
+
+dfll@0,7011 {
+compatible = "nvidia,tegra124-dfll";
+reg = <0 0x7011 0 0x100>, /* DFLL control */
+  <0 0x7011 0 0x100>, /* I2C output control */
+  <0 0x70110100 0 0x100>, /* Integrated I2C controller */
+  <0 0x70110200 0 0x100>; /* Look-up table RAM */
+interrupts = ;
+clocks = <_car TEGRA124_CLK_DFLL_SOC>,
+ <_car TEGRA124_CLK_DFLL_REF>,
+ <_car TEGRA124_CLK_I2C5>;
+clock-names = "soc", "ref", "i2c";
+#clock-cells = <0>;
+clock-output-names = "dfllCPU_out";
+vdd-cpu-supply = <_cpu>;
+status = "okay";
+
+nvidia,sample-rate = <12500>;
+nvidia,droop-ctrl = <0x0f00>;
+nvidia,force-mode = <1>;
+nvidia,cf = <10>;
+nvidia,ci = <0>;
+nvidia,cg = <2>;
+
+nvidia,i2c-fs-rate = <40>;
+};
-- 
1.8.1.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: slub/debugobjects: lockup when freeing memory

[Christoph Lameter]

On Mon, 18 Aug 2014, Paul E. McKenney wrote:

> > > So call rcu activates the object, but the object has no reference in
> > > the debug objects code so the fixup code is called which inits the
> > > object and allocates a reference 
> >
> > So we need to init the object in the page struct before the __call_rcu?
>
> And the needed APIs are now in mainline:
>
>   void init_rcu_head(struct rcu_head *head);
>   void destroy_rcu_head(struct rcu_head *head);
>
> Over to you, Christoph!  ;-)

The field we are using for the rcu head serves other purposes before
the free action. We cannot init the field at slab creation as we
thought since it is used for the queueing of slabs on the partial, free
and full lists. The kmem_cache information is not available when doing
the freeing so we must force the allocation of reserve fields and the
use of the reserved areas for rcu on all kmem_caches.

I made this conditional on CONFIG_RCU_XYZ. This needs to be the actual
Debug options that will require allocations when initializing rcu heads.

Also note that the allocations in the rcu head initialization must be
restricted to non RCU slabs otherwise the recursion may not terminate.


Subject RFC: Allow allocations on initializing rcu fields in slub.

Signed-off-by: Christoph Lameter 

Index: linux/mm/slub.c
===
--- linux.orig/mm/slub.c
+++ linux/mm/slub.c
@@ -1308,6 +1308,41 @@ static inline struct page *alloc_slab_pa
return page;
 }

+#ifdef CONFIG_RCU_DEBUG_XYZ
+/*
+ * We may have to do alloations during the initialization of the
+ * debug portion of the rcu structure for a slab. It must therefore
+ * be separately allocated and initized on allocation.
+ * We cannot overload the lru field in the page struct at all.
+ */
+#define need_reserve_slab_rcu 1
+#else
+/*
+ * Overload the lru field in struct page if it fits.
+ * Should struct rcu_head grow due to debugging fields etc then
+ * additional space will be allocated from the end of the slab to
+ * store the rcu_head.
+ */
+#define need_reserve_slab_rcu  \
+   (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
+#endif
+
+static struct rcu_head *get_rcu_head(struct kmem_cache *s, struct page *page)
+{
+   if (need_reserve_slab_rcu) {
+   int order = compound_order(page);
+   int offset = (PAGE_SIZE << order) - s->reserved;
+
+   VM_BUG_ON(s->reserved != sizeof(struct rcu_head));
+   return page_address(page) + offset;
+   } else {
+   /*
+* RCU free overloads the RCU head over the LRU
+*/
+   return (void *)>lru;
+   }
+}
+
 static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
 {
struct page *page;
@@ -1357,6 +1392,21 @@ static struct page *allocate_slab(struct
kmemcheck_mark_unallocated_pages(page, pages);
}

+#ifdef CONFIG_RCU_DEBUG_XYZ
+   if (unlikely(s->flags & SLAB_DESTROY_BY_RCU) && page)
+   /*
+* Initialize rcu_head and potentially do other
+* allocations. Note that this is still a recursive
+* call into the allocator which may recurse endlessly
+* if the same kmem_cache is used for allocation here.
+*
+* So in order to be safe the slab caches used
+* in init_rcu_head must be restricted to be of the
+* non rcu kind only.
+*/
+   init_rcu_head(get_rcu_head(s, page));
+#endif
+
if (flags & __GFP_WAIT)
local_irq_disable();
if (!page)
@@ -1452,13 +1502,13 @@ static void __free_slab(struct kmem_cach
memcg_uncharge_slab(s, order);
 }

-#define need_reserve_slab_rcu  \
-   (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
-
 static void rcu_free_slab(struct rcu_head *h)
 {
struct page *page;

+#ifdef CONFIG_RCU_DEBUG_XYZ
+   destroy_rcu_head(h);
+#endif
if (need_reserve_slab_rcu)
page = virt_to_head_page(h);
else
@@ -1469,24 +1519,9 @@ static void rcu_free_slab(struct rcu_hea

 static void free_slab(struct kmem_cache *s, struct page *page)
 {
-   if (unlikely(s->flags & SLAB_DESTROY_BY_RCU)) {
-   struct rcu_head *head;
-
-   if (need_reserve_slab_rcu) {
-   int order = compound_order(page);
-   int offset = (PAGE_SIZE << order) - s->reserved;
-
-   VM_BUG_ON(s->reserved != sizeof(*head));
-   head = page_address(page) + offset;
-   } else {
-   /*
-* RCU free overloads the RCU head over the LRU
-*/
-   head = (void *)>lru;
-   }
-
- 

[PATCH v3 10/15] ARM: tegra: Enable the DFLL on the Jetson TK1

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add the board-specific properties of the DFLL for the Jetson TK1 board.
On this board, the DFLL will take control of the sd0 regulator on the
on-board AS3722 PMIC.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 624b0fb..0c30450 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1453,7 +1453,7 @@
vin-ldo9-10-supply = <_5v0_sys>;
vin-ldo11-supply = <_3v3_run>;
 
-   sd0 {
+   vdd_cpu: sd0 {
regulator-name = "+VDD_CPU_AP";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <140>;
@@ -1662,6 +1662,12 @@
non-removable;
};
 
+   dfll@0,7011 {
+   status = "okay";
+   vdd-cpu-supply = <_cpu>;
+   nvidia,i2c-fs-rate = <40>;
+   };
+
ahub@0,7030 {
i2s@0,70301100 {
status = "okay";
-- 
1.8.1.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 v3 06/15] clk: tegra: Add Tegra124 DFLL clocksource platform driver

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add basic platform driver support for the fast CPU cluster DFLL
clocksource found on Tegra124 SoCs. This small driver selects the
appropriate Tegra124-specific characterization data and integration
code. It relies on the DFLL common code to do most of the work.

Signed-off-by: Tuomas Tynkkynen 
---
v3: changed some accidental commas at end-of-statement to semicolons
---
 drivers/clk/tegra/Makefile |   2 +
 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 165 +
 2 files changed, 167 insertions(+)
 create mode 100644 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 47320ca..2f87188 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
 obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124.o
+obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124-dfll-fcpu.o
+obj-y  += cvb.o
diff --git a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c 
b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
new file mode 100644
index 000..13d2fae
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
@@ -0,0 +1,165 @@
+/*
+ * Tegra124 DFLL FCPU clock source driver
+ *
+ * Copyright (C) 2012-2014 NVIDIA Corporation.  All rights reserved.
+ *
+ * Aleksandr Frid 
+ * Paul Walmsley 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+#include "clk-dfll.h"
+#include "cvb.h"
+
+/* Maximum CPU frequency, indexed by CPU speedo id */
+static const unsigned long cpu_max_freq_table[] = {
+   [0] = 201450UL,
+   [1] = 232050UL,
+   [2] = 211650UL,
+   [3] = 252450UL,
+};
+
+static const struct cvb_table tegra124_cpu_cvb_tables[] = {
+   {
+   .speedo_id = -1,
+   .process_id = -1,
+   .min_millivolts = 900,
+   .max_millivolts = 1260,
+   .alignment = {
+   .step_uv = 1, /* 10mV */
+   },
+   .speedo_scale = 100,
+   .voltage_scale = 1000,
+   .cvb_table = {
+   {20400UL,   {1112619, -29295, 402} },
+   {30600UL,   {1150460, -30585, 402} },
+   {40800UL,   {1190122, -31865, 402} },
+   {51000UL,   {1231606, -33155, 402} },
+   {61200UL,   {1274912, -34435, 402} },
+   {71400UL,   {1320040, -35725, 402} },
+   {81600UL,   {1366990, -37005, 402} },
+   {91800UL,   {1415762, -38295, 402} },
+   {102000UL,  {1466355, -39575, 402} },
+   {112200UL,  {1518771, -40865, 402} },
+   {122400UL,  {1573009, -42145, 402} },
+   {132600UL,  {1629068, -43435, 402} },
+   {142800UL,  {1686950, -44715, 402} },
+   {153000UL,  {1746653, -46005, 402} },
+   {163200UL,  {1808179, -47285, 402} },
+   {173400UL,  {1871526, -48575, 402} },
+   {183600UL,  {1936696, -49855, 402} },
+   {193800UL,  {2003687, -51145, 402} },
+   {201450UL,  {2054787, -52095, 402} },
+   {211650UL,  {2124957, -53385, 402} },
+   {221850UL,  {2196950, -54665, 402} },
+   {232050UL,  {2270765, -55955, 402} },
+   {242250UL,  {2346401, -57235, 402} },
+   {252450UL,  {2437299, -58535, 402} },
+   {0, {  0,  0,   0} },
+   },
+   .cpu_dfll_data = {
+   .tune0_low = 0x005020ff,
+   .tune0_high = 0x005040ff,
+   .tune1 = 0x0060,
+   }
+   },
+};
+
+static struct tegra_dfll_soc_data soc;
+
+static int tegra124_dfll_fcpu_probe(struct platform_device *pdev)
+{
+   return tegra_dfll_register(pdev, );
+}
+
+static struct of_device_id tegra124_dfll_fcpu_of_match[] = {
+   { .compatible = "nvidia,tegra124-dfll", },
+   

[PATCH v3 03/15] clk: tegra: Add closed loop support for the DFLL

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

With closed loop support, the clock rate of the DFLL can be adjusted.

The oscillator itself in the DFLL is a free-running oscillator whose
rate is directly determined the supply voltage. However, the DFLL
module contains logic to compare the DFLL output rate to a fixed
reference clock (51 MHz) and make a decision to either lower or raise
the DFLL supply voltage. The DFLL module can then autonomously change
the supply voltage by communicating with an off-chip PMIC via either I2C
or PWM signals. This driver currently supports only I2C.

Signed-off-by: Tuomas Tynkkynen 

---
v3: Fix incorrect order of arguments to dfll_scale_dvco_rate
---
 drivers/clk/tegra/clk-dfll.c | 656 ++-
 1 file changed, 653 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index f60ef54..d11ab43f 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -205,12 +205,16 @@
  */
 #define REF_CLOCK_RATE 5100UL
 
+#define DVCO_RATE_TO_MULT(rate, ref_rate)  ((rate) / ((ref_rate) / 2))
+#define MULT_TO_DVCO_RATE(mult, ref_rate)  ((mult) * ((ref_rate) / 2))
 
 /**
  * enum dfll_ctrl_mode - DFLL hardware operating mode
  * @DFLL_UNINITIALIZED: (uninitialized state - not in hardware bitfield)
  * @DFLL_DISABLED: DFLL not generating an output clock
  * @DFLL_OPEN_LOOP: DVCO running, but DFLL not adjusting voltage
+ * @DFLL_CLOSED_LOOP: DVCO running, and DFLL adjusting voltage to match
+ *   the requested rate
  *
  * The integer corresponding to the last two states, minus one, is
  * written to the DFLL hardware to change operating modes.
@@ -219,6 +223,7 @@ enum dfll_ctrl_mode {
DFLL_UNINITIALIZED = 0,
DFLL_DISABLED = 1,
DFLL_OPEN_LOOP = 2,
+   DFLL_CLOSED_LOOP = 3,
 };
 
 /**
@@ -236,6 +241,22 @@ enum dfll_tune_range {
DFLL_TUNE_LOW = 1,
 };
 
+/**
+ * struct dfll_rate_req - target DFLL rate request data
+ * @rate: target frequency, after the postscaling
+ * @dvco_target_rate: target frequency, after the postscaling
+ * @lut_index: LUT index at which voltage the dvco_target_rate will be reached
+ * @mult_bits: value to program to the MULT bits of the DFLL_FREQ_REQ register
+ * @scale_bits: value to program to the SCALE bits of the DFLL_FREQ_REQ 
register
+ */
+struct dfll_rate_req {
+   unsigned long rate;
+   unsigned long dvco_target_rate;
+   int lut_index;
+   u8 mult_bits;
+   u8 scale_bits;
+};
+
 struct tegra_dfll {
struct device   *dev;
struct tegra_dfll_soc_data  *soc;
@@ -259,9 +280,26 @@ struct tegra_dfll {
struct dentry   *debugfs_dir;
struct clk_hw   dfll_clk_hw;
const char  *output_clock_name;
+   struct dfll_rate_reqlast_req;
 
/* Parameters from DT */
u32 droop_ctrl;
+   u32 sample_rate;
+   u32 force_mode;
+   u32 cf;
+   u32 ci;
+   u32 cg;
+   boolcg_scale;
+
+   /* I2C interface parameters */
+   u32 i2c_fs_rate;
+   u32 i2c_reg;
+   u32 i2c_slave_addr;
+
+   /* i2c_lut array entries are regulator framework selectors */
+   unsignedi2c_lut[MAX_DFLL_VOLTAGES];
+   int i2c_lut_size;
+   u8  lut_min, lut_max, lut_safe;
 };
 
 #define clk_hw_to_dfll(_hw) container_of(_hw, struct tegra_dfll, dfll_clk_hw)
@@ -271,6 +309,7 @@ static const char * const mode_name[] = {
[DFLL_UNINITIALIZED] = "uninitialized",
[DFLL_DISABLED] = "disabled",
[DFLL_OPEN_LOOP] = "open_loop",
+   [DFLL_CLOSED_LOOP] = "closed_loop",
 };
 
 /*
@@ -494,6 +533,282 @@ static void dfll_set_mode(struct tegra_dfll *td,
 }
 
 /*
+ * DFLL-to-I2C controller interface
+ */
+
+/**
+ * dfll_i2c_set_output_enabled - enable/disable I2C PMIC voltage requests
+ * @td: DFLL instance
+ * @enable: whether to enable or disable the I2C voltage requests
+ *
+ * Set the master enable control for I2C control value updates. If disabled,
+ * then I2C control messages are inhibited, regardless of the DFLL mode.
+ */
+static int dfll_i2c_set_output_enabled(struct tegra_dfll *td, bool enable)
+{
+   u32 val;
+
+   val = dfll_i2c_readl(td, DFLL_OUTPUT_CFG);
+
+   if (enable)
+   val |= DFLL_OUTPUT_CFG_I2C_ENABLE;
+   else
+   val &= ~DFLL_OUTPUT_CFG_I2C_ENABLE;
+
+   dfll_i2c_writel(td, val, DFLL_OUTPUT_CFG);
+   dfll_i2c_wmb(td);
+
+   return 0;
+}
+
+/**
+ * dfll_load_lut - load the voltage lookup table
+ * @td: struct 

[PATCH v3 00/15] Tegra124 CL-DVFS / DFLL clocksource, plus cpufreq

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

v3 changes:
- Fix incorrect order of arguments to dfll_scale_dvco_rate
- Fix accidental commas at end-of-statement to semicolons
- Some cpufreq changes:
- rename cpufreq-tegra to cpufreq-tegra20
- have separate Kconfig entries for Tegra20/Tegra124 support
- use 'select GENERIC_CPUFREQ_CPU0', not depends
- support unbinding of the platform device
- requires adding the vdd_cpu regulator to the DT so
  the old voltage can be restored when switching to PLLX
- allocate a state structure instead of globals
- use of_match_machine()
- various style nits fixed

The cpufreq part is dependant on the of_match_machine() series.

Original cover letter:

This series implements the DFLL/CL-DVFS clock source for the fast CPU
cluster on Tegra124, and a cpufreq driver that uses the DFLL for
clocking the CPU. Most of this is based on Paul Walmsley's public patch
set from December 2013, which is available at
http://comments.gmane.org/gmane.linux.ports.tegra/15273

The DFLL clock hardware is a voltage-controlled oscillator plus
control logic that compares the generated output clock with a
51 MHz reference clock, and can make decisions to either lower
or raise the DFLL voltage to keep the output rate close to the
software-requested rate. The voltage changes are done by
communicating with an off-chip PMIC via either I2C or PWM.
As the DFLL oscillator is powered via the CPU rail, using
the DFLL as the CPU clocksource also gives us dynamic CPU
voltage scaling.

This series has been tested on the Jetson TK1 (Rev C). Porting this to
the Venice2 should be simple, though do note that it does not have
active cooling.

Thanks,
Tuomas


Paul Walmsley (1):
  clk: tegra: Add DFLL DVCO reset control for Tegra124

Tuomas Tynkkynen (14):
  clk: tegra: Add binding for the Tegra124 DFLL clocksource
  clk: tegra: Add library for the DFLL clock source (open-loop mode)
  clk: tegra: Add closed loop support for the DFLL
  clk: tegra: Add functions for parsing CVB tables
  clk: tegra: Add Tegra124 DFLL clocksource platform driver
  clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend
  clk: tegra: Add the DFLL as a possible parent of the cclk_g clock
  ARM: tegra: Add the DFLL to Tegra124 device tree
  ARM: tegra: Enable the DFLL on the Jetson TK1
  cpufreq: tegra124: Add device tree bindings
  cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq
  cpufreq: Add cpufreq driver for Tegra124
  ARM: tegra: Add entries for cpufreq on Tegra124
  ARM: tegra: Add CPU regulator to the Jetson TK1 device tree

 .../bindings/clock/nvidia,tegra124-dfll.txt|   69 +
 .../bindings/cpufreq/tegra124-cpufreq.txt  |   44 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   12 +-
 arch/arm/boot/dts/tegra124.dtsi|   33 +-
 arch/arm/mach-tegra/Kconfig|1 +
 drivers/clk/tegra/Makefile |3 +
 drivers/clk/tegra/clk-dfll.c   | 1735 
 drivers/clk/tegra/clk-dfll.h   |   55 +
 drivers/clk/tegra/clk-tegra-super-gen4.c   |4 +-
 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c |  165 ++
 drivers/clk/tegra/clk-tegra124.c   |   61 +
 drivers/clk/tegra/clk.h|3 +
 drivers/clk/tegra/cvb.c|  133 ++
 drivers/clk/tegra/cvb.h|   67 +
 drivers/cpufreq/Kconfig.arm|   14 +-
 drivers/cpufreq/Makefile   |3 +-
 drivers/cpufreq/tegra124-cpufreq.c |  206 +++
 .../cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} |0
 18 files changed, 2601 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
 create mode 100644 drivers/clk/tegra/clk-dfll.c
 create mode 100644 drivers/clk/tegra/clk-dfll.h
 create mode 100644 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
 create mode 100644 drivers/clk/tegra/cvb.c
 create mode 100644 drivers/clk/tegra/cvb.h
 create mode 100644 drivers/cpufreq/tegra124-cpufreq.c
 rename drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} (100%)

-- 
1.8.1.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 v3 12/15] cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The Tegra124 will use a different driver for frequency scaling, so
rename the old driver (which handles only Tegra20) appropriately.

Signed-off-by: Tuomas Tynkkynen 
---
v3: New patch
---
 drivers/cpufreq/Kconfig.arm| 6 +++---
 drivers/cpufreq/Makefile   | 2 +-
 drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} | 0
 3 files changed, 4 insertions(+), 4 deletions(-)
 rename drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} (100%)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7364a53..3795a16 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -241,9 +241,9 @@ config ARM_SPEAR_CPUFREQ
help
  This adds the CPUFreq driver support for SPEAr SOCs.
 
-config ARM_TEGRA_CPUFREQ
-   bool "TEGRA CPUFreq support"
+config ARM_TEGRA20_CPUFREQ
+   bool "Tegra20 CPUFreq support"
depends on ARCH_TEGRA
default y
help
- This adds the CPUFreq driver support for TEGRA SOCs.
+ This adds the CPUFreq driver support for Tegra20 SOCs.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..428451a 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -75,7 +75,7 @@ obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o
 obj-$(CONFIG_ARM_SA1100_CPUFREQ)   += sa1100-cpufreq.o
 obj-$(CONFIG_ARM_SA1110_CPUFREQ)   += sa1110-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
-obj-$(CONFIG_ARM_TEGRA_CPUFREQ)+= tegra-cpufreq.o
+obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)  += tegra20-cpufreq.o
 obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
 
 
##
diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra20-cpufreq.c
similarity index 100%
rename from drivers/cpufreq/tegra-cpufreq.c
rename to drivers/cpufreq/tegra20-cpufreq.c
-- 
1.8.1.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 v3 05/15] clk: tegra: Add DFLL DVCO reset control for Tegra124

[Tuomas Tynkkynen]

From: Paul Walmsley 

The DVCO present in the DFLL IP block has a separate reset line,
exposed via the CAR IP block.  This reset line is asserted upon SoC
reset.  Unless something (such as the DFLL driver) deasserts this
line, the DVCO will not oscillate, although reads and writes to the
DFLL IP block will complete.

Thanks to Aleksandr Frid  for identifying this and
saving hours of debugging time.

Signed-off-by: Paul Walmsley 
[ttynkkynen: ported to tegra124 from tegra114]
Signed-off-by: Tuomas Tynkkynen 
---
 drivers/clk/tegra/clk-tegra124.c | 47 
 drivers/clk/tegra/clk.h  |  3 +++
 2 files changed, 50 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index 9525c68..cc81eab 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -31,6 +31,9 @@
 #define CLK_SOURCE_CSITE 0x1d4
 #define CLK_SOURCE_EMC 0x19c
 
+#define RST_DFLL_DVCO  0x2f4
+#define DVFS_DFLL_RESET_SHIFT  0
+
 #define PLLC_BASE 0x80
 #define PLLC_OUT 0x84
 #define PLLC_MISC2 0x88
@@ -1386,6 +1389,50 @@ static void __init tegra124_clock_apply_init_table(void)
tegra_init_from_table(init_table, clks, TEGRA124_CLK_CLK_MAX);
 }
 
+/**
+ * tegra124_car_barrier - wait for pending writes to the CAR to complete
+ *
+ * Wait for any outstanding writes to the CAR MMIO space from this CPU
+ * to complete before continuing execution.  No return value.
+ */
+static void tegra124_car_barrier(void)
+{
+   readl_relaxed(clk_base + RST_DFLL_DVCO);
+}
+
+/**
+ * tegra124_clock_assert_dfll_dvco_reset - assert the DFLL's DVCO reset
+ *
+ * Assert the reset line of the DFLL's DVCO.  No return value.
+ */
+void tegra124_clock_assert_dfll_dvco_reset(void)
+{
+   u32 v;
+
+   v = readl_relaxed(clk_base + RST_DFLL_DVCO);
+   v |= (1 << DVFS_DFLL_RESET_SHIFT);
+   writel_relaxed(v, clk_base + RST_DFLL_DVCO);
+   tegra124_car_barrier();
+}
+EXPORT_SYMBOL(tegra124_clock_assert_dfll_dvco_reset);
+
+/**
+ * tegra124_clock_deassert_dfll_dvco_reset - deassert the DFLL's DVCO reset
+ *
+ * Deassert the reset line of the DFLL's DVCO, allowing the DVCO to
+ * operate.  No return value.
+ */
+void tegra124_clock_deassert_dfll_dvco_reset(void)
+{
+   u32 v;
+
+   v = readl_relaxed(clk_base + RST_DFLL_DVCO);
+   v &= ~(1 << DVFS_DFLL_RESET_SHIFT);
+   writel_relaxed(v, clk_base + RST_DFLL_DVCO);
+   tegra124_car_barrier();
+}
+EXPORT_SYMBOL(tegra124_clock_deassert_dfll_dvco_reset);
+
 static void __init tegra124_clock_init(struct device_node *np)
 {
struct device_node *node;
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 16ec8d6..4b3f3d0 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -627,6 +627,9 @@ void tegra114_clock_tune_cpu_trimmers_init(void);
 void tegra114_clock_assert_dfll_dvco_reset(void);
 void tegra114_clock_deassert_dfll_dvco_reset(void);
 
+void tegra124_clock_assert_dfll_dvco_reset(void);
+void tegra124_clock_deassert_dfll_dvco_reset(void);
+
 typedef void (*tegra_clk_apply_init_table_func)(void);
 extern tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
 
-- 
1.8.1.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 v3 15/15] ARM: tegra: Add CPU regulator to the Jetson TK1 device tree

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add the CPU voltage regulator for the cpufreq driver.

Signed-off-by: Tuomas Tynkkynen 
---
v3: New patch
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 0c30450..4be7c82 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1858,3 +1858,7 @@
clock-names = "pll_a", "pll_a_out0", "mclk";
};
 };
+
+ {
+   vdd-cpu-supply = <_cpu>;
+};
-- 
1.8.1.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 v3 02/15] clk: tegra: Add library for the DFLL clock source (open-loop mode)

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add shared code to support the Tegra DFLL clocksource in open-loop
mode. This root clocksource is present on the Tegra124 SoCs. The
DFLL is the intended primary clock source for the fast CPU cluster.

This code is very closely based on a patch by Paul Walmsley from
December (http://comments.gmane.org/gmane.linux.ports.tegra/15273),
which in turn comes from the internal driver by originally created
by Aleksandr Frid .

Subsequent patches will add support for closed loop mode and drivers
for the Tegra124 fast CPU cluster DFLL devices, which rely on this
code.

Signed-off-by: Paul Walmsley 
Signed-off-by: Tuomas Tynkkynen 
---
v3: Fix incorrect order of arguments to dfll_scale_dvco_rate call
---
 drivers/clk/tegra/Makefile   |1 +
 drivers/clk/tegra/clk-dfll.c | 1085 ++
 drivers/clk/tegra/clk-dfll.h |   55 +++
 3 files changed, 1141 insertions(+)
 create mode 100644 drivers/clk/tegra/clk-dfll.c
 create mode 100644 drivers/clk/tegra/clk-dfll.h

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index f7dfb72..47320ca 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -1,5 +1,6 @@
 obj-y  += clk.o
 obj-y  += clk-audio-sync.o
+obj-y  += clk-dfll.o
 obj-y  += clk-divider.o
 obj-y  += clk-periph.o
 obj-y  += clk-periph-gate.o
diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
new file mode 100644
index 000..f60ef54
--- /dev/null
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -0,0 +1,1085 @@
+/*
+ * clk-dfll.c - Tegra DFLL clock source common code
+ *
+ * Copyright (C) 2012-2014 NVIDIA Corporation. All rights reserved.
+ *
+ * Aleksandr Frid 
+ * Paul Walmsley 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * This library is for the DVCO and DFLL IP blocks on the Tegra124
+ * SoC. These IP blocks together are also known at NVIDIA as
+ * "CL-DVFS". To try to avoid confusion, this code refers to them
+ * collectively as the "DFLL."
+ *
+ * The DFLL is a root clocksource which tolerates some amount of
+ * supply voltage noise. Tegra124 uses it to clock the fast CPU
+ * complex when the target CPU speed is above a particular rate. The
+ * DFLL can be operated in either open-loop mode or closed-loop mode.
+ * In open-loop mode, the DFLL generates an output clock appropriate
+ * to the supply voltage. In closed-loop mode, when configured with a
+ * target frequency, the DFLL minimizes supply voltage while
+ * delivering an average frequency equal to the target.
+ *
+ * Devices clocked by the DFLL must be able to tolerate frequency
+ * variation. In the case of the CPU, it's important to note that the
+ * CPU cycle time will vary. This has implications for
+ * performance-measurement code and any code that relies on the CPU
+ * cycle time to delay for a certain length of time.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-dfll.h"
+
+/*
+ * DFLL control registers - access via dfll_{readl,writel}
+ */
+
+/* DFLL_CTRL: DFLL control register */
+#define DFLL_CTRL  0x00
+#define DFLL_CTRL_MODE_MASK0x03
+
+/* DFLL_CONFIG: DFLL sample rate control */
+#define DFLL_CONFIG0x04
+#define DFLL_CONFIG_DIV_MASK   0xff
+#define DFLL_CONFIG_DIV_PRESCALE   32
+
+/* DFLL_PARAMS: tuning coefficients for closed loop integrator */
+#define DFLL_PARAMS0x08
+#define DFLL_PARAMS_CG_SCALE   (0x1 << 24)
+#define DFLL_PARAMS_FORCE_MODE_SHIFT   22
+#define DFLL_PARAMS_FORCE_MODE_MASK(0x3 << DFLL_PARAMS_FORCE_MODE_SHIFT)
+#define DFLL_PARAMS_CF_PARAM_SHIFT 16
+#define DFLL_PARAMS_CF_PARAM_MASK  (0x3f << DFLL_PARAMS_CF_PARAM_SHIFT)
+#define DFLL_PARAMS_CI_PARAM_SHIFT 8
+#define DFLL_PARAMS_CI_PARAM_MASK  (0x7 << DFLL_PARAMS_CI_PARAM_SHIFT)
+#define DFLL_PARAMS_CG_PARAM_SHIFT 0
+#define DFLL_PARAMS_CG_PARAM_MASK  (0xff << DFLL_PARAMS_CG_PARAM_SHIFT)
+
+/* DFLL_TUNE0: delay line configuration register 0 */
+#define DFLL_TUNE0 0x0c
+
+/* DFLL_TUNE1: delay line configuration register 1 */
+#define DFLL_TUNE1 0x10
+
+/* DFLL_FREQ_REQ: target DFLL frequency control */
+#define DFLL_FREQ_REQ  0x14
+#define 

[PATCH v3 08/15] clk: tegra: Add the DFLL as a possible parent of the cclk_g clock

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The DFLL clocksource was missing from the list of possible parents for
the fast CPU cluster. Add it to the list.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/clk/tegra/clk-tegra-super-gen4.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c 
b/drivers/clk/tegra/clk-tegra-super-gen4.c
index feb3201..f1f4410 100644
--- a/drivers/clk/tegra/clk-tegra-super-gen4.c
+++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
@@ -44,7 +44,9 @@ static const char *sclk_parents[] = { "clk_m", "pll_c_out1", 
"pll_p_out4",
 
 static const char *cclk_g_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
"pll_p", "pll_p_out4", "unused",
-   "unused", "pll_x" };
+   "unused", "pll_x", "unused", "unused",
+   "unused", "unused", "unused", "unused",
+   "dfllCPU_out" };
 
 static const char *cclk_lp_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
 "pll_p", "pll_p_out4", "unused",
-- 
1.8.1.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 v3 13/15] cpufreq: Add cpufreq driver for Tegra124

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add a new cpufreq driver for Tegra124. Instead of using the PLLX as
the CPU clocksource, switch immediately to the DFLL. It allows the use
of higher clock rates, and will automatically scale the CPU voltage as
well. Besides the CPU clocksource switch, we let the cpufreq-cpu0 driver
for all the cpufreq operations.

This driver also relies on the DFLL driver to fill the OPP table for the
CPU0 device, so that the cpufreq-cpu0 driver knows what frequencies to
use.

Signed-off-by: Tuomas Tynkkynen 
---
v3:
 - separate Kconfig entry
 - use 'select GENERIC_CPUFREQ_CPU0', not depends
 - support unbinding of the platform device
 - allocate a state structure instead of globals
 - use of_match_machine()
 - various style nits fixed
---
 drivers/cpufreq/Kconfig.arm|   8 ++
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/tegra124-cpufreq.c | 206 +
 3 files changed, 215 insertions(+)
 create mode 100644 drivers/cpufreq/tegra124-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 3795a16..07bfed1 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -247,3 +247,11 @@ config ARM_TEGRA20_CPUFREQ
default y
help
  This adds the CPUFreq driver support for Tegra20 SOCs.
+
+config ARM_TEGRA124_CPUFREQ
+   bool "Tegra124 CPUFreq support"
+   depends on ARCH_TEGRA
+   select GENERIC_CPUFREQ_CPU0
+   default y
+   help
+ This adds the CPUFreq driver support for Tegra124 SOCs.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 428451a..25b4f53 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_ARM_SA1100_CPUFREQ)  += sa1100-cpufreq.o
 obj-$(CONFIG_ARM_SA1110_CPUFREQ)   += sa1110-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)  += tegra20-cpufreq.o
+obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
 obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
 
 
##
diff --git a/drivers/cpufreq/tegra124-cpufreq.c 
b/drivers/cpufreq/tegra124-cpufreq.c
new file mode 100644
index 000..5748baa
--- /dev/null
+++ b/drivers/cpufreq/tegra124-cpufreq.c
@@ -0,0 +1,206 @@
+/*
+ * Tegra 124 cpufreq driver
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct tegra124_cpufreq_priv {
+   struct regulator *vdd_cpu_reg;
+   struct clk *cpu_clk;
+   struct clk *pllp_clk;
+   struct clk *pllx_clk;
+   struct clk *dfll_clk;
+   struct platform_device *cpufreq_cpu0_pdev;
+};
+
+static int tegra124_cpu_switch_to_dfll(struct tegra124_cpufreq_priv *priv)
+{
+   struct clk *orig_parent;
+   int ret;
+
+   ret = clk_set_rate(priv->dfll_clk, clk_get_rate(priv->cpu_clk));
+   if (ret)
+   return ret;
+
+   orig_parent = clk_get_parent(priv->cpu_clk);
+   clk_set_parent(priv->cpu_clk, priv->pllp_clk);
+
+   ret = clk_prepare_enable(priv->dfll_clk);
+   if (ret)
+   goto out;
+
+   clk_set_parent(priv->cpu_clk, priv->dfll_clk);
+
+   return 0;
+
+out:
+   clk_set_parent(priv->cpu_clk, orig_parent);
+
+   return ret;
+}
+
+static void tegra124_cpu_switch_to_pllx(struct tegra124_cpufreq_priv *priv)
+{
+   clk_set_parent(priv->cpu_clk, priv->pllp_clk);
+   clk_disable_unprepare(priv->dfll_clk);
+   regulator_sync_voltage(priv->vdd_cpu_reg);
+   clk_set_parent(priv->cpu_clk, priv->pllx_clk);
+}
+
+static int tegra124_cpufreq_probe(struct platform_device *pdev)
+{
+   struct tegra124_cpufreq_priv *priv;
+   struct device_node *np;
+   struct platform_device_info cpufreq_cpu0_devinfo = {};
+   int ret;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   np = of_cpu_device_node_get(0);
+   if (!np)
+   return -ENODEV;
+
+   priv->vdd_cpu_reg = regulator_get(get_cpu_device(0), "vdd-cpu");
+   if (IS_ERR(priv->vdd_cpu_reg)) {
+   ret = PTR_ERR(priv->vdd_cpu_reg);
+   goto out_put_np;
+   }
+
+   priv->cpu_clk = of_clk_get_by_name(np, "cpu_g");
+   if (IS_ERR(priv->cpu_clk)) {
+   ret 

[PATCH v3 11/15] cpufreq: tegra124: Add device tree bindings

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The cpufreq driver for Tegra124 will be a different one than the old
Tegra20 cpufreq driver (tegra-cpufreq), which does not use the device
tree.

Signed-off-by: Tuomas Tynkkynen 
---
v3: vdd-cpu-supply property added
---
 .../bindings/cpufreq/tegra124-cpufreq.txt  | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt 
b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
new file mode 100644
index 000..b1669fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
@@ -0,0 +1,44 @@
+Tegra124 CPU frequency scaling driver bindings
+--
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@0.
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - cpu_g: Clock mux for the fast CPU cluster.
+  - cpu_lp: Clock mux for the low-power CPU cluster.
+  - pll_x: Fast PLL clocksource.
+  - pll_p: Auxiliary PLL used during fast PLL rate changes.
+  - dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
+- vdd-cpu-supply: Regulator for CPU voltage
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+  in unit of nanoseconds.
+
+Example:
+
+cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0>;
+
+   clocks = <_car TEGRA124_CLK_CCLK_G>,
+<_car TEGRA124_CLK_CCLK_LP>,
+<_car TEGRA124_CLK_PLL_X>,
+<_car TEGRA124_CLK_PLL_P>,
+<>;
+   clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", "dfll";
+   clock-latency = <30>;
+   vdd-cpu-supply: <_cpu>;
+   };
+
+   <...>
+};
-- 
1.8.1.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 v3 07/15] clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Save and restore this register since the LP1 restore assembly routines
fiddle with it. Otherwise the CPU would keep running on PLLX after
resume from suspend even when DFLL was the original clocksource.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/clk/tegra/clk-tegra124.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index cc81eab..4b12ddc 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -89,6 +89,8 @@
 #define PMC_PLLM_WB0_OVERRIDE 0x1dc
 #define PMC_PLLM_WB0_OVERRIDE_2 0x2b0
 
+#define CCLKG_BURST_POLICY 0x368
+
 #define UTMIP_PLL_CFG2 0x488
 #define UTMIP_PLL_CFG2_STABLE_COUNT(x) (((x) & 0x) << 6)
 #define UTMIP_PLL_CFG2_ACTIVE_DLY_COUNT(x) (((x) & 0x3f) << 18)
@@ -121,6 +123,8 @@
 #ifdef CONFIG_PM_SLEEP
 static struct cpu_clk_suspend_context {
u32 clk_csite_src;
+   u32 cclkg_burst;
+   u32 cclkg_divider;
 } tegra124_cpu_clk_sctx;
 #endif
 
@@ -1318,12 +1322,22 @@ static void tegra124_cpu_clock_suspend(void)
tegra124_cpu_clk_sctx.clk_csite_src =
readl(clk_base + CLK_SOURCE_CSITE);
writel(3 << 30, clk_base + CLK_SOURCE_CSITE);
+
+   tegra124_cpu_clk_sctx.cclkg_burst =
+   readl(clk_base + CCLKG_BURST_POLICY);
+   tegra124_cpu_clk_sctx.cclkg_divider =
+   readl(clk_base + CCLKG_BURST_POLICY + 4);
 }
 
 static void tegra124_cpu_clock_resume(void)
 {
writel(tegra124_cpu_clk_sctx.clk_csite_src,
clk_base + CLK_SOURCE_CSITE);
+
+   writel(tegra124_cpu_clk_sctx.cclkg_burst,
+   clk_base + CCLKG_BURST_POLICY);
+   writel(tegra124_cpu_clk_sctx.cclkg_divider,
+   clk_base + CCLKG_BURST_POLICY + 4);
 }
 #endif
 
-- 
1.8.1.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 v3 14/15] ARM: tegra: Add entries for cpufreq on Tegra124

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The Tegra124 cpufreq driver relies on certain clocks being present
in the /cpus/cpu@0 node.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/boot/dts/tegra124.dtsi | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 8ff4332..17f2382 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -782,10 +782,19 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0>;
+
+   clocks = <_car TEGRA124_CLK_CCLK_G>,
+<_car TEGRA124_CLK_CCLK_LP>,
+<_car TEGRA124_CLK_PLL_X>,
+<_car TEGRA124_CLK_PLL_P>,
+<>;
+   clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", 
"dfll";
+   /* FIXME: what's the actual transition time? */
+   clock-latency = <30>;
};
 
cpu@1 {
-- 
1.8.1.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: Do not overwrite __machine_arch_type

[Peng Fan]

If using DT_MACHINE_START when enabled CONFIG_OF, the nr of mdesc is ~0.
The value of __machine_arch_type is passsed from bootloader using reigster
r1, and assigned in head-common.S. Remove this line to avoid overwrite it.

Signed-off-by: Peng Fan 
---
 arch/arm/kernel/devtree.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..3a04486 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -243,8 +243,5 @@ const struct machine_desc * __init 
setup_machine_fdt(unsigned int dt_phys)
 
early_init_dt_scan_nodes();
 
-   /* Change machine number to match the mdesc we're using */
-   __machine_arch_type = mdesc->nr;
-
return mdesc;
 }
-- 
1.8.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: AGENCY FOR SHIPPING AND CUSTOM BROKER

[RAIN]

Dear Sir,
Good day!
 
This is Rain Mao from Shenzhen Top Way International Forwarding Co.,Ltd in 
China. 

We interest & expect to establish the cooperation relationship with your esteem 
company.

This is the first letter you recieve from me.Could you please help me to 
forward my contact
to the person whom manage the shipment?
So that  I could share the lastest rates from China to AUSTRIALIA, Thanks! 
 
Our competitive advantages :
l  FCL freight china to all over the world. 
l  DHL,UPS,FEDEX courier door to door price 30% discount to worldwide
l  Door to door sea freight cargo.
l  Free samples & small orders consolidation service.
l  15 days free warehousing.
 
Any question and instruction will be highly appreciated.
Let's talk more about the details.

Thanks regards
 
Ms.Rain 
Shenzhen Top Way International Forwarding Co., Ltd
MOBILE & WHATSAPP:+86-13528787227
TEL:+86-755-89367755-802
Email:r...@topwayfreight.com
Skype:rain-blestocean
QQ:840626628
website: topwayfreight.com
http://hkkingway.en.alibaba.com

Re: Static build of libtraceevent failing on ubuntu13 x86_64

[Namhyung Kim]

Hi Arnaldo,

On Wed, 13 Aug 2014 19:54:38 -0300, Arnaldo Carvalho de Melo wrote:
> Hi guys,
>
>   Have you ever stumbled on this?
>
>   It is the only target breaking when I do a test build of perf + 
> libtraceevent
> on several distros/arches, the command is:
>
> $ make -C tools/perf build-test
>
> Distro is ubuntu12
>
> acme@ubuntu13:~/git/linux$ cat /etc/debian_version 
> wheezy/sid
> acme@ubuntu13:~/git/linux$ uname -a
> Linux ubuntu13 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 
> x86_64 x86_64 x86_64 GNU/Linux
>
> - Arnaldo
>
> - make_static: cd . && make -f Makefile DESTDIR=/tmp/tmp.18qUa2nzwd 
> LDFLAGS=-static
> cd . && make -f Makefile DESTDIR=/tmp/tmp.18qUa2nzwd LDFLAGS=-static
[SNIP]
>   LINK perf
> /home/acme/git/linux/tools/lib/traceevent/libtraceevent.a(event-plugin.o): In 
> function `load_plugin':
> /home/acme/git/linux/tools/lib/traceevent/event-plugin.c:256: warning: Using 
> 'dlopen' in statically linked applications requires at runtime the shared 
> libraries from the glibc version used for linking

Hmm.. this one is actually related to the libtraceevent.  It seems glibc
(and libdl) emits warnings if a static build try to link to the libdl
functions (for obvious reason) and/or nss functions (which might use
libdl).

I found this article [1] but couldn't find how can suppress them.  But
as it's for loading plugins at runtime, we can disable the plugin
support for static builds if we really nervous about the warnings.


[1] http://www.airs.com/blog/archives/54



> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
>  In function `audit_rule_fieldpair_data':
> (.text+0x191b): warning: Using 'getgrnam' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
>  In function `audit_rule_fieldpair_data':
> (.text+0x1978): warning: Using 'getpwnam' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking
> libperf.a(target.o): In function `target__parse_uid':
> /home/acme/git/linux/tools/perf/util/target.c:79: warning: Using 'getpwnam_r' 
> in statically linked applications requires at runtime the shared libraries 
> from the glibc version used for linking
> /home/acme/git/linux/tools/perf/util/target.c:91: warning: Using 'getpwuid_r' 
> in statically linked applications requires at runtime the shared libraries 
> from the glibc version used for linking
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libnuma.a(affinity.o): In 
> function `affinity_ip':
> (.text+0x765): warning: Using 'getaddrinfo' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking

Likewise.


> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libbfd.a(compress.o): In 
> function `bfd_compress_section_contents':
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:100:
>  undefined reference to `compressBound'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:106:
>  undefined reference to `compress'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libbfd.a(compress.o): In 
> function `decompress_contents':
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:49:
>  undefined reference to `inflateInit_'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:56:
>  undefined reference to `inflate'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:59:
>  undefined reference to `inflateReset'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:61:
>  undefined reference to `inflateEnd'

This one is different and seems like linking with libbfd but without zlib?

Thanks,
Namhyung


> collect2: error: ld returned 1 exit status
> make[3]: *** [perf] Error 1
> make[2]: *** [all] Error 2
>   test: test -x ./perf
> make[1]: *** [make_static] Error 1
> make: *** [build-test] Error 2
> make: Leaving directory `/home/acme/git/linux/tools/perf'
>
> real  14m52.077s
> user  39m36.668s
> sys   6m27.970s
> acme@ubuntu13:~/git/linux$ 
--
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] fs: Initialize mountpoint list head in new_mountpoint()

[Murilo Opsfelder Araujo]

The commit 89f7ca1af15bdfe7a6aed343032a84af2a69f736 makes next-20140818
to panic because mountpoint list head was not initialized.  Initializing
it with NULL fixes the problem.

commit 89f7ca1af15bdfe7a6aed343032a84af2a69f736
Author: Eric W. Biederman 
Date:   Sun Sep 22 19:37:01 2013 -0700

vfs: Keep a list of mounts on a mount point

To spot any possible problems call BUG if a mountpoint
is put when it's list of mounts is not empty.

AV: use hlist instead of list_head

Signed-off-by: Murilo Opsfelder Araujo 
---
 fs/namespace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/namespace.c b/fs/namespace.c
index 1a2bbef..1a00bac 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -736,6 +736,7 @@ static struct mountpoint *new_mountpoint(struct dentry 
*dentry)
return ERR_PTR(ret);
}
 
+   INIT_HLIST_HEAD(>m_list);
mp->m_dentry = dentry;
mp->m_count = 1;
hlist_add_head(>m_hash, chain);
-- 
2.1.0.rc2.234.ge4c5f60

--
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] mtd: nand: stm_nand_bch: add new driver

[Brian Norris]

On Fri, Aug 01, 2014 at 10:27:25AM +0100, Lee Jones wrote:
> On Thu, 31 Jul 2014, Brian Norris wrote:
> > On Thu, Jul 31, 2014 at 05:47:09PM +0100, Lee Jones wrote:
> > > > >  arch/arm/boot/dts/stih41x-b2020.dtsi   |   40 +
> > > > 
> > > > This will need refreshed and sent as a separate patch, to go through the
> > > > appropriate ARM tree.
> > > 
> > > As above.
> > 
> > OK, if you're really planning to send a final git pull request, you'll
> > need to have this in a separate branch for them to take, then.
> 
> Of course.  Same goes with the DTS(I) changes.

PSA: make sure your patches will bisect if you're going to send so many.
I don't want to have to copy-and-paste my build results again.

> > > > (Related: Coverity caught a whole bunch of these type of bugs in the MTD
> > > > test modules. I have fixes queued up that I meant to test and submit
> > > > soon.)
> > > 
> > > I will attempt to play around with Coverity.
> > 
> > Good luck :) Coverity isn't always the easiest to get running
> > individually. You might have better luck (once your stuff is merged)
> 
> Sorry merged where?

To Linus's tree. Presumably that's what you're sending your patches to
me for? :)

Dave Jones runs a Coverity instance against mainline.

> > checking out the free service offered for open source projects through
> > github. There's a project instance set up for mainline:
> > 
> >   https://scan.coverity.com/projects/128?tab=overview
> 
> Thanks.  I'll have a play.
> 
> > > > > +/*
> > > > > + * Detect an erased page, tolerating and correcting up to a 
> > > > > specified number of
> > > > > + * bits at '0'.  (For many devices, it is now deemed within spec for 
> > > > > an erased
> > > > > + * page to include a number of bits at '0', either as a result of 
> > > > > read-disturb
> > > > > + * behaviour or 'stuck-at-zero' failures.)  Returns the number of 
> > > > > corrected
> > > > > + * bits, or a '-1' if we have exceeded the maximum number of bits at 
> > > > > '0' (likely
> > > > > + * to be a genuine uncorrectable ECC error).  In the latter case, 
> > > > > the data must
> > > > > + * be returned unmodified, in accordance with the MTD API.
> > > > > + */
> > > > > +static int check_erased_page(uint8_t *data, uint32_t page_size, int 
> > > > > max_zeros)
> > > > 
> > > > Another "check erased page" implementation? Sigh... it would be nice if
> > > > we could agree on a common implementation to share. My last attempt was
> > > > unsuccessful, since some drivers have some very odd requirements.
> > > > 
> > > > > +{
> > > > > + uint8_t *b = data;
> > > > > + int zeros = 0;
> > > > > + int i;
> > > > > +
> > > > > + for (i = 0; i < page_size; i++) {
> > > > > + zeros += hweight8(~*b++);
> > > > > + if (zeros > max_zeros)
> > > > > + return -1;
> > > > > + }
> > > > > +
> > > > > + if (zeros)
> > > > > + memset(data, 0xff, page_size);
> > > > 
> > > > It seems like you're not considering the spare area at all. What if this
> > > > is a mostly-blank page, with ECC data, but most of the bitflips are in
> > > > the spare area? Then you will "correct" this page to all 0xFF, not
> > > > noticing that this was really not a blank page at all.
> > > 
> > > I could really use Angus' advice on this one.  Although, I fear he may
> > > have disappeared into the cosmos.  If I remember correctly (I'm
> > > getting rusty on this now), this controller doesn't allow access to
> > > the spare area easily.  I think it's all handled automatically
> > > i.e. without intervention.
> > 
> > That's tough. It's pretty hard to support NAND without *any* access to
> > spare area.
> 
> I think we _can_ do it, via the second (Flex) interface, but it appears
> to be readonly and we only do so when initially scanning/building the
> BBTs.

Does your driver pass the MTD tests? (drivers/mtd/tests/)

> I'm not sure I follow your example precisely.  When you say that most
> of the bitflips are in the spare area, do you mean that there's usable
> data in there?

What I mean is that because ALL [*] data (in- and out-of-band) is used
by the error correction algorithm, then you need to use all of that data
when determining that a page is erased, not just the data that you see
in-band.

Consider this: you program a page with all 0xFF data, except for a
single byte of data. Then suppose your page experiences too many
bitflips in the spare area. When you try to read this page back, you
will experience an ECC error, and fall back to "checking for an erased
page." But if this algorithm only looks at the in-band data, it may see
mostly-0xFF, with fewer than 8 bits that are low. Because it ignored all
of the ECC parity data stored OOB, then your algorithm might falsely
declare your page "erased," when in fact it held data and is instead
truly uncorrectable.

This kind of subtle error might lead to silent corruption.

I haven't exactly seen this in practice, since most MTD 

[PATCH v2] ARM: dts: Add sdio0 and sdio1 to the rk3288

[Addy Ke]

This patch requires that 
land in order to compile.

Signed-off-by: Addy Ke 
---
Changes in v2:
- repost patch to match what's in Heiko's "wip/v3.18-next/dts" tree
  for the other dwmmc controllers
- add "cd" and "int" line, suggested by Doug Anderson
- fix up sdio1 configuration error 

 arch/arm/boot/dts/rk3288.dtsi | 86 +++
 1 file changed, 86 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 36be7bb..91576ae 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -88,6 +88,26 @@
status = "disabled";
};
 
+   sdio0: dwmmc@ff0d {
+   compatible = "rockchip,rk3288-dw-mshc";
+   clocks = < HCLK_SDIO0>, < SCLK_SDIO0>;
+   clock-names = "biu", "ciu";
+   fifo-depth = <0x100>;
+   interrupts = ;
+   reg = <0xff0d 0x4000>;
+   status = "disabled";
+   };
+
+   sdio1: dwmmc@ff0e {
+   compatible = "rockchip,rk3288-dw-mshc";
+   clocks = < HCLK_SDIO1>, < SCLK_SDIO1>;
+   clock-names = "biu", "ciu";
+   fifo-depth = <0x100>;
+   interrupts = ;
+   reg = <0xff0e 0x4000>;
+   status = "disabled";
+   };
+
emmc: dwmmc@ff0f {
compatible = "rockchip,rk3288-dw-mshc";
clocks = < HCLK_EMMC>, < SCLK_EMMC>;
@@ -508,6 +528,72 @@
};
};
 
+   sdio0 {
+   sdio0_clk: sdio0-clk {
+   rockchip,pins = <4 25 RK_FUNC_1 
_pull_none>;
+   };
+
+   sdio0_cmd: sdio0-cmd {
+   rockchip,pins = <4 24 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_cd: sdio0-cd {
+   rockchip,pins = <4 26 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_pwr: sdio0-pwr {
+   rockchip,pins = <4 28 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_int: sdio0-int {
+   rockchip,pins = <4 30 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_bus1: sdio0-bus1 {
+   rockchip,pins = <4 20 RK_FUNC_1 _pull_up>;
+   };
+
+   sdio0_bus4: sdio0-bus4 {
+   rockchip,pins = <4 20 RK_FUNC_1 _pull_up>,
+   <4 21 RK_FUNC_1 _pull_up>,
+   <4 22 RK_FUNC_1 _pull_up>,
+   <4 23 RK_FUNC_1 _pull_up>;
+   };
+   };
+
+   sdio1 {
+   sdio1_clk: sdio1-clk {
+   rockchip,pins = <4 7 RK_FUNC_4 _pull_none>;
+   };
+
+   sdio1_cmd: sdio1-cmd {
+   rockchip,pins = <4 6 RK_FUNC_4 _pull_up>;
+   };
+
+   sdio1_cd: sdio1-cd {
+   rockchip,pins = <3 28 RK_FUNC_4 _pull_up>;
+   };
+
+   sdio1_pwr: sdio1-pwr {
+   rockchip,pins = <4 9 RK_FUNC_4 _pull_up>;
+   };
+
+   sdio1_int: sdio1-int {
+   rockchip,pins = <3 31 RK_FUNC_4 _pull_up>;
+   };
+
+   sdio1_bus1: sdio1-bus1 {
+   rockchip,pins = <3 24 RK_FUNC_4 _pull_up>;
+   };
+
+   sdio1_bus4: sdio1-bus4 {
+   rockchip,pins = <3 24 RK_FUNC_4 _pull_up>,
+   <3 25 RK_FUNC_4 _pull_up>,
+   <3 26 RK_FUNC_4 _pull_up>,
+   <3 27 RK_FUNC_4 _pull_up>;
+   };
+   };
+
emmc {
emmc_clk: emmc-clk {
rockchip,pins = <3 18 RK_FUNC_2 
_pull_none>;
-- 
1.8.3.2


--
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: i8k: Don't revert affinity in i8k_smm

[Guenter Roeck]

On Tue, Aug 19, 2014 at 09:19:55AM +1000, Con Kolivas wrote:
> As a followup to this discussion:
> 
> On Tue, 15 Jul 2014 08:01:13 PM Sam Asadi wrote:
> > Commit f36fdb9f0266 (i8k: Force SMM to run on CPU 0) adds support
> > for multi-core CPUs to the driver. Unfortunately, that causes it
> > to fail loading if compiled without SMP support, at least on
> > 32 bit kernels. Kernel log shows "i8k: unable to get SMM Dell
> > signature", and function i8k_smm is found to return -EINVAL.
> > 
> > Testing revealed that the culprit is the missing return value check
> > of set_cpus_allowed_ptr.
> 
> It appears that the original commit f36fdb9f0266 changes the affinity for the 
> duration of i8k_smm function and then unconditionally reverts the affinity to 
> the old cpu mask regardless of whether the function succeeds or fails. As 
> this 
> must run on CPU 0 at all times it does not make sense to revert the affinity 
> at 
> the end of the function. Proposed patch attached.
> 
Sorry, I must have missed the rest of the discussion. What problem is this patch
supposed to fix ? Or, in other words, is there a problem with the current code ?
I also don't really understand the argument above. Why does it not make sense to
revert to the original affinity ? After all, only the SMM call must run on CPU
0. Why does it not make sense to let the rest of the code run on another CPU ?

Thanks,
Guenter

> Signed-off-by: Con Kolivas 
> 
> ---
>  drivers/char/i8k.c |6 --
>  1 file changed, 6 deletions(-)
> 
> Index: linux-3.16-ck1/drivers/char/i8k.c
> ===
> --- linux-3.16-ck1.orig/drivers/char/i8k.c2014-08-12 14:07:49.0 
> +1000
> +++ linux-3.16-ck1/drivers/char/i8k.c 2014-08-19 09:09:57.939056696 +1000
> @@ -132,12 +132,8 @@ static int i8k_smm(struct smm_regs *regs
>  {
>   int rc;
>   int eax = regs->eax;
> - cpumask_var_t old_mask;
>  
>   /* SMM requires CPU 0 */
> - if (!alloc_cpumask_var(_mask, GFP_KERNEL))
> - return -ENOMEM;
> - cpumask_copy(old_mask, >cpus_allowed);
>   rc = set_cpus_allowed_ptr(current, cpumask_of(0));
>   if (rc)
>   goto out;
> @@ -203,8 +199,6 @@ static int i8k_smm(struct smm_regs *regs
>   rc = -EINVAL;
>  
>  out:
> - set_cpus_allowed_ptr(current, old_mask);
> - free_cpumask_var(old_mask);
>   return rc;
>  }
>  
> 
> -- 
> -ck
> 
--
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/2] PM: Print pending wakeup IRQ preventing suspend to dmesg

[Todd Poynor]

On Fri, Aug 1, 2014 at 9:30 AM, Amit Pundir  wrote:
> From: Todd Poynor 
>
> Currently when a pending wakeup irq stops suspend, it can be difficult
> to determine why suspend was prevented and which IRQ was actually
> responsible.
>
> In order to help debug these situations, this patch prints the IRQ
> number and action name of that pending wakeup irq which prevents suspend.
> This patch comes from the Android patch set, where its been used to debug
> suspend problems.

This info is sometimes useful to debugging Android suspend / battery
life problems, such as to detect a driver that is failing to service
or clear a wakeup interrupt condition.

In general, we intend to fold reporting of suspend abort reasons
(wakeup IRQ pending, wakelock grabbed, task refusing to freeze...)
into the wakeup reason reporting API to userspace previously discussed
on the linux-pm list (and also revive discussion of how to rework that
for mainline acceptance soon).

Thanks,


Todd
--
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/5] KVM: vmx: fix ept reserved bits for 1-GByte page

[Wanpeng Li]

Hi Paolo,
On Mon, Aug 18, 2014 at 12:18:59PM +0200, Paolo Bonzini wrote:
>Il 18/08/2014 11:50, Wanpeng Li ha scritto:
>> EPT misconfig handler in kvm will check which reason lead to EPT 
>> misconfiguration after vmexit. One of the reasons is that an EPT 
>> paging-structure entry is configured with settings reserved for 
>> future functionality. However, the handler can't identify if 
>> paging-structure entry of reserved bits for 1-GByte page are 
>> configured, since PDPTE which point to 1-GByte page will reserve 
>> bits 29:12 instead of bits 7:3 which are reserved for PDPTE that 
>> references an EPT Page Directory. This patch fix it by reserve 
>> bits 29:12 for 1-GByte page. 
>> 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kvm/vmx.c | 14 ++
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index bfe11cf..71cbee5 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -5521,9 +5521,14 @@ static u64 ept_rsvd_mask(u64 spte, int level)
>>  for (i = 51; i > boot_cpu_data.x86_phys_bits; i--)
>>  mask |= (1ULL << i);
>>  
>> -if (level > 2)
>> -/* bits 7:3 reserved */
>> -mask |= 0xf8;
>> +if (level > 2) {
>
>level can be 4 here.  You have to return 0xf8 for level == 4.
>
>The same "if" statement then can cover both 2MB and 1GB pages, like
>
>if (spte & (1ULL << 7))
>/* 1GB/2MB page, bits 29:12 or 20:12 reserved 
> respectively */
>mask |= (PAGE_SIZE << ((level - 1) * 9)) - PAGE_SIZE;
>else
>/* bits 6:3 reserved */
>mask |= 0x78;
>
>> -if (level == 1 || (level == 2 && (spte & (1ULL << 7 {
>> +if (level == 1 || ((level == 3 || level == 2)
>> +&& (spte & (1ULL << 7 {
>
>This condition can be simplified by checking the return value of ept_rsvd_mask.
>If it includes 0x38, this is a large page.  Otherwise it is a leaf page and
>you can go down the "if".

As you know, 5:3 bits which used for EPT MT are not reserved bits, so 
I fail to understand why check the return value of ept_rsvd_mask and 
it's a large page if includes 0x38. Could you eplain in more details? ;-)

Regards,
Wanpeng Li 

>
>Paolo
>
>>  u64 ept_mem_type = (spte & 0x38) >> 3;
>>  
>>  if (ept_mem_type == 2 || ept_mem_type == 3 ||
>> 
--
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/2] PM: Suspend: Print wall time at suspend entry and exit

[Todd Poynor]

> Existing printk timestamps in a dmesg only log suspend activities
> (e.g. filesystem syncs, freezing/unfreezing tasks etc) while the
> system has already started to enter/exit the suspend state. Sometimes
> it is handy to have suspend entry/exit overhead information while
> debugging suspend issues. This patch print markers with wall
> timestamps at suspend Entry and Exit in the kernel log. These
> timestamps can be used to compute how long the system spent in
> low-power suspend state plus the entry/exit overhead.
>
> This patch comes from the Android patch set, where its been used to
> help diagnose battery life problems in various Android-based devices.

Thanks Amit.  For this patch, we're actually moving away from
primarily analyzing the kernel log of suspend times, instead logging
this info via userspace.  Android is now using the wakeup_count
suspend interface (previously autosleep was employed), allowing
userspace to be informed whenever suspend is entered and resumed.  The
Android batterystats service logs timestamps for these, along with the
wakeup reason info previously discussed on the linux-pm list.  But it
still is occasionally useful to see the suspend times when debugging
problems based on the kernel log.


Todd
--
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] earlyprintk: re-enable earlyprintk calling early_param

[Keun-O Park]

FYI only if you missed my previous 2 replies which didn't reach the
mailing list.
Thanks.



On Mon, Aug 18, 2014 at 12:13 PM, Sahara  wrote:
>
> 2014년 08월 16일 03:34, Rusty Russell 쓴 글:
>
>> kpark3...@gmail.com writes:
>>>
>>> From: Sahara 
>>>
>>> Although there are many obs_kernel_param and its names are
>>> earlyprintk and also EARLY_PRINTK is also enabled, we could not
>>> see the early_printk output properly until now. This patch
>>> considers earlycon as well as earlyprintk.
>>
>> Hmm, the initial "earlycon" hack slipped in when I wasn't looking.
>> I don't think we should extend it.
>>
>> Why not make the thing(s) you want early_param()s?
>>
>> Cheers,
>> Rusty.
>
> The earlycon and the earlyprintk are scattered and used in many
> architectures.
> It looks earlycon just could be a subset of earlyprintk.
> The earlycon is for uart specific, while the earlyprintk is to support vga,
> efi, xen, serial, and so on. Especially ARM uses earlyprintk in many places.
> And, I am not sure if this is a good chance to replace all the earlyprintk
> with the earlycon. As of now, it's fair for both earlycon and earlyprintk.
> Or perhaps removing case#2, see in my previous email to Andrew Morton, is
> better?, so users be forced to specify earlycon and earlyprintk in cmdline
> if they want to see early_printk() output.
>
> Thanks.
>
> Best Regards,
> Sahara.
>
>
>>
>>> --- a/init/main.c
>>> +++ b/init/main.c
>>> @@ -426,7 +426,8 @@ static int __init do_early_param(char *param, char
>>> *val, const char *unused)
>>> for (p = __setup_start; p < __setup_end; p++) {
>>> if ((p->early && parameq(param, p->str)) ||
>>> (strcmp(param, "console") == 0 &&
>>> -strcmp(p->str, "earlycon") == 0)
>>> +((strcmp(p->str, "earlycon") == 0) ||
>>> +(strcmp(p->str, "earlyprintk") == 0)))
>>> ) {
>>> if (p->setup_func(val) != 0)
>>> pr_warn("Malformed early option '%s'\n",
>>> param);
>>> --
>>> 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] mtd: nand: stm_nand_bch: add new driver

[Brian Norris]

On Wed, Aug 06, 2014 at 02:32:18AM +0530, pe...@pek-sem.com wrote:
> On Tuesday 05 August 2014 07:53 PM, Lee Jones wrote:
> >On Thu, 03 Jul 2014, Gupta, Pekon wrote:
> + /* Load last page of block */
> + offs = (loff_t)block << chip->phys_erase_shift;
> + offs += mtd->erasesize - mtd->writesize;
> + if (bch_read_page(nandi, offs, buf) < 0) {
> >>
> >>*Important*: You shouldn't call internal functions directly here..
> >>Instead use chip->_read() OR mtd-read() that will:

I'm not sure exactly what you're saying in the above line (chip->_read()
is not a function, and and mtd-read() is syntactically incorrect),
but...

You most certainly do *not* want to call mtd->_read() directly (or any
of the callbacks prefixed with underscores). That is one of the main
purposes of:

commit 3c3c10bba1e4ccb75b41442e45c1a072f6cded19
Author: Artem Bityutskiy 
Date:   Mon Jan 30 14:58:32 2012 +0200

mtd: add leading underscore to all mtd functions

> >>- keep this code independent of ECC modes added in your driver
> >>in future.
> >>- implicitly handle updating mtd->ecc_stat (like ecc_failed,
> >>bits_corrected).
> >>- implicitly take care of address alignments checks and offset
> >>calculations.
> >>
> >> >>bch_read_page())
> >
> >Yourself and Brian seem to disagree on this point.  Which is correct?

I think you've worked out a decent solution in your latest series, but
a few of the guiding principles:

 * BBT code can rely on generic NAND implementation details (e.g.,
   chip->options), but it can also act as an MTD user (i.e., use the
   mtd_*() APIs)

 * It should not rely on details of the particular NAND driver (e.g.,
   calling your ST bch_read_page())

 * Look at similar code and try to follow its pattern where it makes
   sense. So while nand_bbt.c is not a shining example in all regards, I
   think it does OK in terms of some of the key points of layering.

> + /* Is block already considered bad? (will also catch
> invalid offsets) */
> + ret = mtd_block_isbad(mtd, offs);
> >>>
> >>>You're violating some of the layering here; the low-level driver
> >>>probably shouldn't be calling the high-level mtd_*() APIs. On
> >>>a similar
> >>>note, I'm not 100% confident that the nand_base/nand_bbt
> >>>separation is
> >>>written cleanly enough for easy maintenance of your nand_base
> >>>+ ST BBT
> >>>code in parallel. I might need a second look at that, and I think
> >>>modularizing your BBT code to a separate file could help ease
> >>>this a
> >>>little.
> >
> >... here is the converse argument.

I think I clarified this one; I misspoke about the mtd_*() APIs.

> I think somewhere in earlier comments, Brian also supported
> to use high-level function like mtd_read(). Also, nand_bbt.c
> itself uses 'mtd_read(), mtd_read_oob() and mtd_write_oob()
> at many places. So I'll let Brain decide here.
> But having low-level function will add redundant code for
> re-checking and aligning the addresses boundaries to block
> and page/sector sizes.

Not all checks are redundant. It's redundant to have the direct
descendant doing the same checks that the parent does, like:

  mtd_read() (checks boundaries)
  |_ mtd->_read() (e.g., nand_read())

So nand_read() and nand_do_read_ops() don't need the checking.

But for a BBT implementation, it can help to make sure that its
page/block/etc. arithmetic fits the right bounds when it ends up
deciding to scan a block.

Now, it still may be easy to prove that the checks are
redundant/unnecessary for correctly-written code, but if the layering
makes sense, then it still may be a better choice to simply use the
high-level, self-checking API than to try to dig deeper. For instance,
I'm pretty sure UBI does some checks to make sure it's not reading off
the end of an MTD, but it still calls mtd_read() because it's The Right
Thing (TM).

Brian
--
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 v15 7/7] mm: Don't split THP page when syscall is called

[Rik van Riel]

On 08/17/2014 08:17 PM, Minchan Kim wrote:

We don't need to split THP page when MADV_FREE syscall is
called. It could be done when VM decide really frees it so
we could avoid unnecessary THP split.

Cc: Andrea Arcangeli 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 


Acked-by: Rik van Riel 

--
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 v15 2/7] x86: add pmd_[dirty|mkclean] for THP

[Rik van Riel]

On 08/17/2014 08:17 PM, Minchan Kim wrote:

MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.

This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Acked-by: Zhang Yanfei 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 


Acked-by: Rik van Riel 

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

Re: [PATCH 7/8] mtd: nand: stm_nand_bch: add support for ST's BCH NAND controller

[Brian Norris]

On Mon, Aug 18, 2014 at 11:31:58AM +0100, Lee Jones wrote:
...
> +/* Derive Hamming-FLEX timing register values from 'nand_sdr_timings' data */
> +static void flex_calc_timing_registers(const struct nand_sdr_timings *spec,
> +int tCLK, int relax,
> +uint32_t *ctl_timing,
> +uint32_t *wen_timing,
> +uint32_t *ren_timing)
> +{
> + int tMAX_HOLD;
> + int n_ctl_setup;
> + int n_ctl_hold;
> + int n_ctl_wb;
> +
> + int tMAX_WEN_OFF;
> + int n_wen_on;
> + int n_wen_off;
> +
> + int tMAX_REN_OFF;
> + int n_ren_on;
> + int n_ren_off;
> +
> + /*
> +  * CTL_TIMING
> +  */
> +
> + /*  - SETUP */
> + n_ctl_setup = (PICO_TO_MILI(spec->tCLS_min - spec->tWP_min)
> ++ tCLK - 1)/tCLK;

Can you add spaces around the '/'? It helps readability. (This is
repeated throughout.)

> + if (n_ctl_setup < 1)
> + n_ctl_setup = 1;
> + n_ctl_setup += relax;

It's been discussed that many drivers probably want a simplified version
of struct nand_sdr_timings where some of these computations are done
already. As we haven't developed such a simplification yet, I'm fine
taking your computations as-is. If nothing else, they serve as a
reference for a later simplification. (Just FYI.)

> +
> + /*  - HOLD */
> + tMAX_HOLD = spec->tCLH_min;
> + if (spec->tCH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tCH_min;
> + if (spec->tALH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tALH_min;
> + if (spec->tDH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tDH_min;
> + n_ctl_hold = (PICO_TO_MILI(tMAX_HOLD) + tCLK - 1)/tCLK + relax;
> +
> + /*  - CE_deassert_hold = 0 */
> +
> + /*  - WE_high_to_RBn_low */
> + n_ctl_wb = (PICO_TO_MILI(spec->tWB_max) + tCLK - 1)/tCLK;
> +
> + *ctl_timing = ((n_ctl_setup & 0xff) |
> +(n_ctl_hold & 0xff) << 8 |
> +(n_ctl_wb & 0xff) << 24);
> +
> + /*
> +  * WEN_TIMING
> +  */
> +
> + /*  - ON */
> + n_wen_on = (PICO_TO_MILI(spec->tWH_min) + tCLK - 1)/tCLK + relax;
> +
> + /*  - OFF */
> + tMAX_WEN_OFF = spec->tWC_min - spec->tWH_min;
> + if (spec->tWP_min > tMAX_WEN_OFF)
> + tMAX_WEN_OFF = spec->tWP_min;
> + n_wen_off = (PICO_TO_MILI(tMAX_WEN_OFF) + tCLK - 1)/tCLK + relax;
> +
> + *wen_timing = ((n_wen_on & 0xff) |
> +(n_wen_off & 0xff) << 8);
> +
> + /*
> +  * REN_TIMING
> +  */
> +
> + /*  - ON */
> + n_ren_on = (PICO_TO_MILI(spec->tREH_min) + tCLK - 1)/tCLK + relax;
> +
> + /*  - OFF */
> + tMAX_REN_OFF = spec->tRC_min - spec->tREH_min;
> + if (spec->tRP_min > tMAX_REN_OFF)
> + tMAX_REN_OFF = spec->tRP_min;
> + if (spec->tREA_max > tMAX_REN_OFF)
> + tMAX_REN_OFF = spec->tREA_max;
> + n_ren_off = (PICO_TO_MILI(tMAX_REN_OFF) + tCLK - 1)/tCLK + 1 + relax;
> +
> + *ren_timing = ((n_ren_on & 0xff) |
> +(n_ren_off & 0xff) << 8);
> +}
> +
> +/* Derive BCH timing register values from 'nand_sdr_timings' data */
> +static void bch_calc_timing_registers(const struct nand_sdr_timings *spec,
> +   int tCLK, int relax,
> +   uint32_t *ctl_timing,
> +   uint32_t *wen_timing,
> +   uint32_t *ren_timing)
> +{
> + int tMAX_HOLD;
> + int n_ctl_setup;
> + int n_ctl_hold;
> + int n_ctl_wb;
> +
> + int n_wen_on;
> + int n_wen_off;
> + int wen_half_on;
> + int wen_half_off;
> +
> + int tMAX_REN_ON;
> + int tMAX_CS_DEASSERT;
> + int n_d_latch;
> + int n_telqv;
> + int n_ren_on;
> + int n_ren_off;
> +
> + /*
> +  * CTL_TIMING
> +  */
> +
> + /*  - SETUP */
> + if (spec->tCLS_min > spec->tWP_min)
> + n_ctl_setup = (PICO_TO_MILI(spec->tCLS_min - spec->tWP_min)
> ++ tCLK - 1)/tCLK;
> + else
> + n_ctl_setup = 0;
> + n_ctl_setup += relax;
> +
> + /*  - HOLD */
> + tMAX_HOLD = spec->tCLH_min;
> + if (spec->tCH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tCH_min;
> + if (spec->tALH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tALH_min;
> + if (spec->tDH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tDH_min;
> + n_ctl_hold = (PICO_TO_MILI(tMAX_HOLD) + tCLK - 1)/tCLK + relax;
> + /*  - CE_deassert_hold = 0 */
> +
> + /*  - WE_high_to_RBn_low */
> + n_ctl_wb = (PICO_TO_MILI(spec->tWB_max) + tCLK - 1)/tCLK;
> +
> + *ctl_timing = ((n_ctl_setup & 0xff) |
> +(n_ctl_hold & 0xff) << 8 |
> +(n_ctl_wb & 0xff) << 24);
> +
> + /*
> +  * WEN_TIMING
> +  */
> +
> + 

Re: [alsa-devel] [PATCH v3 2/2] mfd: arizona: Update DT binding to support INn_MODE init_data

[Inha Song]

Hi, Charles.
Thanks for your review.

On Mon, 18 Aug 2014 15:29:45 +0100
Charles Keepax  wrote:

> On Mon, Aug 18, 2014 at 08:00:09PM +0900, Inha Song wrote:
> > This patch update DT binding to support INn_MODE init_data. Each
> > input signal path can be configurated either as a Analogue or
> > Digital using the INn_MODE registers.
> > 
> > Signed-off-by: Inha Song 
> > ---
> >  Documentation/devicetree/bindings/mfd/arizona.txt | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> > b/Documentation/devicetree/bindings/mfd/arizona.txt
> > index 5c7e723..0064b21 100644
> > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > @@ -42,6 +42,14 @@ Optional properties:
> >  the chip default will be used.  If present exactly five values must
> >  be specified.
> >  
> > +  - wlf,inmode : A list of INn_MODE register values, where n is the number
> > +of input signals. Each input signal path can be configurated either as 
> > a
> > +Analogue or Digital using the INn_MODE registers. If absent, INn_MODE
> 
> I would replace the second sentence here with something like
> "Valid values are 0 (Differential), 1 (Single-ended) and 2 (Digital
> Microphone)."
> 

OK, I will fix it like this:

- wlf,inmode : A list of INn_MODE register values, where n is the number
  of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
  2 (Digital Microphone). If absent, INn_MODE registers.

Best regards,
Inha Song.

> Thanks,
> Charles
> 
> > +registers set to 0 by default. If present, values must be specified 
> > less
> > +than or equal to the number of input singals. If values less than the
> > +number of input signals, elements that has not been specifed are set 
> > to 0
> > +by default.
> > +
> >- DCVDD-supply, MICVDD-supply : Power supplies, only need to be 
> > specified if
> >  they are being externally supplied. As covered in
> >  Documentation/devicetree/bindings/regulator/regulator.txt
> > -- 
> > 2.0.0.390.gcb682f8
> > 
--
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] memory-hotplug: add sysfs zones_online_to attribute

[Zhang Zhen]

On 2014/8/19 5:48, David Rientjes wrote:
> On Wed, 13 Aug 2014, Zhang Zhen wrote:
> 
>> Currently memory-hotplug has two limits:
>> 1. If the memory block is in ZONE_NORMAL, you can change it to
>> ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
>> 2. If the memory block is in ZONE_MOVABLE, you can change it to
>> ZONE_NORMAL, but this memory block must be adjacent to ZONE_NORMAL.
>>
>> With this patch, we can easy to know a memory block can be onlined to
>> which zone, and don't need to know the above two limits.
>>
>> Updated the related Documentation.
>>
>> Change v1 -> v2:
>> - optimize the implementation following Dave Hansen's suggestion
>>
>> Signed-off-by: Zhang Zhen 
> 
> linux-next build failure:
> 
> drivers/built-in.o: In function `show_zones_online_to':
> memory.c:(.text+0x13ee09): undefined reference to `test_pages_in_a_zone'
> 
The function implementation in mm/memory_hotplug.c is only built if
CONFIG_MEMORY_HOTREMOVE is enabled.

A fix has been proposed.
http://ozlabs.org/~akpm/mmots/broken-out/memory-hotplug-add-sysfs-zones_online_to-attribute-fix-2.patch

Thanks!
> 


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

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
>...
>> Well, it will become necessary as old code gets dismantled and converted 
>> towards
>> this patchset. To give you an example that I'm familiar with, for arch/arm 
>> the
>> host bridge drivers have moved into drivers/pci/host, but they still 
>> depend/use
>> the bios32 infrastructure that takes care of setting up the irq. When they 
>> switch
>> to my version they would have to go and debug the "irq not being assigned" 
>> issue
>> and it is quite likely that some of the people doing the conversion will 
>> complain
>> about my code rather than understanding the issue. What I'm trying to do is 
>> to
>> make switching to my patchset as painless as possible, with a cleanup to 
>> remove
>> redundant operations coming after the switchover.
>
>While the goal is fine, until we see a common pattern for what needs to
>go into pcibios_add_device() I think we should have an arm64-specific
>implementation (and probably an arm32 specific one as well). I can see
>powerpc uses it for setting the DMA ops. Would we have a similar need on
>arm64 to choose between coherent and non-coherent dma_ops?

Liviu,

I have the same feeling with Catalin. An arm64-specific implementation of
pcibios_add_device() would be better.

No more other concerns from my side.

>
>Also at some point we'll get ACPI support, so I'm not sure what we do
>with assigning the dev->irq here but definitely of_* functions won't
>work.
>
>-- 
>Catalin

-- 
Richard Yang
Help you, Help me

--
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/5] softlockup: make detector be aware of task switch of processes hogging cpu

[Chai Wen]

On 08/19/2014 04:38 AM, Don Zickus wrote:

> On Mon, Aug 18, 2014 at 09:02:00PM +0200, Ingo Molnar wrote:
>>
>> * Don Zickus  wrote:
>>
>> So I agree with the motivation of this improvement, but 
>> is this implementation namespace-safe?
>
> What namespace are you worried about colliding with?  I 
> thought softlockup_ would provide the safety??  Maybe I 
> am missing something obvious. :-(

 I meant PID namespaces - a PID in itself isn't guaranteed 
 to be unique across the system.
>>>
>>> Ah, I don't think we thought about that.  Is there a better 
>>> way to do this?  Is there a domain id or something that can 
>>> be OR'd with the pid?
>>
>> What is always unique is the task pointer itself. We use pids 
>> when we interface with user-space - but we don't really do that 
>> here, right?
> 
> No, I don't believe so.  Ok, so saving 'current' and comparing that should
> be enough, correct?
> 


I am not sure of the safety about using pid here with namespace.
But as to the pointer of process, is there a chance that we got a 'historical'
address saved in the 'softlockup_warn_pid(or address)_saved' and the current
hogging process happened to get the same task pointer address?
If it never happens, I think the comparing of address is ok.

thanks
chai wen

> Cheers,
> Don
> .
> 



-- 
Regards

Chai Wen
--
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/8] mtd: nand: Support for new DT NAND driver

[Brian Norris]

On Mon, Aug 18, 2014 at 11:31:51AM +0100, Lee Jones wrote:
> I believe all of your queries have either been answered or addressed
> and I am hoping this will be the last submission. :)

Sorry, no. I can't review code that doesn't compile, so I'm only now
getting to some of the review.

> This is v2 of the squashed submission.  v1 had a small typo which
> prevented the BBT code from being truly configurable.  This has now
> been rectified and build tested with and without MTD_NAND_STM_BCH_BBT
> support.

>From smatch:

  drivers/mtd/nand/stm_nand_bch.c:1556 stm_nand_bch_probe() error: we 
previously assumed 'bank' could be null (see line 1482) [smatch]

>From GCC (extra warnings):

  drivers/mtd/nand/stm_nand_dt.c:39:21: warning: no previous prototype for 
'stm_of_get_partitions_node' [-Wmissing-prototypes]
  drivers/mtd/nand/stm_nand_dt.c:68:5: warning: no previous prototype for 
'stm_of_get_nand_banks' [-Wmissing-prototypes]

Looks like you forgot to include .

And your code is not bisectable. I think patch 7 and 8 should be
reordered (with some tweaks, perhaps):

Bisectability test results for configuration 
"arm-multi_v7_defconfig,arm,arm-unknown-linux-gnueabi-"

Failed to build patch #7: 5936df30f5e1 mtd: nand: stm_nand_bch: add support for 
ST's BCH NAND controller
Configuration: "arm-multi_v7_defconfig, architecture arm".


In file included from include/linux/ftrace.h:20:0,
 from include/linux/perf_event.h:47,
 from kernel/sys.c:16:
arch/arm/include/asm/ftrace.h:48:21: warning: no previous prototype for 
'return_address' [-Wmissing-prototypes]
In file included from include/linux/ftrace.h:20:0,
 from include/linux/perf_event.h:47,
 from include/linux/ftrace_event.h:9,
 from kernel/module.c:21:
arch/arm/include/asm/ftrace.h:48:21: warning: no previous prototype for 
'return_address' [-Wmissing-prototypes]
kernel/module.c: In function 'add_usage_links':
kernel/module.c:1512:6: warning: variable 'nowarn' set but not used 
[-Wunused-but-set-variable]
drivers/mtd/nand/stm_nand_bch.c:26:36: fatal error: linux/mtd/stm_nand_bbt.h: 
No such file or directory
compilation terminated.
make[4]: *** [drivers/mtd/nand/stm_nand_bch.o] Error 1

Brian
--
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/8] mtd: nand: Support for new DT NAND driver

[Brian Norris]

On Mon, Aug 18, 2014 at 09:39:53AM +0100, Lee Jones wrote:
> On Thu, 14 Aug 2014, Brian Norris wrote:
> > Particularly, take a hard look at rewriting
> > include/linux/mtd/stm_nand_bbt.h.
> 
> I don't think there is any need - although this change is required:
> 
> -#if defined(MTD_NAND_STM_BBT)
> +#if defined(MTD_NAND_STM_BCH_BBT)

You're still missing a GPL header and #include guards.

Your whole patch series (both v1 and v2) also has a few legit
checkpatch.pl warnings. Please fix these.

Brian
--
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/

[no subject]

[Charles Hjorth]

I have been ill and trying to reach you, this is my seventh time of
writing you
this email. My wife and I won a  Lottery of  $11.2 million in July and have
voluntarily decided to give the sum of  $1,000,000.00 USD to you as part
of our own charity project to improve the lot of 5 lucky individuals all
over the
world.

If you have received this email then you are one of the lucky recipients and
all you have to do is get back with us so that we can send your details to
the
payout bank.


Allen and Violet Large

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

fs: INFO: possible irq lock inversion dependency detected in kill_fasync

[Sasha Levin]

Hi all,

While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following spew:

[ 1132.334973] =
[ 1132.336095] [ INFO: possible irq lock inversion dependency detected ]
[ 1132.337056] 3.16.0-next-20140815-sasha-00034-g615561b #1071 Not tainted
[ 1132.337922] -
[ 1132.340751] trinity-main/8521 just changed the state of lock:
[ 1132.342015] (&(>fa_lock)->rlock){-.}, at: kill_fasync 
(fs/fcntl.c:717 fs/fcntl.c:737)
[ 1132.342761] but this lock took another, HARDIRQ-unsafe lock in the past:
[ 1132.342761]  (&(>alloc_lock)->rlock){+.+...}

and interrupts could create inverse lock ordering between them.

[ 1132.342761]
[ 1132.342761] other info that might help us debug this:
[ 1132.342761] Chain exists of:
&(>fa_lock)->rlock --> >f_owner.lock --> &(>alloc_lock)->rlock
[ 1132.334973] =
[ 1132.336095] [ INFO: possible irq lock inversion dependency detected ]
[ 1132.337056] 3.16.0-next-20140815-sasha-00034-g615561b #1071 Not tainted
[ 1132.337922] -
[ 1132.340751] trinity-main/8521 just changed the state of lock:
[ 1132.342015] (&(>fa_lock)->rlock){-.}, at: kill_fasync 
(fs/fcntl.c:717 fs/fcntl.c:737)
[ 1132.342761] but this lock took another, HARDIRQ-unsafe lock in the past:
[ 1132.342761]  (&(>alloc_lock)->rlock){+.+...}

and interrupts could create inverse lock ordering between them.

[ 1132.342761]
[ 1132.342761] other info that might help us debug this:
[ 1132.342761] Chain exists of:
&(>fa_lock)->rlock --> >f_owner.lock --> &(>alloc_lock)->rlock

[ 1132.342761]  Possible interrupt unsafe locking scenario:
[ 1132.342761]
[ 1132.342761]CPU0CPU1
[ 1132.342761]
[ 1132.342761]   lock(&(>alloc_lock)->rlock);
[ 1132.342761]local_irq_disable();
[ 1132.342761]lock(&(>fa_lock)->rlock);
[ 1132.342761]lock(>f_owner.lock);
[ 1132.342761]   
[ 1132.342761] lock(&(>fa_lock)->rlock);
[ 1132.342761]
[ 1132.342761]  *** DEADLOCK ***
[ 1132.342761]
[ 1132.342761] 1 lock held by trinity-main/8521:
[ 1132.342761] #0: (rcu_read_lock){..}, at: kill_fasync (fs/fcntl.c:731)
[ 1132.342761]
[ 1132.342761] the shortest dependencies between 2nd lock and 1st lock:
[ 1132.342761]-> (&(>alloc_lock)->rlock){+.+...} ops: 737341 {
[ 1132.342761]   HARDIRQ-ON-W at:
[ 1132.342761] __lock_acquire (kernel/locking/lockdep.c:2802 
kernel/locking/lockdep.c:3140)
[ 1132.342761] lock_acquire (./arch/x86/include/asm/current.h:14 
kernel/locking/lockdep.c:3610)
[ 1132.342761] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 
kernel/locking/spinlock.c:151)
[ 1132.342761] __set_task_comm (include/linux/spinlock.h:309 
include/linux/jump_label.h:114 include/trace/events/task.h:33 fs/exec.c:1048)
[ 1132.342761] kthreadd (kernel/kthread.c:489)
[ 1132.342761] ret_from_fork (arch/x86/kernel/entry_64.S:348)
[ 1132.342761]   SOFTIRQ-ON-W at:
[ 1132.342761] __lock_acquire (kernel/locking/lockdep.c:2806 
kernel/locking/lockdep.c:3140)
[ 1132.342761] lock_acquire (./arch/x86/include/asm/current.h:14 
kernel/locking/lockdep.c:3610)
[ 1132.342761] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 
kernel/locking/spinlock.c:151)
[ 1132.342761] __set_task_comm (include/linux/spinlock.h:309 
include/linux/jump_label.h:114 include/trace/events/task.h:33 fs/exec.c:1048)
[ 1132.342761] kthreadd (kernel/kthread.c:489)
[ 1132.342761] ret_from_fork (arch/x86/kernel/entry_64.S:348)
[ 1132.342761]   INITIAL USE at:
[ 1132.342761] __lock_acquire (kernel/locking/lockdep.c:3144)
[ 1132.342761] lock_acquire (./arch/x86/include/asm/current.h:14 
kernel/locking/lockdep.c:3610)
[ 1132.342761] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 
kernel/locking/spinlock.c:151)
[ 1132.342761] __set_task_comm (include/linux/spinlock.h:309 
include/linux/jump_label.h:114 include/trace/events/task.h:33 fs/exec.c:1048)
[ 1132.342761] kthreadd (kernel/kthread.c:489)
[ 1132.342761] ret_from_fork (arch/x86/kernel/entry_64.S:348)
[ 1132.342761] }
[ 1132.342761] ... key at: __key.51842 (??:?)
[ 1132.342761] ... acquired at:
[ 1132.342761] lock_acquire (./arch/x86/include/asm/current.h:14 
kernel/locking/lockdep.c:3610)
[ 1132.342761] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 
kernel/locking/spinlock.c:151)
[ 1132.342761] do_prlimit (kernel/sys.c:1386)
[ 1132.342761] SyS_getrlimit (kernel/sys.c:1276 kernel/sys.c:1270)
[ 1132.342761] tracesys (arch/x86/kernel/entry_64.S:541)
[ 1132.342761]
[ 1132.342761]   -> (tasklist_lock){.+.+..} ops: 42693178 {
[ 1132.342761]  HARDIRQ-ON-R at:
[ 1132.342761] __lock_acquire (kernel/locking/lockdep.c:2794 
kernel/locking/lockdep.c:3140)
[ 1132.342761] lock_acquire 

Re: [PATCH RESEND v2 0/7] vf610: Add USB support

[Peter Chen]

On Mon, Aug 18, 2014 at 10:07:10PM +0200, Stefan Agner wrote:
> This patchset adds USB support for Vybrid VF610 SoC. It extends the
> clock framework to support the USB PHY cocks, extends the device
> tree files and adds support for the non-core registers in the
> usbmisc_imx driver.
> 
> This patchset needs the eSDHC registers length fix available in
> Shawn's for-next branch, since that overlapped by chance the USB
> areas.
> 
> The whole patchset proved to be working on a Colibri VF61 and
> Freescale Tower VF65GS10. The first USB controller runs in
> peripheral mode. I could successfully use RNDIS, however with some
> stability issues: Suddenly the other side was not reachable anymore
> and the interface needed to brought down and back up again. I'm
> still investigating this.
> 
> The second USB controller, running in USB host mode, showed errors
> when connecting devices behind a USB hub:
> 
> [  215.163507] usb usb1-port1: cannot reset (err = -32)
> [  215.170498] usb usb1-port1: cannot reset (err = -32)
> [  215.185120] usb usb1-port1: cannot reset (err = -32)
> [  215.191345] usb usb1-port1: cannot reset (err = -32)
> [  215.202487] usb usb1-port1: cannot reset (err = -32)
> [  215.207718] usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
> [  215.219317] usb usb1-port1: unable to enumerate USB device
> 
> By extending the PHY driver with the MXS_PHY_NEED_IP_FIX flag, this
> issue is resolved.
> 
> Resend, also added Felipe Balbi this time, sorry about that. I think
> I only miss the Ack/Review from you here and then things should be
> fine.
> 
> Changes in v2:
> - Extended usbmisc_imx to support multiple instances
> - Update DT documentation and compatible strings where necessary
> - Add USB PHY flag MXS_PHY_NEED_IP_FIX
> - Added patches to enable USB on Tower
> 
> Stefan Agner (7):
>   ARM: dts: vf610: Add USB PHY and controller
>   ARM: imx: clk-vf610: Add USBPHY clocks
>   usb: phy: mxs: Add VF610 USB PHY support
>   ARM: dts: vf610: Add usbmisc for non-core registers
>   chipidea: usbmisc_imx: Add USB support for VF610 SoCs

This driver change is already at my tree, but it is too late
for 3.17-rc1 when you sent, so I sent it to greg for v3.18.

Peter

>   ARM: dts: vf610-colibri: Add USB support
>   ARM: dts: vf610-twr: Add USB support
> 
>  Documentation/devicetree/bindings/usb/mxs-phy.txt  |  1 +
>  .../devicetree/bindings/usb/usbmisc-imx.txt|  1 +
>  arch/arm/boot/dts/vf610-colibri.dts| 10 
>  arch/arm/boot/dts/vf610-twr.dts| 10 
>  arch/arm/boot/dts/vf610.dtsi   | 60 
> --
>  arch/arm/mach-imx/clk-vf610.c  | 12 -
>  drivers/usb/chipidea/ci_hdrc_imx.c |  8 +++
>  drivers/usb/chipidea/ci_hdrc_imx.h |  1 +
>  drivers/usb/chipidea/usbmisc_imx.c | 52 +++
>  drivers/usb/phy/phy-mxs-usb.c  |  6 +++
>  include/dt-bindings/clock/vf610-clock.h|  5 +-
>  11 files changed, 149 insertions(+), 17 deletions(-)
> 
> -- 
> 2.0.4
> 

-- 
Best Regards,
Peter Chen
--
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 v3] powerpc/perf: Implement get_cpu_str()

[Sukadev Bhattiprolu]

powerpc/perf: Implement get_cpu_str()

With a file ~/.cache/pmu-events/004d0100-core.json describing Power8
PMU events we would need to run:

perf stat \
--events-file ~/.cache/pmu-events/004d0100-core.json \
-e PM_CYC sleep 1

With this get_cpu_str(), On Powerpc, we can skip the --events-file option
and run:

perf stat -e PM_CYC sleep 1

Signed-off-by: Sukadev Bhattiprolu 
---
Changelog[v3]:
[Tobias Klauser]: Fix some changelog damage to patch.

Changelog[v2]:
[Michael Ellerman]: Use PVR instead of AUXV variables

 tools/perf/arch/powerpc/util/header.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/tools/perf/arch/powerpc/util/header.c 
b/tools/perf/arch/powerpc/util/header.c
index 6c1b8a7..306bf35 100644
--- a/tools/perf/arch/powerpc/util/header.c
+++ b/tools/perf/arch/powerpc/util/header.c
@@ -6,6 +6,7 @@
 
 #include "../../util/header.h"
 #include "../../util/util.h"
+#include "../../util/jevents.h"
 
 #define mfspr(rn)   ({unsigned long rval; \
 asm volatile("mfspr %0," __stringify(rn) \
@@ -32,3 +33,14 @@ get_cpuid(char *buffer, size_t sz)
}
return -1;
 }
+
+char *
+get_cpu_str(void)
+{
+   char *bufp;
+
+   if (asprintf(, "%.8lx-core", mfspr(SPRN_PVR)) < 0)
+   bufp = NULL;
+
+   return bufp;
+}
-- 
1.8.3.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 v8 01/11] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs

[Brian Norris]

Hi Russell,

On Wed, Aug 13, 2014 at 04:47:06PM -0700, Brian Norris wrote:
> Picking up this thread again, as things are now set for dropping this
> patch and resubmitting SMP support for 3.18.

Any further comment on this? I'd like to submit v10 of this patch soon.
As of now, my patch will still look essentially the same (with only
minor changes for some of the review comments), since I'm convinced
neither that my current per-cpu flag-based solution is unsound nor that
a delayed work queue can solve all of the same problems.

> On Sat, Aug 02, 2014 at 10:27:56AM +0100, Russell King wrote:
> > On Thu, Jul 31, 2014 at 03:06:42PM -0700, Brian Norris wrote:
> > > Yes, I noticed this. What I meant is that smp_ops.cpu_die() and
> > > smp_ops.cpu_kill() are not synchronized.
> > ...
> > > We're not relying on the L1 cache, though. Don't sync_cache_{r,w}()
> > > ensure all reads/writes reach at least the L2?
> > 
> > What exactly are you trying to achieve here?
> 
> Synchronization between v7_exit_coherency_flush() (on the dying CPU) and
> yanking the power (brcmstb_cpu_kill(), on the murderous CPU). The core
> completion-based synchronization is not sufficient, since it allows
> brcmstb_smp_ops.smp_kill and brcmstb_smp_ops.smp_die to race.
> 
> Am I somehow not achieving what I intend here?
> 
> > > How does that ensure that the CPU is down by the time the work is
> > > scheduled? It seems like this would just defer the work long enough that
> > > it *most likely* has quiesced, but I don't see how this gives us a
> > > better guarantee. Or maybe I'm missing something. (If so, please do
> > > enlighten!)
> > 
> > Note that I said a delayed work queue.  The dying CPU runs a predictable
> > sequence once cpu_die() has been entered - interrupts at the GIC have
> > been programmed to be routed to other CPUs, interrupts at the CPU are
> > masked, so the CPU isn't going to be doing anything else except executing
> > that code path.  So, it's going to be a predictable number of CPU cycles.
> > 
> > That allows you to arrange a delayed workqueue (or a timer) to fire
> > after a period of time that you can guarantee that the dying CPU has
> > reached that wfi().
> 
> OK, that sounds workable for the active hotplug case.
> 
> But what about for the suspend case? CPUs are hot-unplugged during
> disable_nonboot_cpus(), and I don't see that this would guarantee the
> workqueue will complete before we enter suspend.
> 
> > Another point which raises itself in your patch is this:
> > 
> > +   /* Settle-time from Broadcom-internal DVT reference code */
> > +   udelay(7);
> > 
[...]
> I'm looking into this specific delay. [...]

BTW, I think this delay can be dropped. It was retained from an early
non-production release of this CPU.

Brian
--
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/1] iommu/vt-d : clear old root entry for dump kernel

[Li, Zhen-Hua]

My debugging result is this: 

1. Clear the old root entry table, dump kernel will choose another
 memory region for root entry.
2. Do NOT clear the old root entry, when dump kernel initializing 
the iommu data structure, it  will allocate memory for root entry, 
this is different from the old address. 

If not clear old entry , the error message appears before dump kernel
finishes the iommu init works, and also appears in other places(before 
device inits). 

If I clear the old root entry, the error message disappears before iommu
init work finish, but still appears in other places. 

-Original Message-
From: Li, Zhen-Hua 
Sent: Tuesday, August 19, 2014 7:48 AM
To: Li, Zhen-Hua; Joerg Roedel
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

When the dump kernel boots, it will initialize iommu again, and the root entry 
will be allocted 
in another memory region.

That means, no matter kernel clears the old root entry table or not,  the dump 
kernel will use 
another memory region when iommu initializing.

-Original Message-
From: Li, Zhen-Hua 
Sent: Tuesday, August 19, 2014 7:27 AM
To: 'Joerg Roedel'
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

: [fault reason 01] Present bit in root entry is clear
It appears when iommu initializing in the kdump kernel.

-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org] 
Sent: Tuesday, August 19, 2014 7:23 AM
To: Li, Zhen-Hua
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

On Mon, Aug 18, 2014 at 11:01:56PM +, Li, Zhen-Hua wrote:
> There is a bug when Linux running on an HP large system: 
>   when kdump kernel runs, the hardware is still using the old 
> root entry. This causes error message when iommu not finished initialization.

What error message are you seeing? When the kdump kernel boots the iommu
should be still enabled from the old kernel with the old root-entry. So
any in-flight DMA initiated from the old kernel can still pass and there
should be no error messages.

When you clear the root-entry that in-flight DMA might go to another
random location in system memory or just fail, no?


Joerg

--
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/1] iommu/vt-d : clear old root entry for dump kernel

[Li, Zhen-Hua]

When the dump kernel boots, it will initialize iommu again, and the root entry 
will be allocted 
in another memory region.

That means, no matter kernel clears the old root entry table or not,  the dump 
kernel will use 
another memory region when iommu initializing.

-Original Message-
From: Li, Zhen-Hua 
Sent: Tuesday, August 19, 2014 7:27 AM
To: 'Joerg Roedel'
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

: [fault reason 01] Present bit in root entry is clear
It appears when iommu initializing in the kdump kernel.

-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org] 
Sent: Tuesday, August 19, 2014 7:23 AM
To: Li, Zhen-Hua
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

On Mon, Aug 18, 2014 at 11:01:56PM +, Li, Zhen-Hua wrote:
> There is a bug when Linux running on an HP large system: 
>   when kdump kernel runs, the hardware is still using the old 
> root entry. This causes error message when iommu not finished initialization.

What error message are you seeing? When the kdump kernel boots the iommu
should be still enabled from the old kernel with the old root-entry. So
any in-flight DMA initiated from the old kernel can still pass and there
should be no error messages.

When you clear the root-entry that in-flight DMA might go to another
random location in system memory or just fail, no?


Joerg

--
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: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()

[Julian Calaby]

Hi All,

On Tue, Aug 19, 2014 at 3:35 AM, Aaro Koskinen  wrote:
> Hi,
>
> On Mon, Aug 18, 2014 at 03:30:16PM +0300, Meelis Roos wrote:
>> > U1, U2, U5, U10, E220R, E420R later or some other day, whenever I get
>> > to them physically.
>>
>> Ultra 5 is bad news with 3.17-rc1: it almost boots up, then aftyer
>> strarting postfix and ntpd, gets RED state exception and contiunes
>> looping with it (before it gor RED state only after prom reboot).
>
> My Ultra 5 is fine with 3.17-rc1 (I'm writing this mail from it),
> also Ultra 10 seems to be OK based on quick test.

Stupid question: aren't the Ultra 5 and Ultra 10 essentially the same hardware?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
--
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 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

[Joerg Roedel]

On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote:
>  .../devicetree/bindings/iommu/samsung,sysmmu.txt   |  93 ++-
>  Documentation/power/notifiers.txt  |  14 +
>  arch/arm/boot/dts/exynos4.dtsi | 118 
>  arch/arm/boot/dts/exynos4210.dtsi  |  23 +
>  arch/arm/boot/dts/exynos4x12.dtsi  |  82 +++
>  arch/arm/include/asm/dma-iommu.h   |  36 ++
>  arch/arm/mach-exynos/pm_domains.c  |  12 +-
>  arch/arm/mach-integrator/impd1.c   |   2 +-
>  arch/arm/mm/dma-mapping.c  |  47 ++
>  drivers/base/bus.c |   4 +-
>  drivers/base/dd.c  |  10 +-
>  drivers/base/platform.c|   2 +-
>  drivers/base/power/domain.c|  70 ++-
>  drivers/clk/samsung/clk-exynos4.c  |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c   |   1 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  26 +-
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c|   1 +
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c|   1 +
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c|   1 +
>  drivers/gpu/drm/exynos/exynos_mixer.c  |   1 +
>  drivers/iommu/exynos-iommu.c   | 663 
> +
>  drivers/iommu/iommu.c  |   3 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   | 107 ++--
>  drivers/pci/host/pci-mvebu.c   |   2 +-
>  drivers/pci/host/pci-rcar-gen2.c   |   2 +-
>  drivers/pci/host/pci-tegra.c   |   2 +-
>  drivers/pci/host/pcie-rcar.c   |   2 +-
>  drivers/soc/tegra/pmc.c|   2 +-
>  include/dt-bindings/clock/exynos4.h|  10 +-
>  include/linux/device.h |  12 +-
>  include/linux/iommu.h  |   1 +
>  include/linux/pm.h |   2 +
>  include/linux/pm_domain.h  |  19 +
>  33 files changed, 1016 insertions(+), 356 deletions(-)

This touches a lot of non-iommu stuff. What is your strategy on getting
this in, do you plan to get the non-iommu changes merged first or do you
want to collect the respective Acks and merge this all through one tree?


Joerg

--
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 V1 00/30] Enable memoryless node on x86 platforms

[Nishanth Aravamudan]

Hi Gerry,

On 25.07.2014 [09:50:01 +0800], Jiang Liu wrote:
> 
> 
> On 2014/7/25 7:32, Nishanth Aravamudan wrote:
> > On 23.07.2014 [16:20:24 +0800], Jiang Liu wrote:
> >>
> >>
> >> On 2014/7/22 1:57, Nishanth Aravamudan wrote:
> >>> On 21.07.2014 [10:41:59 -0700], Tony Luck wrote:
>  On Mon, Jul 21, 2014 at 10:23 AM, Nishanth Aravamudan
>   wrote:
> > It seems like the issue is the order of onlining of resources on a
> > specific x86 platform?
> 
>  Yes. When we online a node the BIOS hits us with some ACPI hotplug 
>  events:
> 
>  First: Here are some new cpus
> >>>
> >>> Ok, so during this period, you might get some remote allocations. Do you
> >>> know the topology of these CPUs? That is they belong to a
> >>> (soon-to-exist) NUMA node? Can you online that currently offline NUMA
> >>> node at this point (so that NODE_DATA()) resolves, etc.)?
> >> Hi Nishanth,
> >>We have method to get the NUMA information about the CPU, and
> >> patch "[RFC Patch V1 30/30] x86, NUMA: Online node earlier when doing
> >> CPU hot-addition" tries to solve this issue by onlining NUMA node
> >> as early as possible. Actually we are trying to enable memoryless node
> >> as you have suggested.
> > 
> > Ok, it seems like you have two sets of patches then? One is to fix the
> > NUMA information timing (30/30 only). The rest of the patches are
> > general discussions about where cpu_to_mem() might be used instead of
> > cpu_to_node(). However, based upon Tejun's feedback, it seems like
> > rather than force all callers to use cpu_to_mem(), we should be looking
> > at the core VM to ensure fallback is occuring appropriately when
> > memoryless nodes are present. 
> > 
> > Do you have a specific situation, once you've applied 30/30, where
> > kmalloc_node() leads to an Oops?
> Hi Nishanth,
>   After following the two threads related to support of memoryless
> node and digging more code, I realized my first version path set is an
> overkill. As Tejun has pointed out, we shouldn't expose the detail of
> memoryless node to normal user, but there are still some special users
> who need the detail. So I have tried to summarize it as:
> 1) Arch code should online corresponding NUMA node before onlining any
>CPU or memory, otherwise it may cause invalid memory access when
>accessing NODE_DATA(nid).

I think that's reasonable.

A related caveat is that NUMA topology information should be stored as
early as possible in boot for *all* CPUs [I think only cpu_to_* is used,
at least for now], not just the boot CPU, etc. This is because (at least
on my examination) pre-SMP initcalls are not prevented from using
cpu_to_node, which will falsely return 0 for all CPUs until
set_cpu_numa_node() is called.

> 2) For normal memory allocations without __GFP_THISNODE setting in the
>gfp_flags, we should prefer numa_node_id()/cpu_to_node() instead of
>numa_mem_id()/cpu_to_mem() because the latter loses hardware topology
>information as pointed out by Tejun:
>A - B - X - C - D
> Where X is the memless node.  numa_mem_id() on X would return
> either B or C, right?  If B or C can't satisfy the allocation,
> the allocator would fallback to A from B and D for C, both of
> which aren't optimal. It should first fall back to C or B
> respectively, which the allocator can't do anymoe because the
> information is lost when the caller side performs numa_mem_id().

Yes, this seems like a very good description of the reasoning.

> 3) For memory allocation with __GFP_THISNODE setting in gfp_flags,
>numa_node_id()/cpu_to_node() should be used if caller only wants to
>allocate from local memory, otherwise numa_mem_id()/cpu_to_mem()
>should be used if caller wants to allocate from the nearest node.
>
> 4) numa_mem_id()/cpu_to_mem() should be used if caller wants to check
>whether a page is allocated from the nearest node.

I'm less clear on what you mean here, I'll look at your v2 patches. I
mean, numa_node_id()/cpu_to_node() should be used to indicate node-local
preference with appropriate failure handling. But I don't know why one
would prefer to use numa_node_id() to numa_mem_id() in such a path? The
only time they differ is if memoryless nodes are present, which is what
your local memory allocation would ideally be for those nodes anyways?

Thanks,
Nish

--
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] powerpc/perf: Implement get_cpu_str()

[Sukadev Bhattiprolu]

Tobias Klauser [tklau...@distanz.ch] wrote:
| > diff --git a/tools/perf/arch/powerpc/util/header.c 
b/tools/perf/arch/powerpc/util/header.c
| > index 6c1b8a7..1bb400e8 100644
| > --- a/tools/perf/arch/powerpc/util/header.c
| > +++ b/tools/perf/arch/powerpc/util/header.c
| > @@ -6,6 +6,7 @@
| >  
| >  #include "../../util/header.h"
| >  #include "../../util/util.h"
| > +#include "../../util/jevents.h"
| >  
| >  #define mfspr(rn)   ({unsigned long rval; \
| >  asm volatile("mfspr %0," __stringify(rn) \
| > @@ -32,3 +33,14 @@ get_cpuid(char *buffer, size_t sz)
| > }
| > return -1;
| >  }
| > +
| > +char *
| > +get_cpu_str(void)
| > +{
| > Changelog[v2]:
| > [Michael Ellerman]: Use PVR instead of AUXV variables
| 
| This was probably not intended to be here and the patch does not apply
| due to these lines.

Sorry about that. Will resend.

Sukadev

--
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/1] iommu/vt-d : clear old root entry for dump kernel

[Li, Zhen-Hua]

: [fault reason 01] Present bit in root entry is clear
It appears when iommu initializing in the kdump kernel.

-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org] 
Sent: Tuesday, August 19, 2014 7:23 AM
To: Li, Zhen-Hua
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

On Mon, Aug 18, 2014 at 11:01:56PM +, Li, Zhen-Hua wrote:
> There is a bug when Linux running on an HP large system: 
>   when kdump kernel runs, the hardware is still using the old 
> root entry. This causes error message when iommu not finished initialization.

What error message are you seeing? When the kdump kernel boots the iommu
should be still enabled from the old kernel with the old root-entry. So
any in-flight DMA initiated from the old kernel can still pass and there
should be no error messages.

When you clear the root-entry that in-flight DMA might go to another
random location in system memory or just fail, no?


Joerg

--
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/1] iommu/vt-d : clear old root entry for dump kernel

[Joerg Roedel]

On Mon, Aug 18, 2014 at 11:01:56PM +, Li, Zhen-Hua wrote:
> There is a bug when Linux running on an HP large system: 
>   when kdump kernel runs, the hardware is still using the old 
> root entry. This causes error message when iommu not finished initialization.

What error message are you seeing? When the kdump kernel boots the iommu
should be still enabled from the old kernel with the old root-entry. So
any in-flight DMA initiated from the old kernel can still pass and there
should be no error messages.

When you clear the root-entry that in-flight DMA might go to another
random location in system memory or just fail, no?


Joerg

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

i8k: Don't revert affinity in i8k_smm

[Con Kolivas]

As a followup to this discussion:

On Tue, 15 Jul 2014 08:01:13 PM Sam Asadi wrote:
> Commit f36fdb9f0266 (i8k: Force SMM to run on CPU 0) adds support
> for multi-core CPUs to the driver. Unfortunately, that causes it
> to fail loading if compiled without SMP support, at least on
> 32 bit kernels. Kernel log shows "i8k: unable to get SMM Dell
> signature", and function i8k_smm is found to return -EINVAL.
> 
> Testing revealed that the culprit is the missing return value check
> of set_cpus_allowed_ptr.

It appears that the original commit f36fdb9f0266 changes the affinity for the 
duration of i8k_smm function and then unconditionally reverts the affinity to 
the old cpu mask regardless of whether the function succeeds or fails. As this 
must run on CPU 0 at all times it does not make sense to revert the affinity at 
the end of the function. Proposed patch attached.

Signed-off-by: Con Kolivas 

---
 drivers/char/i8k.c |6 --
 1 file changed, 6 deletions(-)

Index: linux-3.16-ck1/drivers/char/i8k.c
===
--- linux-3.16-ck1.orig/drivers/char/i8k.c  2014-08-12 14:07:49.0 
+1000
+++ linux-3.16-ck1/drivers/char/i8k.c   2014-08-19 09:09:57.939056696 +1000
@@ -132,12 +132,8 @@ static int i8k_smm(struct smm_regs *regs
 {
int rc;
int eax = regs->eax;
-   cpumask_var_t old_mask;
 
/* SMM requires CPU 0 */
-   if (!alloc_cpumask_var(_mask, GFP_KERNEL))
-   return -ENOMEM;
-   cpumask_copy(old_mask, >cpus_allowed);
rc = set_cpus_allowed_ptr(current, cpumask_of(0));
if (rc)
goto out;
@@ -203,8 +199,6 @@ static int i8k_smm(struct smm_regs *regs
rc = -EINVAL;
 
 out:
-   set_cpus_allowed_ptr(current, old_mask);
-   free_cpumask_var(old_mask);
return rc;
 }
 

-- 
-ck
--
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] cnic: Replace rcu_dereference() with rcu_access_pointer()

[Michael Chan]

On Sun, 2014-08-17 at 13:12 +0300, Andreea-Cristina Bernat wrote: 
> The "rcu_dereference()" calls are used directly in conditions.
> Since their return values are never dereferenced it is recommended to use
> "rcu_access_pointer()" instead of "rcu_dereference()".
> Therefore, this patch makes the replacements.
> 
> The following Coccinelle semantic patch was used:
> @@
> @@
> 
> (
>  if(
>  (<+...
> - rcu_dereference
> + rcu_access_pointer
>   (...)
>   ...+>)) {...}
> |
>  while(
>  (<+...
> - rcu_dereference
> + rcu_access_pointer
>   (...)
>   ...+>)) {...}
> )
> 
> Signed-off-by: Andreea-Cristina Bernat 

Acked-by: Michael Chan 

> ---
> v2: Modified subject line from
>  "rcu: Replace rcu_dereference() with rcu_access_pointer()"
>  to
>  "cnic: Replace rcu_dereference() with rcu_access_pointer()",
>  noted by David Miller 
> 
>  drivers/net/ethernet/broadcom/cnic.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/broadcom/cnic.c 
> b/drivers/net/ethernet/broadcom/cnic.c
> index 8244e2b..dad9cb7 100644
> --- a/drivers/net/ethernet/broadcom/cnic.c
> +++ b/drivers/net/ethernet/broadcom/cnic.c
> @@ -381,7 +381,7 @@ static int cnic_iscsi_nl_msg_recv(struct cnic_dev *dev, 
> u32 msg_type,
>   break;
>  
>   rcu_read_lock();
> - if (!rcu_dereference(cp->ulp_ops[CNIC_ULP_L4])) {
> + if (!rcu_access_pointer(cp->ulp_ops[CNIC_ULP_L4])) {
>   rc = -ENODEV;
>   rcu_read_unlock();
>   break;
> @@ -525,7 +525,7 @@ int cnic_unregister_driver(int ulp_type)
>   list_for_each_entry(dev, _dev_list, list) {
>   struct cnic_local *cp = dev->cnic_priv;
>  
> - if (rcu_dereference(cp->ulp_ops[ulp_type])) {
> + if (rcu_access_pointer(cp->ulp_ops[ulp_type])) {
>   pr_err("%s: Type %d still has devices registered\n",
>  __func__, ulp_type);
>   read_unlock(_dev_lock);
> @@ -573,7 +573,7 @@ static int cnic_register_device(struct cnic_dev *dev, int 
> ulp_type,
>   mutex_unlock(_lock);
>   return -EAGAIN;
>   }
> - if (rcu_dereference(cp->ulp_ops[ulp_type])) {
> + if (rcu_access_pointer(cp->ulp_ops[ulp_type])) {
>   pr_err("%s: Type %d has already been registered to this 
> device\n",
>  __func__, ulp_type);
>   mutex_unlock(_lock);


--
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/1] iommu/vt-d : clear old root entry for dump kernel

[Li, Zhen-Hua]

There is a bug when Linux running on an HP large system: 
when kdump kernel runs, the hardware is still using the old 
root entry. This causes error message when iommu not finished initialization.

-Original Message-
From: Li, Zhen-Hua 
Sent: Monday, August 18, 2014 4:59 PM
To: David Woodhouse; Joerg Roedel; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Cc: Li, Zhen-Hua
Subject: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

If intel_iommu is enabled, when kdump kernel boots, the old root entry
 should be cleared, otherwise it may cause DMAR error.

To make it works for more enviroments, this patch does not use 
is_kdump_kernel() to check it,  but reads the register to check whether 
hardware is using old root entry.

Signed-off-by: Li, Zhen-Hua 
---
 drivers/iommu/dmar.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 60ab474..7b4fa90 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -66,6 +66,8 @@ static int dmar_dev_scope_status = 1;
 static int alloc_iommu(struct dmar_drhd_unit *drhd);
 static void free_iommu(struct intel_iommu *iommu);
 
+static int iommu_check_root_entry(struct intel_iommu *iommu);
+
 static void __init dmar_register_drhd_unit(struct dmar_drhd_unit *drhd)
 {
/*
@@ -987,6 +989,8 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
   intel_iommu_groups,
   iommu->name);
 
+   iommu_check_root_entry(iommu);
+
return 0;
 
  err_unmap:
@@ -1666,5 +1670,32 @@ static int __init dmar_free_unused_resources(void)
return 0;
 }
 
+static int iommu_check_root_entry(struct intel_iommu *iommu)
+{
+   u64 re_pa;
+
+   re_pa = dmar_readq(iommu->reg + DMAR_RTADDR_REG);
+
+   /* This only works for hardware error and kdump kernel */
+   if (unlikely(re_pa != 0)) {
+   u32 sts;
+   unsigned long flag;
+
+   raw_spin_lock_irqsave(>register_lock, flag);
+   dmar_writeq(iommu->reg + DMAR_RTADDR_REG, 0);
+
+   writel(iommu->gcmd | DMA_GCMD_SRTP, iommu->reg + DMAR_GCMD_REG);
+
+   /* Make sure hardware complete it */
+   IOMMU_WAIT_OP(iommu, DMAR_GSTS_REG,
+ readl, (sts & DMA_GSTS_RTPS), sts);
+
+   raw_spin_unlock_irqrestore(>register_lock, flag);
+
+   }
+
+   return 0;
+}
+
 late_initcall(dmar_free_unused_resources);
 IOMMU_INIT_POST(detect_intel_iommu);
-- 
2.0.0-rc0

--
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] usb: misc: yurex: remove useless casting of private_data

[Arjun Sreedharan]

Signed-off-by: Arjun Sreedharan 
---
 drivers/usb/misc/yurex.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/misc/yurex.c b/drivers/usb/misc/yurex.c
index 1472805..c3a45da 100644
--- a/drivers/usb/misc/yurex.c
+++ b/drivers/usb/misc/yurex.c
@@ -358,7 +358,7 @@ static int yurex_fasync(int fd, struct file *file, int on)
 {
struct usb_yurex *dev;
 
-   dev = (struct usb_yurex *)file->private_data;
+   dev = file->private_data;
return fasync_helper(fd, file, on, >async_queue);
 }
 
@@ -401,7 +401,7 @@ static int yurex_release(struct inode *inode, struct file 
*file)
 {
struct usb_yurex *dev;
 
-   dev = (struct usb_yurex *)file->private_data;
+   dev = file->private_data;
if (dev == NULL)
return -ENODEV;
 
@@ -418,7 +418,7 @@ static ssize_t yurex_read(struct file *file, char *buffer, 
size_t count, loff_t
char in_buffer[20];
unsigned long flags;
 
-   dev = (struct usb_yurex *)file->private_data;
+   dev = file->private_data;
 
mutex_lock(>io_mutex);
if (!dev->interface) {  /* already disconnected */
@@ -455,7 +455,7 @@ static ssize_t yurex_write(struct file *file, const char 
*user_buffer, size_t co
DEFINE_WAIT(wait);
 
count = min(sizeof(buffer), count);
-   dev = (struct usb_yurex *)file->private_data;
+   dev = file->private_data;
 
/* verify that we actually have some data to write */
if (count == 0)
-- 
1.8.1.msysgit.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 2/3] iommu/amd: Fix cleanup_domain for mass device removal

[Joerg Roedel]

From: Joerg Roedel 

When multiple devices are detached in __detach_device, they
are also removed from the domains dev_list. This makes it
unsafe to use list_for_each_entry_safe, as the next pointer
might also not be in the list anymore after __detach_device
returns. So just repeatedly remove the first element of the
list until it is empty.

Cc: sta...@vger.kernel.org
Tested-by: Marti Raudsepp 
Signed-off-by: Joerg Roedel 
---
 drivers/iommu/amd_iommu.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 1840531..ecb0109 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -3149,14 +3149,16 @@ free_domains:
 
 static void cleanup_domain(struct protection_domain *domain)
 {
-   struct iommu_dev_data *dev_data, *next;
+   struct iommu_dev_data *entry;
unsigned long flags;
 
write_lock_irqsave(_iommu_devtable_lock, flags);
 
-   list_for_each_entry_safe(dev_data, next, >dev_list, list) {
-   __detach_device(dev_data);
-   atomic_set(_data->bind, 0);
+   while (!list_empty(>dev_list)) {
+   entry = list_first_entry(>dev_list,
+struct iommu_dev_data, list);
+   __detach_device(entry);
+   atomic_set(>bind, 0);
}
 
write_unlock_irqrestore(_iommu_devtable_lock, flags);
-- 
1.9.1

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

[PATCH 3/3] iommu/core: Check for the right function pointer in iommu_map()

[Joerg Roedel]

From: Joerg Roedel 

Check for the ->map and not the ->unmap pointer.

Signed-off-by: Joerg Roedel 
---
 drivers/iommu/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 1698360..ac4adb3 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -995,7 +995,7 @@ int iommu_map(struct iommu_domain *domain, unsigned long 
iova,
size_t orig_size = size;
int ret = 0;
 
-   if (unlikely(domain->ops->unmap == NULL ||
+   if (unlikely(domain->ops->map == NULL ||
 domain->ops->pgsize_bitmap == 0UL))
return -ENODEV;
 
-- 
1.9.1

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

Re: [PATCH v12] NVMe: Convert to blk-mq

[Keith Busch]

On Fri, 15 Aug 2014, Matias Bjørling wrote:


* NVMe queues are merged with the tags structure of blk-mq.



I see the driver's queue suspend logic is removed, but I didn't mean to
imply it was safe to do so without replacing it with something else. I
thought maybe we could use the blk_stop/start_queue() functions if I'm
correctly understanding what they're for.

With what's in version 12, we could free an irq multiple times that
doesn't even belong to the nvme queue anymore in certain error conditions.

A couple other things I just noticed:

 * We lose the irq affinity hint after a suspend/resume or device reset
 because the driver's init_hctx() isn't called in these scenarios.

 * After a reset, we are not guaranteed that we even have the same number
 of h/w queues. The driver frees ones beyond the device's capabilities,
 so blk-mq may have references to freed memory. The driver may also
 allocate more queues if it is capable, but blk-mq won't be able to take
 advantage of that.

[PATCH 0/3] IOMMU Fixes

[Joerg Roedel]

Hi,

here are a few fixes for the x86 iommu drivers and a small
one for the iommu core-code I plan to send for -rc2.


Joerg

Joerg Roedel (3):
  iommu/vt-d: Defer domain removal if device is assigned to a driver
  iommu/amd: Fix cleanup_domain for mass device removal
  iommu/core: Check for the right function pointer in iommu_map()

 drivers/iommu/amd_iommu.c   | 10 ++
 drivers/iommu/intel-iommu.c |  8 
 drivers/iommu/iommu.c   |  2 +-
 3 files changed, 15 insertions(+), 5 deletions(-)

-- 
1.9.1

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

[PATCH 1/3] iommu/vt-d: Defer domain removal if device is assigned to a driver

[Joerg Roedel]

From: Joerg Roedel 

When the BUS_NOTIFY_DEL_DEVICE event is received the device
might still be attached to a driver. In this case the domain
can't be released as the mappings might still be in use.

Defer the domain removal in this case until we receivce the
BUS_NOTIFY_UNBOUND_DRIVER event.

Cc: Jiang Liu 
Cc: David Woodhouse 
Cc: sta...@vger.kernel.org   # v3.15, v3.16
Signed-off-by: Joerg Roedel 
---
 drivers/iommu/intel-iommu.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d1f5caa..5619f26 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3869,6 +3869,14 @@ static int device_notifier(struct notifier_block *nb,
action != BUS_NOTIFY_DEL_DEVICE)
return 0;
 
+   /*
+* If the device is still attached to a device driver we can't
+* tear down the domain yet as DMA mappings may still be in use.
+* Wait for the BUS_NOTIFY_UNBOUND_DRIVER event to do that.
+*/
+   if (action == BUS_NOTIFY_DEL_DEVICE && dev->driver != NULL)
+   return 0;
+
domain = find_domain(dev);
if (!domain)
return 0;
-- 
1.9.1

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

Re: [PATCH 2/7] locking/rwsem: more aggressive use of optimistic spinning

[Waiman Long]

On 08/17/2014 07:41 PM, Dave Chinner wrote:

On Fri, Aug 15, 2014 at 01:58:09PM -0400, Waiman Long wrote:

On 08/14/2014 11:34 PM, Dave Chinner wrote:


xfs_io -f -c "truncate 500t" -c "extsize 1m" /path/to/vm/image/file



Thank for the testing recipe. I am afraid that I can't find a 500TB
SSD for testing purpose.

Which bit of "sparse vm image file" didn't you understand?  I'm
using a 400GB of SSD for this testing

$ df -h /mnt/fast-ssd
Filesystem  Size  Used Avail Use% Mounted on
/dev/sdf400G  275G  125G  69% /mnt/fast-ssd
$ ls -lh /mnt/fast-ssd/vm-500t.img
-rw--- 1 root root 500T Aug 15 13:21 /mnt/fast-ssd/vm-500t.img
$ du -sh /mnt/fast-ssd/vm-500t.img
275G/mnt/fast-ssd/vm-500t.img

That is on a Samsung 840 EVO SSD, which just about everyone should
be able to obtain. Do you *really* think I have 500TB of SSDs lying
around?

Cheers,

Dave.


I am sorry that I misunderstood your instruction. I am not a filesystem 
guy and haven't run this kind of test before.


Thank for the clarification.

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

[PATCH 2/2] kvm: x86: fix stale mmio cache bug

[David Matlack]

The following events can lead to an incorrect KVM_EXIT_MMIO bubbling
up to userspace:

(1) Guest accesses gpa X without a memory slot. The gfn is cached in
struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets
the SPTE write-execute-noread so that future accesses cause
EPT_MISCONFIGs.

(2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION
covering the page just accessed.

(3) Guest attempts to read or write to gpa X again. On Intel, this
generates an EPT_MISCONFIG. The memory slot generation number that
was incremented in (2) would normally take care of this but we fast
path mmio faults through quickly_check_mmio_pf(), which only checks
the per-vcpu mmio cache. Since we hit the cache, KVM passes a
KVM_EXIT_MMIO up to userspace.

This patch fixes the issue by using the memslot generation number
to validate the mmio cache.

[ xiaoguangrong: adjust the code to make it simpler for stable-tree fix. ]

Cc: sta...@vger.kernel.org
Signed-off-by: David Matlack 
Signed-off-by: Xiao Guangrong 
---
 arch/x86/include/asm/kvm_host.h |  1 +
 arch/x86/kvm/mmu.c  |  4 ++--
 arch/x86/kvm/mmu.h  |  2 ++
 arch/x86/kvm/x86.h  | 21 -
 4 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 49205d0..f518d14 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -479,6 +479,7 @@ struct kvm_vcpu_arch {
u64 mmio_gva;
unsigned access;
gfn_t mmio_gfn;
+   unsigned int mmio_gen;
 
struct kvm_pmu pmu;
 
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 9314678..e00fbfe 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -234,7 +234,7 @@ static unsigned int get_mmio_spte_generation(u64 spte)
return gen;
 }
 
-static unsigned int kvm_current_mmio_generation(struct kvm *kvm)
+unsigned int kvm_current_mmio_generation(struct kvm *kvm)
 {
/*
 * Init kvm generation close to MMIO_MAX_GEN to easily test the
@@ -3163,7 +3163,7 @@ static void mmu_sync_roots(struct kvm_vcpu *vcpu)
if (!VALID_PAGE(vcpu->arch.mmu.root_hpa))
return;
 
-   vcpu_clear_mmio_info(vcpu, ~0ul);
+   vcpu_clear_mmio_info(vcpu, MMIO_GVA_ANY);
kvm_mmu_audit(vcpu, AUDIT_PRE_SYNC);
if (vcpu->arch.mmu.root_level == PT64_ROOT_LEVEL) {
hpa_t root = vcpu->arch.mmu.root_hpa;
diff --git a/arch/x86/kvm/mmu.h b/arch/x86/kvm/mmu.h
index b982112..e2d902a 100644
--- a/arch/x86/kvm/mmu.h
+++ b/arch/x86/kvm/mmu.h
@@ -76,6 +76,8 @@ enum {
 };
 
 int handle_mmio_page_fault_common(struct kvm_vcpu *vcpu, u64 addr, bool 
direct);
+unsigned int kvm_current_mmio_generation(struct kvm *kvm);
+
 void kvm_init_shadow_mmu(struct kvm_vcpu *vcpu, struct kvm_mmu *context);
 void kvm_init_shadow_ept_mmu(struct kvm_vcpu *vcpu, struct kvm_mmu *context,
bool execonly);
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index 8c97bac..ae7006d 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -3,6 +3,7 @@
 
 #include 
 #include "kvm_cache_regs.h"
+#include "mmu.h"
 
 static inline void kvm_clear_exception_queue(struct kvm_vcpu *vcpu)
 {
@@ -78,15 +79,23 @@ static inline void vcpu_cache_mmio_info(struct kvm_vcpu 
*vcpu,
vcpu->arch.mmio_gva = gva & PAGE_MASK;
vcpu->arch.access = access;
vcpu->arch.mmio_gfn = gfn;
+   vcpu->arch.mmio_gen = kvm_current_mmio_generation(vcpu->kvm);
+}
+
+static inline bool vcpu_match_mmio_gen(struct kvm_vcpu *vcpu)
+{
+   return vcpu->arch.mmio_gen == kvm_current_mmio_generation(vcpu->kvm);
 }
 
 /*
- * Clear the mmio cache info for the given gva,
- * specially, if gva is ~0ul, we clear all mmio cache info.
+ * Clear the mmio cache info for the given gva. If gva is MMIO_GVA_ANY, we
+ * clear all mmio cache info.
  */
+#define MMIO_GVA_ANY (~(gva_t)0)
+
 static inline void vcpu_clear_mmio_info(struct kvm_vcpu *vcpu, gva_t gva)
 {
-   if (gva != (~0ul) && vcpu->arch.mmio_gva != (gva & PAGE_MASK))
+   if (gva != MMIO_GVA_ANY && vcpu->arch.mmio_gva != (gva & PAGE_MASK))
return;
 
vcpu->arch.mmio_gva = 0;
@@ -94,7 +103,8 @@ static inline void vcpu_clear_mmio_info(struct kvm_vcpu 
*vcpu, gva_t gva)
 
 static inline bool vcpu_match_mmio_gva(struct kvm_vcpu *vcpu, unsigned long 
gva)
 {
-   if (vcpu->arch.mmio_gva && vcpu->arch.mmio_gva == (gva & PAGE_MASK))
+   if (vcpu_match_mmio_gen(vcpu) && vcpu->arch.mmio_gva &&
+ vcpu->arch.mmio_gva == (gva & PAGE_MASK))
return true;
 
return false;
@@ -102,7 +112,8 @@ static inline bool vcpu_match_mmio_gva(struct kvm_vcpu 
*vcpu, unsigned long gva)
 
 static inline bool vcpu_match_mmio_gpa(struct kvm_vcpu *vcpu, gpa_t gpa)
 {
-   if (vcpu->arch.mmio_gfn && vcpu->arch.mmio_gfn == gpa >> PAGE_SHIFT)
+   if (vcpu_match_mmio_gen(vcpu) && vcpu->arch.mmio_gfn &&
+ 

[PATCH 1/2] kvm: fix potentially corrupt mmio cache

[David Matlack]

vcpu exits and memslot mutations can run concurrently as long as the
vcpu does not aquire the slots mutex. Thus it is theoretically possible
for memslots to change underneath a vcpu that is handling an exit.

If we increment the memslot generation number again after
synchronize_srcu_expedited(), vcpus can safely cache memslot generation
without maintaining a single rcu_dereference through an entire vm exit.
And much of the x86/kvm code does not maintain a single rcu_dereference
of the current memslots during each exit.

We can prevent the following case:

   vcpu (CPU 0) | thread (CPU 1)
+--
1  vm exit  |
2  decide to cache something based on   |
 old memslots   |
3   | change memslots
4   | increment generation
5  tag cache with new memslot generation|
... |
   |
... |
  |

By incrementing the generation again after synchronizing kvm->srcu
readers, we guarantee the generation cached in (5) will very soon
become invalid.

Cc: sta...@vger.kernel.org
Cc: Xiao Guangrong 
Signed-off-by: David Matlack 
---
 virt/kvm/kvm_main.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 4b6c01b..86d3697 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -95,8 +95,6 @@ static int hardware_enable_all(void);
 static void hardware_disable_all(void);
 
 static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
-static void update_memslots(struct kvm_memslots *slots,
-   struct kvm_memory_slot *new, u64 last_generation);
 
 static void kvm_release_pfn_dirty(pfn_t pfn);
 static void mark_page_dirty_in_slot(struct kvm *kvm,
@@ -685,8 +683,7 @@ static void sort_memslots(struct kvm_memslots *slots)
 }
 
 static void update_memslots(struct kvm_memslots *slots,
-   struct kvm_memory_slot *new,
-   u64 last_generation)
+   struct kvm_memory_slot *new)
 {
if (new) {
int id = new->id;
@@ -697,8 +694,6 @@ static void update_memslots(struct kvm_memslots *slots,
if (new->npages != npages)
sort_memslots(slots);
}
-
-   slots->generation = last_generation + 1;
 }
 
 static int check_memory_region_flags(struct kvm_userspace_memory_region *mem)
@@ -720,10 +715,19 @@ static struct kvm_memslots *install_new_memslots(struct 
kvm *kvm,
 {
struct kvm_memslots *old_memslots = kvm->memslots;
 
-   update_memslots(slots, new, kvm->memslots->generation);
+   slots->generation = old_memslots->generation + 1;
+
+   update_memslots(slots, new);
rcu_assign_pointer(kvm->memslots, slots);
synchronize_srcu_expedited(>srcu);
 
+   /*
+* Increment the new memslot generation a second time. This prevents
+* vm exits that race with memslot updates from caching a memslot
+* generation that will (potentially) be valid forever.
+*/
+   slots->generation++;
+
kvm_arch_memslots_updated(kvm);
 
return old_memslots;
-- 
2.1.0.rc2.206.gedb03e5

--
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 13/14] scsi: add support for a blk-mq based I/O path.

[Kashyap Desai]

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Friday, July 18, 2014 3:43 PM
> To: James Bottomley; linux-s...@vger.kernel.org
> Cc: Jens Axboe; Bart Van Assche; Mike Christie; Martin K. Petersen;
Robert
> Elliott; Webb Scales; linux-kernel@vger.kernel.org
> Subject: [PATCH 13/14] scsi: add support for a blk-mq based I/O path.
>
> This patch adds support for an alternate I/O path in the scsi midlayer
which
> uses the blk-mq infrastructure instead of the legacy request code.
>
> Use of blk-mq is fully transparent to drivers, although for now a host
> template field is provided to opt out of blk-mq usage in case any
unforseen
> incompatibilities arise.
>
> In general replacing the legacy request code with blk-mq is a simple and
> mostly mechanical transformation.  The biggest exception is the new code
> that deals with the fact the I/O submissions in blk-mq must happen from
> process context, which slightly complicates the I/O completion handler.
> The second biggest differences is that blk-mq is build around the
concept of
> preallocated requests that also include driver specific data, which in
SCSI
> context means the scsi_cmnd structure.  This completely avoids dynamic
> memory allocations for the fast path through I/O submission.
>
> Due the preallocated requests the MQ code path exclusively uses the
host-
> wide shared tag allocator instead of a per-LUN one.  This only affects
drivers
> actually using the block layer provided tag allocator instead of their
own.
> Unlike the old path blk-mq always provides a tag, although drivers don't
have
> to use it.
>
> For now the blk-mq path is disable by defauly and must be enabled using
the
> "use_blk_mq" module parameter.  Once the remaining work in the block
> layer to make blk-mq more suitable for slow devices is complete I hope
to
> make it the default and eventually even remove the old code path.
>
> Based on the earlier scsi-mq prototype by Nicholas Bellinger.
>
> Thanks to Bart Van Assche and Robert Elliot for testing, benchmarking
and
> various sugestions and code contributions.
>
> Signed-off-by: Christoph Hellwig 
> Reviewed-by: Hannes Reinecke 
> Reviewed-by: Webb Scales 
> Acked-by: Jens Axboe 
> Tested-by: Bart Van Assche 
> Tested-by: Robert Elliott 
> ---
>  drivers/scsi/hosts.c  |  35 +++-
>  drivers/scsi/scsi.c   |   5 +-
>  drivers/scsi/scsi_lib.c   | 464
> --
>  drivers/scsi/scsi_priv.h  |   3 +
>  drivers/scsi/scsi_scan.c  |   5 +-
>  drivers/scsi/scsi_sysfs.c |   2 +
>  include/scsi/scsi_host.h  |  18 +-
>  include/scsi/scsi_tcq.h   |  28 ++-
>  8 files changed, 488 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index
0632eee..6de80e3
> 100644
> --- a/drivers/scsi/hosts.c
> +++ b/drivers/scsi/hosts.c
> @@ -213,9 +213,24 @@ int scsi_add_host_with_dma(struct Scsi_Host
> *shost, struct device *dev,
>   goto fail;
>   }
>
> + if (shost_use_blk_mq(shost)) {
> + error = scsi_mq_setup_tags(shost);
> + if (error)
> + goto fail;
> + }
> +
> + /*
> +  * Note that we allocate the freelist even for the MQ case for
now,
> +  * as we need a command set aside for scsi_reset_provider.  Having
> +  * the full host freelist and one command available for that is a
> +  * little heavy-handed, but avoids introducing a special allocator
> +  * just for this.  Eventually the structure of scsi_reset_provider
> +  * will need a major overhaul.
> +  */
>   error = scsi_setup_command_freelist(shost);
>   if (error)
> - goto fail;
> + goto out_destroy_tags;
> +
>
>   if (!shost->shost_gendev.parent)
>   shost->shost_gendev.parent = dev ? dev : _bus;
> @@ -226,7 +241,7 @@ int scsi_add_host_with_dma(struct Scsi_Host *shost,
> struct device *dev,
>
>   error = device_add(>shost_gendev);
>   if (error)
> - goto out;
> + goto out_destroy_freelist;
>
>   pm_runtime_set_active(>shost_gendev);
>   pm_runtime_enable(>shost_gendev);
> @@ -279,8 +294,11 @@ int scsi_add_host_with_dma(struct Scsi_Host
> *shost, struct device *dev,
>   device_del(>shost_dev);
>   out_del_gendev:
>   device_del(>shost_gendev);
> - out:
> + out_destroy_freelist:
>   scsi_destroy_command_freelist(shost);
> + out_destroy_tags:
> + if (shost_use_blk_mq(shost))
> + scsi_mq_destroy_tags(shost);
>   fail:
>   return error;
>  }
> @@ -309,8 +327,13 @@ static void scsi_host_dev_release(struct device
> *dev)
>   }
>
>   scsi_destroy_command_freelist(shost);
> - if (shost->bqt)
> - blk_free_tags(shost->bqt);
> + if (shost_use_blk_mq(shost)) {
> + if (shost->tag_set.tags)
> + scsi_mq_destroy_tags(shost);
> + } else {
> + 

[PATCH] regmap: fix of_regmap_get_endian()

[Stephen Warren]

From: Stephen Warren 

Commit d647c199510c ("regmap: add DT endianness binding support") has
some issues. Specifically, if config->reg_format_endian is not explicitly
set, it will be zero, i.e. REGMAP_ENDIAN_DEFAULT. The switch statement
that looks up the *endian from DT for the type==REGMAP_ENDIAN_VAL case
doesn't change *endian in the type==REGMAP_ENDIAN_REG case. However, the
test immediately following, compares *endian against REGMAP_ENDIAN_NATIVE,
and if not equal, returns *endian as is. This ends up returning
REGMAP_ENDIAN_DEFAULT, which the calling code does not expect, eventually
leading to e.g.:

Unable to handle kernel NULL pointer dereference at virtual address 0024
...
[] (regcache_cache_only) from [] 
(tegra30_ahub_probe+0x1b8/0x430)
[] (tegra30_ahub_probe) from [] 
(platform_drv_probe+0x2c/0x5c)
[] (platform_drv_probe) from [] 
(driver_probe_device+0x10c/0x22c)
[] (driver_probe_device) from [] (__driver_attach+0x8c/0x90)

This patch solves this by:
* When looking up the endianness from DT, don't change *endian at all if
  there is no DT property; leave it set to REGMAP_ENDIAN_DEFAULT so the
  code falls through to other data sources in the same way as before.
  Now, the "unspecified" case acts the same for both REGMAP_ENDIAN_REG and
  REGMAP_ENDIAN_VAL.
* After potentially looking up the endianness from DT, check *endian
  against REGMAP_ENDIAN_DEFAULT instead of REGMAP_ENDIAN_NATIVE to avoid
  returning unexpected values.

Also, clean up the code a bit:

* Make the comments briefer, and only refer to the specific action taken
  at their location. This makes most of the comments independent of DT,
  and easier to follow.
* Restore the overall default of REGMAP_ENDIAN_BIG if none of the config,
  DT, or the bus specify any endianness. Since all busses specify an
  endianness now, this makes no difference, but I saw no justification in
  the patch description for changing the default default.
* s/of_regmap_get_endian/regmap_get_endian/ since the function isn't DT-
  specific, even if the reason it was originally added was to add some
  DT-specific features.

Reported-by: Thierry Reding 
Fixes: d647c199510c ("regmap: add DT endianness binding support")
Cc: Xiubo Li 
Signed-off-by: Stephen Warren 
---
 drivers/base/regmap/regmap.c | 58 ++--
 1 file changed, 18 insertions(+), 40 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index e4e567e82b84..bb4502a48be5 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -454,7 +454,7 @@ enum regmap_endian_type {
REGMAP_ENDIAN_VAL,
 };
 
-static int of_regmap_get_endian(struct device *dev,
+static int regmap_get_endian(struct device *dev,
const struct regmap_bus *bus,
const struct regmap_config *config,
enum regmap_endian_type type,
@@ -465,15 +465,7 @@ static int of_regmap_get_endian(struct device *dev,
if (!endian || !config)
return -EINVAL;
 
-   /*
-* Firstly, try to parse the endianness from driver's config,
-* this is to be compatible with the none DT or the old drivers.
-* From the driver's config the endianness value maybe:
-*   REGMAP_ENDIAN_BIG,
-*   REGMAP_ENDIAN_LITTLE,
-*   REGMAP_ENDIAN_NATIVE,
-*   REGMAP_ENDIAN_DEFAULT.
-*/
+   /* Retrieve the endianness specification from the regmap config */
switch (type) {
case REGMAP_ENDIAN_REG:
*endian = config->reg_format_endian;
@@ -485,30 +477,17 @@ static int of_regmap_get_endian(struct device *dev,
return -EINVAL;
}
 
-   /*
-* If the endianness parsed from driver config is
-* REGMAP_ENDIAN_DEFAULT, that means maybe we are using the DT
-* node to specify the endianness information.
-*/
+   /* If the regmap config specified a non-default value, use that */
if (*endian != REGMAP_ENDIAN_DEFAULT)
return 0;
 
-   /*
-* Secondly, try to parse the endianness from DT node if the
-* driver config does not specify it.
-* From the DT node the endianness value maybe:
-*   REGMAP_ENDIAN_BIG,
-*   REGMAP_ENDIAN_LITTLE,
-*   REGMAP_ENDIAN_NATIVE,
-*/
+   /* Parse the device's DT node for an endianness specification */
switch (type) {
case REGMAP_ENDIAN_VAL:
if (of_property_read_bool(np, "big-endian"))
*endian = REGMAP_ENDIAN_BIG;
else if (of_property_read_bool(np, "little-endian"))
*endian = REGMAP_ENDIAN_LITTLE;
-   else
-   *endian = REGMAP_ENDIAN_NATIVE;
break;
case REGMAP_ENDIAN_REG:
break;
@@ -516,19 +495,11 @@ static int of_regmap_get_endian(struct device 

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Catalin Marinas]

On Mon, Aug 18, 2014 at 10:30:54PM +0100, Liviu Dudau wrote:
> On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
> > On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> > > On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > > > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > > > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > > > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> > > > >> > int __weak pcibios_add_device(struct pci_dev *dev)
> > > > >> > {
> > > > >> >+   dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > > >> >+
> > > > >> >return 0;
> > > > >> > }
> > > > >> 
> > > > >> For this, my suggestion is to add arch dependent function to setup 
> > > > >> the irq
> > > > >> line for pci devices. I can't find an obvious reason this won't work 
> > > > >> on other
> > > > >> archs, but maybe this will hurt some of them?
> > > > >
> > > > >I'm not sure I understand your point. Architectures that support OF 
> > > > >will obviously
> > > > >benefit from this common approach, and for the other ones the function 
> > > > >is empty
> > > > >so it will not change existing behaviour. If you are suggesting that I 
> > > > >should
> > > > >create a new API that each architecture could go and implement for 
> > > > >setting up the
> > > > >IRQ line then I would agree that it would be nice to have that, but 
> > > > >the question
> > > > >is how many architectures are outside OF that need this?
> > > > 
> > > > My suggestion is to define the pcibios_add_device() for arm arch, like 
> > > > the one
> > > > in arch/powerpc/kernel/pci-common.c. If my understanding is correct, 
> > > > this
> > > > patch set address the pci bus setup mostly on arm arch.
> > > 
> > > And also arm64 at the least.
> > ...
> > > Well, it will become necessary as old code gets dismantled and converted 
> > > towards
> > > this patchset. To give you an example that I'm familiar with, for 
> > > arch/arm the
> > > host bridge drivers have moved into drivers/pci/host, but they still 
> > > depend/use
> > > the bios32 infrastructure that takes care of setting up the irq. When 
> > > they switch
> > > to my version they would have to go and debug the "irq not being 
> > > assigned" issue
> > > and it is quite likely that some of the people doing the conversion will 
> > > complain
> > > about my code rather than understanding the issue. What I'm trying to do 
> > > is to
> > > make switching to my patchset as painless as possible, with a cleanup to 
> > > remove
> > > redundant operations coming after the switchover.
> > 
> > While the goal is fine, until we see a common pattern for what needs to
> > go into pcibios_add_device() I think we should have an arm64-specific
> > implementation (and probably an arm32 specific one as well). I can see
> > powerpc uses it for setting the DMA ops. Would we have a similar need on
> > arm64 to choose between coherent and non-coherent dma_ops?
> 
> At this point I would like to hear more from people doing the conversion of
> the drivers. I cannot answer fully for all arm or arm64 drivers.

As I read the description of pcibios_add_device(), it is meant as an
architecture hook. While it's nice to generalise this, I'm not sure we
we can find a common denominator. For example, we may want to call
set_dma_ops() as powerpc does but the ops would be arm64 specific (so
even the __weak implementation may not be used by any architecture).

-- 
Catalin
--
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/