[PATCH v2] networking: Documentation: Fix typo in timestamping.txt

[Ahmad Fatoum]

Passing (void *) val would cause sock_setsockopt to -EFAULT.

See tools/testing/selftests/networking/timestamping/timestamping.c
for a working example.

Cc: Jonathan Corbet 
Cc: linux-doc@vger.kernel.org
Cc: triv...@kernel.org
Signed-off-by: Ahmad Fatoum 
---
Changes in v2:
  - Reference current location of timestamping.c example in commit message

 Documentation/networking/timestamping.txt | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/networking/timestamping.txt 
b/Documentation/networking/timestamping.txt
index 96f50694..0410863f 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -44,8 +44,7 @@ timeval of SO_TIMESTAMP (ms).
 Supports multiple types of timestamp requests. As a result, this
 socket option takes a bitmap of flags, not a boolean. In
 
-  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, (void *) val,
-   sizeof(val));
+  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, , sizeof(val));
 
 val is an integer with any of the following bits set. Setting other
 bit returns EINVAL and does not change the current state.
@@ -231,8 +230,7 @@ setsockopt to receive timestamps:
 
   __u32 val = SOF_TIMESTAMPING_SOFTWARE |
  SOF_TIMESTAMPING_OPT_ID /* or any other flag */;
-  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, (void *) val,
-   sizeof(val));
+  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, , sizeof(val));
 
 
 1.4 Bytestream Timestamps
-- 
2.12.2

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

[PATCH] networking: Documentation: Fix typo in timestamping.txt

[ahmad]

From: Ahmad Fatoum 

Passing (void *) val would cause sock_setsockopt to -EFAULT.

See Documentation/networking/timestamping/timestamping.c
for a working example.

Cc: Jonathan Corbet 
Cc: linux-doc@vger.kernel.org
Cc: triv...@kernel.org
Signed-off-by: Ahmad Fatoum 
---
 Documentation/networking/timestamping.txt | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/networking/timestamping.txt 
b/Documentation/networking/timestamping.txt
index 96f50694..0410863f 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -44,8 +44,7 @@ timeval of SO_TIMESTAMP (ms).
 Supports multiple types of timestamp requests. As a result, this
 socket option takes a bitmap of flags, not a boolean. In
 
-  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, (void *) val,
-   sizeof(val));
+  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, , sizeof(val));
 
 val is an integer with any of the following bits set. Setting other
 bit returns EINVAL and does not change the current state.
@@ -231,8 +230,7 @@ setsockopt to receive timestamps:
 
   __u32 val = SOF_TIMESTAMPING_SOFTWARE |
  SOF_TIMESTAMPING_OPT_ID /* or any other flag */;
-  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, (void *) val,
-   sizeof(val));
+  err = setsockopt(fd, SOL_SOCKET, SO_TIMESTAMPING, , sizeof(val));
 
 
 1.4 Bytestream Timestamps
-- 
2.12.2

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

Re: [RFC PATCH v2 12/17] cgroup: Remove cgroup v2 no internal process constraint

[Mike Galbraith]

On Fri, 2017-05-19 at 16:38 -0400, Tejun Heo wrote:
> Hello, Waiman.
> 
> On Mon, May 15, 2017 at 09:34:11AM -0400, Waiman Long wrote:
> > The rationale behind the cgroup v2 no internal process constraint is
> > to avoid resouorce competition between internal processes and child
> > cgroups. However, not all controllers have problem with internal
> > process competiton. Enforcing this rule may lead to unnatural process
> > hierarchy and unneeded levels for those controllers.
> 
> This isn't necessarily something we can determine by looking at the
> current state of controllers.  It's true that some controllers - pid
> and perf - inherently only care about membership of each task but at
> the same time neither really suffers from the constraint either.  CPU
> which is the problematic one here...

(+ cpuacct + cpuset)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/29] printk-formats.txt: standardize document format

[Randy Dunlap]

On 05/19/17 13:28, Mauro Carvalho Chehab wrote:
> Em Fri, 19 May 2017 03:26:08 -0700
> Joe Perches  escreveu:
> 
>> On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote:
>>> Each text file under Documentation follows a different
>>> format. Some doesn't even have titles!
>>>
>>> Change its representation to follow the adopted standard,
>>> using ReST markups for it to be parseable by Sphinx:
>>>
>>> - add a title for the document;
>>> - add markups for section titles;
>>> - move authorship to the beginning and use :Author:;
>>> - use right markup for tables;
>>> - mark literals and literal blocks.  
>>
>> I think the .rst markup is far uglier to read as text
>> and harder to modify for new additions to %p
>> given column alignments.
>>
>> For instance below, but other than that, the .rst
>> is easier to read.
>>
>>> diff --git a/Documentation/printk-formats.txt 
>>> b/Documentation/printk-formats.txt  
>> []
>>> @@ -1,139 +1,180 @@
>>> -If variable is of Type,use printk format specifier:
>>> --
>>> -   int %d or %x
>>> -   unsigned int%u or %x
>>> -   long%ld or %lx
>>> -   unsigned long   %lu or %lx
>>> -   long long   %lld or %llx
>>> -   unsigned long long  %llu or %llx
>>> -   size_t  %zu or %zx
>>> -   ssize_t %zd or %zx
>>> -   s32 %d or %x
>>> -   u32 %u or %x
>>> -   s64 %lld or %llx
>>> -   u64 %llu or %llx  
>> []
>>> +=== ===
>>> +If variable is of Type use printk format specifier
>>> +=== ===
>>> +``int````%d or %x``
>>> +``unsigned int``   ``%u or %x``
>>> +``long``   ``%ld or %lx``
>>> +``unsigned long``  ``%lu or %lx``
>>> +``long long``  ``%lld or %llx``
>>> +``unsigned long long`` ``%llu or %llx``
>>> +``size_t`` ``%zu or %zx``
>>> +``ssize_t````%zd or %zx``
>>> +``s32````%d or %x``
>>> +``u32````%u or %x``
>>> +``s64````%lld or %llx``
>>> +``u64````%llu or %llx``
>>> +=== ===  
> 
> Well, we could,instead, use literal blocks, e. g. something like:
> 
> ::
> 
>  -If variable is of Type, use printk format specifier:
>  --
>  -int %d or %x
>  -unsigned int%u or %x
>  -long%ld or %lx
>  -unsigned long   %lu or %lx
>  -long long   %lld or %llx
>  -unsigned long long  %llu or %llx
>  -size_t  %zu or %zx
>  -ssize_t %zd or %zx
>  -s32 %d or %x
>  -u32 %u or %x
>  -s64 %lld or %llx
>  -u64 %llu or %llx  
> 

I like that latter option.

thanks.
-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6] kmod: preempt on kmod_umh_threads_get()

[Dmitry Torokhov]

On Thu, May 18, 2017 at 08:24:43PM -0700, Luis R. Rodriguez wrote:
> In theory it is possible multiple concurrent threads will try to
> kmod_umh_threads_get() and as such atomic_inc(_concurrent) at
> the same time, therefore enabling a small time during which we've
> bumped kmod_concurrent but have not really enabled work. By using
> preemption we mitigate this a bit.
> 
> Preemption is not needed when we kmod_umh_threads_put().
> 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  kernel/kmod.c | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 563600fc9bb1..7ea11dbc7564 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -113,15 +113,35 @@ static int call_modprobe(char *module_name, int wait)
>  
>  static int kmod_umh_threads_get(void)
>  {
> + int ret = 0;
> +
> + /*
> +  * Disabling preemption makes sure that we are not rescheduled here
> +  *
> +  * Also preemption helps kmod_concurrent is not increased by mistake
> +  * for too long given in theory two concurrent threads could race on
> +  * atomic_inc() before we atomic_read() -- we know that's possible
> +  * and but we don't care, this is not used for object accounting and
> +  * is just a subjective threshold. The alternative is a lock.
> +  */
> + preempt_disable();
>   atomic_inc(_concurrent);
>   if (atomic_read(_concurrent) <= max_modprobes)

That is very "fancy" way to basically say:

if (atomic_inc_return(_concurrent) <= max_modprobes)
...

> - return 0;
> + goto out;
> +
>   atomic_dec(_concurrent);
> - return -EBUSY;
> + ret = -EBUSY;
> +out:
> + preempt_enable();
> + return ret;
>  }
>  
>  static void kmod_umh_threads_put(void)
>  {
> + /*
> +  * Preemption is not needed given once work is done we can
> +  * pace ourselves on our way out.
> +  */
>   atomic_dec(_concurrent);
>  }
>  
> -- 
> 2.11.0
> 

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/6] kmod: use simplified rate limit printk

[Dmitry Torokhov]

On Thu, May 18, 2017 at 08:24:44PM -0700, Luis R. Rodriguez wrote:
> Just use the simplified rate limit printk when the max modprobe
> limit is reached, while at it throw out a bone should the error
> be triggered.
> 
> Reviewed-by: Petr Mladek 
> Signed-off-by: Luis R. Rodriguez 
> ---
>  kernel/kmod.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/kernel/kmod.c b/kernel/kmod.c
> index 7ea11dbc7564..56cd2a16e7ac 100644
> --- a/kernel/kmod.c
> +++ b/kernel/kmod.c
> @@ -166,7 +166,6 @@ int __request_module(bool wait, const char *fmt, ...)
>   va_list args;
>   char module_name[MODULE_NAME_LEN];
>   int ret;
> - static int kmod_loop_msg;
>  
>   /*
>* We don't allow synchronous module loading from async.  Module
> @@ -191,13 +190,8 @@ int __request_module(bool wait, const char *fmt, ...)
>  
>   ret = kmod_umh_threads_get();
>   if (ret) {
> - /* We may be blaming an innocent here, but unlikely */
> - if (kmod_loop_msg < 5) {
> - printk(KERN_ERR
> -"request_module: runaway loop modprobe %s\n",
> -module_name);
> - kmod_loop_msg++;
> - }
> + pr_err_ratelimited("%s: module \"%s\" reached limit (%u) of 
> concurrent modprobe calls\n",
> +__func__, module_name, max_modprobes);

This is completely different behavior, isn't it? Instead of reporting
first 5 occurrences we now reporting every once in a while. Why is this
new behavior better?

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/41] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

[Tony Lindgren]

Hi,

* Kishon Vijay Abraham I <kis...@ti.com> [170519 01:19]:
> This series adds UHS, HS200, DDR mode and ADMA support to
> omap_hsmmc driver used to improve the throughput of MMC/SD in dra7
> SoCs.

Certainly seems way less intrusive than earlier before the
dmaengine changes :)

> *) tuning ratio of MMC in dra7 is different from sdhci

Hmm what's the tuning ratio?

> This series has been tested on beagleboard, pandaboard, beaglebone-black,
> beaglebone, am335x-evm, am437x-evm, dra7xx-evm, dra72x-evm, am571x-idk
> and am572x-idk.

I gave this a quick try after manally applying next-20170519
after reverting 67d0687224a9 ("mm: drop HASH_ADAPT"). Looks like
something is missing as I got:

arch/arm/mach-omap2/pdata-quirks.c:445:23: error:
'struct omap_hsmmc_platform_data' has no member named 'version'
...

It's possible I messed up something while manually applying.

> I can split the series to go into Ulf Hansson's tree and Tony's tree 
> separately if that is required.

Yes please. Maybe send the dts parts first that are ready to
get merged, like the fixes and all the iodelay configuration.

Then the mmc driver changes as a separate set.

Then third set to follow-up and enable things once the mmc
driver changes are merged.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count

[Dmitry Torokhov]

On Fri, May 19, 2017 at 02:45:29PM -0700, Luis R. Rodriguez wrote:
> On May 19, 2017 1:45 PM, "Dmitry Torokhov" 
> wrote:
> 
> On Thu, May 18, 2017 at 08:24:39PM -0700, Luis R. Rodriguez wrote:
> > We currently statically limit the number of modprobe threads which
> > we allow to run concurrently to 50. As per Keith Owens, this was a
> > completely arbitrary value, and it was set in the 2.3.38 days [0]
> > over 16 years ago in year 2000.
> >
> > Although we haven't yet hit our lower limits, experimentation [1]
> > shows that when and if we hit this limit in the worst case, will be
> > fatal -- consider get_fs_type() failures upon mount on a system which
> > has many partitions, some of which might even be with the same
> > filesystem. Its best to be prudent and increase and set this
> > value to something more sensible which ensures we're far from hitting
> > the limit and also allows default build/user run time override.
> >
> > The worst case is fatal given that once a module fails to load there
> > is a period of time during which subsequent request for the same module
> > will fail, so in the case of partitions its not just one request that
> > could fail, but whole series of partitions. This later issue of a
> > module request failure domino effect can be addressed later, but
> > increasing the limit to something more meaninful should at least give us
> > enough cushion to avoid this for a while.
> >
> > Set this value up with a bit more meaninful modern limits:
> >
> > Bump this up to 64  max for small systems (CONFIG_BASE_SMALL)
> > Bump this up to 128 max for larger systems (!CONFIG_BASE_SMALL)
> >
> > Also allow the default max limit to be further fine tuned at compile
> > time and at initialization at run time at boot up using the kernel
> > parameter: max_modprobes.
> >
> > [0] https://git.kernel.org/cgit/linux/kernel/git/history/
> history.git/commit/?id=ab1c4ec7410f6ec64e1511d1a7d850fc99c09b44
> > [1] https://github.com/mcgrof/test_request_module
> 
> If we actually run into this issue, instead of slamming the system with
> bazillion concurrent requests, can we wait for the other modprobes to
> finish and then continue?
> 
> 
> Yes ! That I have a patch that does precisely that ! That is actually still
> *not enough* to not fail fatally but this would be subject of another
> series with more debatable approaches.
> 

Then please post it.

> This at least pushes us to closer safer limits for now while also making it
> configurable.

Making it configurable depending on how big/little box is makes no
sense, especially if the above is implemented, as depth of modprobe
invocations depends on configuration and not computing power of the
hardware the system is running on.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Tom Lendacky]

On 5/19/2017 4:28 PM, Borislav Petkov wrote:

On Fri, May 19, 2017 at 04:07:24PM -0500, Tom Lendacky wrote:

As long as those never change from static inline everything will be
fine. I can change it, but I really like how it explicitly indicates


I know what you want to do. But you're practically defining a helper
which contains two arbitrary instructions which probably no one else
will need.

So how about we simplify this function even more. We don't need to pay
attention to kexec being in progress because we're halting anyway so who
cares how fast we halt.

Might have to state that in the comment below though, instead of what's
there now.

And for the exact same moot reason, we don't need to look at SME CPUID
feature - we can just as well WBINVD unconditionally.

void stop_this_cpu(void *dummy)
{
local_irq_disable();
/*
 * Remove this CPU:
 */
set_cpu_online(smp_processor_id(), false);
disable_local_APIC();
mcheck_cpu_clear(this_cpu_ptr(_info));

for (;;) {
/*
 * If we are performing a kexec and the processor supports
 * SME then we need to clear out cache information before
 * halting. With kexec, going from SME inactive to SME active
 * requires clearing cache entries so that addresses without
 * the encryption bit set don't corrupt the same physical
 * address that has the encryption bit set when caches are
 * flushed. Perform a wbinvd followed by a halt to achieve
 * this.
 */
asm volatile("wbinvd; hlt" ::: "memory");
}
}

How's that?


I can live with that!

Thanks,
Tom




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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Borislav Petkov]

On Fri, May 19, 2017 at 04:07:24PM -0500, Tom Lendacky wrote:
> As long as those never change from static inline everything will be
> fine. I can change it, but I really like how it explicitly indicates

I know what you want to do. But you're practically defining a helper
which contains two arbitrary instructions which probably no one else
will need.

So how about we simplify this function even more. We don't need to pay
attention to kexec being in progress because we're halting anyway so who
cares how fast we halt.

Might have to state that in the comment below though, instead of what's
there now.

And for the exact same moot reason, we don't need to look at SME CPUID
feature - we can just as well WBINVD unconditionally.

void stop_this_cpu(void *dummy)
{
local_irq_disable();
/*
 * Remove this CPU:
 */
set_cpu_online(smp_processor_id(), false);
disable_local_APIC();
mcheck_cpu_clear(this_cpu_ptr(_info));

for (;;) {
/*
 * If we are performing a kexec and the processor supports
 * SME then we need to clear out cache information before
 * halting. With kexec, going from SME inactive to SME active
 * requires clearing cache entries so that addresses without
 * the encryption bit set don't corrupt the same physical
 * address that has the encryption bit set when caches are
 * flushed. Perform a wbinvd followed by a halt to achieve
 * this.
 */
asm volatile("wbinvd; hlt" ::: "memory");
}
}

How's that?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 13/17] cgroup: Allow fine-grained controllers control in cgroup v2

[Waiman Long]

On 05/19/2017 04:55 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Mon, May 15, 2017 at 09:34:12AM -0400, Waiman Long wrote:
>> For cgroup v1, different controllers can be binded to different cgroup
>> hierarchies optimized for their own use cases. That is not currently
>> the case for cgroup v2 where combining all these controllers into
>> the same hierarchy will probably require more levels than is needed
>> by each individual controller.
>>
>> By not enabling a controller in a cgroup and its descendants, we can
>> effectively trim the hierarchy as seen by a controller from the leafs
>> up. However, there is currently no way to compress the hierarchy in
>> the intermediate levels.
>>
>> This patch implements a fine-grained mechanism to allow a controller to
>> skip some intermediate levels in a hierarchy and effectively flatten
>> the hierarchy as seen by that controller.
>>
>> Controllers can now be directly enabled or disabled in a cgroup
>> by writing to the "cgroup.controllers" file.  The special prefix
>> '#' with the controller name is used to set that controller in
>> pass-through mode.  In that mode, the controller is disabled for that
>> cgroup but it allows its children to have that controller enabled or
>> in pass-through mode again.
>>
>> With this change, each controller can now have a unique view of their
>> virtual process hierarchy that can be quite different from other
>> controllers.  We now have the freedom and flexibility to create the
>> right hierarchy for each controller to suit their own needs without
>> performance loss when compared with cgroup v1.
> I can see the appeal but this needs at least more refinements.
>
> This breaks the invariant that in a cgroup its resource control knobs
> control distribution of resources from its parent.  IOW, the resource
> control knobs of a cgroup always belong to the parent.  This is also
> reflected in how delegation is done.  The delegatee assumes ownership
> of the cgroup itself and the ability to manage sub-cgroups but doesn't
> get the ownership of the resource control knobs as otherwise the
> parent would lose control over how it distributes its resources.

One twist that I am thinking is to have a controller enabled by the
parent in subtree_control, but then allow the child to either disable it
or set it in pass-through mode by writing to controllers file. IOW, a
child cannot enable a controller without parent's permission. Once a
child has permission, it can do whatever it wants. A parent cannot force
a child to have a controller enabled.

> Another aspect is that most controllers aren't that sensitive to
> nesting several levels.  Expensive operations can be and already are
> aggregated and the performance overhead of several levels of nesting
> barely shows up.  Skipping levels can be an interesting optimization
> approach and we can definitely support from the core side; however,
> it'd be a lot nicer if we could do that optimization transparently
> (e.g. CPU can skip multi level queueing if there usually is only one
> item at some levels).

The trend that I am seeing is that the total number of controllers is
going to grow over time. New controllers may be sensitive to the level
of nesting like the cpu controller. I am also thinking about how systemd
is using the cgroup filesystem for task classification purpose without
any controller attached to it. With this scheme, we can accommodate all
the different needs without using different cgroup filesystems.

> Hmm... that said, if we can fix the delegation issue in a not-too-ugly
> way, why not?  I wonder whether we can still keep the resource control
> knobs attached to the parent and skip in the middle.  Topology-wise,
> that'd make more sense too.

Let me know how you think about my proposal above.

Cheers,
Longma

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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Tom Lendacky]

On 5/19/2017 3:58 PM, Borislav Petkov wrote:

On Fri, May 19, 2017 at 03:45:28PM -0500, Tom Lendacky wrote:

Actually there is.  The above will result in data in the cache because
halt() turns into a function call if CONFIG_PARAVIRT is defined (refer
to the comment above where do_wbinvd_halt is set to true). I could make
this a native_wbinvd() and native_halt()


That's why we have the native_* versions - to bypass paravirt crap.


As long as those never change from static inline everything will be
fine. I can change it, but I really like how it explicitly indicates
what is needed in this case. Even if the function gets changed from
static inline the fact that the instructions are sequential in the
function covers that case.

Thanks,
Tom




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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Borislav Petkov]

On Fri, May 19, 2017 at 03:45:28PM -0500, Tom Lendacky wrote:
> Actually there is.  The above will result in data in the cache because
> halt() turns into a function call if CONFIG_PARAVIRT is defined (refer
> to the comment above where do_wbinvd_halt is set to true). I could make
> this a native_wbinvd() and native_halt()

That's why we have the native_* versions - to bypass paravirt crap.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

[Tejun Heo]

Hello,

On Fri, May 19, 2017 at 04:26:24PM -0400, Tejun Heo wrote:
> (exactly in the way necessary), I wonder whether it'd be better to
> simply allow root to be both domain and thread root.

I'll give this approach a shot early next week.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 13/17] cgroup: Allow fine-grained controllers control in cgroup v2

[Tejun Heo]

Hello, Waiman.

On Mon, May 15, 2017 at 09:34:12AM -0400, Waiman Long wrote:
> For cgroup v1, different controllers can be binded to different cgroup
> hierarchies optimized for their own use cases. That is not currently
> the case for cgroup v2 where combining all these controllers into
> the same hierarchy will probably require more levels than is needed
> by each individual controller.
> 
> By not enabling a controller in a cgroup and its descendants, we can
> effectively trim the hierarchy as seen by a controller from the leafs
> up. However, there is currently no way to compress the hierarchy in
> the intermediate levels.
> 
> This patch implements a fine-grained mechanism to allow a controller to
> skip some intermediate levels in a hierarchy and effectively flatten
> the hierarchy as seen by that controller.
> 
> Controllers can now be directly enabled or disabled in a cgroup
> by writing to the "cgroup.controllers" file.  The special prefix
> '#' with the controller name is used to set that controller in
> pass-through mode.  In that mode, the controller is disabled for that
> cgroup but it allows its children to have that controller enabled or
> in pass-through mode again.
> 
> With this change, each controller can now have a unique view of their
> virtual process hierarchy that can be quite different from other
> controllers.  We now have the freedom and flexibility to create the
> right hierarchy for each controller to suit their own needs without
> performance loss when compared with cgroup v1.

I can see the appeal but this needs at least more refinements.

This breaks the invariant that in a cgroup its resource control knobs
control distribution of resources from its parent.  IOW, the resource
control knobs of a cgroup always belong to the parent.  This is also
reflected in how delegation is done.  The delegatee assumes ownership
of the cgroup itself and the ability to manage sub-cgroups but doesn't
get the ownership of the resource control knobs as otherwise the
parent would lose control over how it distributes its resources.

Another aspect is that most controllers aren't that sensitive to
nesting several levels.  Expensive operations can be and already are
aggregated and the performance overhead of several levels of nesting
barely shows up.  Skipping levels can be an interesting optimization
approach and we can definitely support from the core side; however,
it'd be a lot nicer if we could do that optimization transparently
(e.g. CPU can skip multi level queueing if there usually is only one
item at some levels).

Hmm... that said, if we can fix the delegation issue in a not-too-ugly
way, why not?  I wonder whether we can still keep the resource control
knobs attached to the parent and skip in the middle.  Topology-wise,
that'd make more sense too.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 17/32] x86/mm: Add support to access boot related data in the clear

[Tom Lendacky]

On 5/18/2017 4:02 AM, Borislav Petkov wrote:

On Wed, May 17, 2017 at 01:54:39PM -0500, Tom Lendacky wrote:

I was worried what the compiler might do when CONFIG_EFI is not set,
but it appears to take care of it. I'll double check though.


There's a efi_enabled() !CONFIG_EFI version too, so should be fine.


I may introduce a length variable to capture data->len right after
paddr_next is set and then have just a single memunmap() call before
the if check.


Yap.


I tried that, but calling an "__init" function (early_memremap()) from
a non "__init" function generated warnings. I suppose I can pass in a
function for the map and unmap but that looks worse to me (also the
unmap functions take different arguments).


No, the other way around: the __init function should call the non-init
one and you need the non-init one anyway for memremap_is_setup_data().



The "worker" function would be doing the loop through the setup data,
but since the setup data is mapped inside the loop I can't do the __init
calling the non-init function and still hope to consolidate the code.
Maybe I'm missing something here...

Thanks,
Tom


This is like the chicken and the egg scenario. In order to determine if
an address is setup data I have to explicitly map the setup data chain
as decrypted. In order to do that I have to supply a flag to explicitly
map the data decrypted otherwise I wind up back in the
memremap_is_setup_data() function again and again and again...


Oh, fun.


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

Re: [PATCH v5 28/32] x86/mm, kexec: Allow kexec to be used with SME

[Tom Lendacky]

On 5/17/2017 2:17 PM, Borislav Petkov wrote:

On Tue, Apr 18, 2017 at 04:21:21PM -0500, Tom Lendacky wrote:

Provide support so that kexec can be used to boot a kernel when SME is
enabled.

Support is needed to allocate pages for kexec without encryption.  This
is needed in order to be able to reboot in the kernel in the same manner
as originally booted.

Additionally, when shutting down all of the CPUs we need to be sure to
flush the caches and then halt. This is needed when booting from a state
where SME was not active into a state where SME is active (or vice-versa).
Without these steps, it is possible for cache lines to exist for the same
physical location but tagged both with and without the encryption bit. This
can cause random memory corruption when caches are flushed depending on
which cacheline is written last.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/init.h  |1 +
 arch/x86/include/asm/irqflags.h  |5 +
 arch/x86/include/asm/kexec.h |8 
 arch/x86/include/asm/pgtable_types.h |1 +
 arch/x86/kernel/machine_kexec_64.c   |   35 +-
 arch/x86/kernel/process.c|   26 +++--
 arch/x86/mm/ident_map.c  |   11 +++
 include/linux/kexec.h|   14 ++
 kernel/kexec_core.c  |7 +++
 9 files changed, 101 insertions(+), 7 deletions(-)


...


@@ -86,7 +86,7 @@ static int init_transition_pgtable(struct kimage *image, 
pgd_t *pgd)
set_pmd(pmd, __pmd(__pa(pte) | _KERNPG_TABLE));
}
pte = pte_offset_kernel(pmd, vaddr);
-   set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC));
+   set_pte(pte, pfn_pte(paddr >> PAGE_SHIFT, PAGE_KERNEL_EXEC_NOENC));
return 0;
 err:
free_transition_pgtable(image);
@@ -114,6 +114,7 @@ static int init_pgtable(struct kimage *image, unsigned long 
start_pgtable)
.alloc_pgt_page = alloc_pgt_page,
.context= image,
.pmd_flag   = __PAGE_KERNEL_LARGE_EXEC,
+   .kernpg_flag= _KERNPG_TABLE_NOENC,
};
unsigned long mstart, mend;
pgd_t *level4p;
@@ -597,3 +598,35 @@ void arch_kexec_unprotect_crashkres(void)
 {
kexec_mark_crashkres(false);
 }
+
+int arch_kexec_post_alloc_pages(void *vaddr, unsigned int pages, gfp_t gfp)
+{
+   int ret;
+
+   if (sme_active()) {


if (!sme_active())
return 0;

/*
 * If SME...



Ok.




+   /*
+* If SME is active we need to be sure that kexec pages are
+* not encrypted because when we boot to the new kernel the
+* pages won't be accessed encrypted (initially).
+*/
+   ret = set_memory_decrypted((unsigned long)vaddr, pages);
+   if (ret)
+   return ret;
+
+   if (gfp & __GFP_ZERO)
+   memset(vaddr, 0, pages * PAGE_SIZE);


This function is called after alloc_pages() which already zeroes memory
when __GFP_ZERO is supplied.

If you need to clear the memory *after* set_memory_encrypted() happens,
then you should probably mask out __GFP_ZERO before the alloc_pages()
call so as not to do it twice.


I'll look into that.  I could put the memset() at the end of this
function so that it is done here no matter what.  And update the
default arch_kexec_post_alloc_pages() to also do the memset(). It
just hides the clearing of the pages a bit though by doing that.




+   }
+
+   return 0;
+}
+
+void arch_kexec_pre_free_pages(void *vaddr, unsigned int pages)
+{
+   if (sme_active()) {
+   /*
+* If SME is active we need to reset the pages back to being
+* an encrypted mapping before freeing them.
+*/
+   set_memory_encrypted((unsigned long)vaddr, pages);
+   }
+}
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 0bb8842..f4e5de6 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -355,8 +356,25 @@ bool xen_set_default_idle(void)
return ret;
 }
 #endif
+
 void stop_this_cpu(void *dummy)
 {
+   bool do_wbinvd_halt = false;
+
+   if (kexec_in_progress && boot_cpu_has(X86_FEATURE_SME)) {
+   /*
+* If we are performing a kexec and the processor supports
+* SME then we need to clear out cache information before
+* halting. With kexec, going from SME inactive to SME active
+* requires clearing cache entries so that addresses without
+* the encryption bit set don't corrupt the same physical
+* address that has the encryption bit set when caches are
+* 

Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count

[Dmitry Torokhov]

On Thu, May 18, 2017 at 08:24:39PM -0700, Luis R. Rodriguez wrote:
> We currently statically limit the number of modprobe threads which
> we allow to run concurrently to 50. As per Keith Owens, this was a
> completely arbitrary value, and it was set in the 2.3.38 days [0]
> over 16 years ago in year 2000.
> 
> Although we haven't yet hit our lower limits, experimentation [1]
> shows that when and if we hit this limit in the worst case, will be
> fatal -- consider get_fs_type() failures upon mount on a system which
> has many partitions, some of which might even be with the same
> filesystem. Its best to be prudent and increase and set this
> value to something more sensible which ensures we're far from hitting
> the limit and also allows default build/user run time override.
> 
> The worst case is fatal given that once a module fails to load there
> is a period of time during which subsequent request for the same module
> will fail, so in the case of partitions its not just one request that
> could fail, but whole series of partitions. This later issue of a
> module request failure domino effect can be addressed later, but
> increasing the limit to something more meaninful should at least give us
> enough cushion to avoid this for a while.
> 
> Set this value up with a bit more meaninful modern limits:
> 
> Bump this up to 64  max for small systems (CONFIG_BASE_SMALL)
> Bump this up to 128 max for larger systems (!CONFIG_BASE_SMALL)
> 
> Also allow the default max limit to be further fine tuned at compile
> time and at initialization at run time at boot up using the kernel
> parameter: max_modprobes.
> 
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/?id=ab1c4ec7410f6ec64e1511d1a7d850fc99c09b44
> [1] https://github.com/mcgrof/test_request_module

If we actually run into this issue, instead of slamming the system with
bazillion concurrent requests, can we wait for the other modprobes to
finish and then continue?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 12/17] cgroup: Remove cgroup v2 no internal process constraint

[Tejun Heo]

Hello, Waiman.

On Mon, May 15, 2017 at 09:34:11AM -0400, Waiman Long wrote:
> The rationale behind the cgroup v2 no internal process constraint is
> to avoid resouorce competition between internal processes and child
> cgroups. However, not all controllers have problem with internal
> process competiton. Enforcing this rule may lead to unnatural process
> hierarchy and unneeded levels for those controllers.

This isn't necessarily something we can determine by looking at the
current state of controllers.  It's true that some controllers - pid
and perf - inherently only care about membership of each task but at
the same time neither really suffers from the constraint either.  CPU
which is the problematic one here and currently only cares about tasks
actually distributes resources which have parts which are specific to
domain rather than threads and we don't want to declare that CPU isn't
domain aware resource because it inherently is.

> This patch removes the no internal process contraint by enabling those
> controllers that don't like internal process competition to have a
> separate set of control knobs just for internal processes in a cgroup.
> 
> A new control file "cgroup.resource_control" is added. Enabling a
> controller with a "+" prefix will create a separate set of control
> knobs for that controller in the special "cgroup.resource_domain"
> sub-directory for all the internal processes. The existing control
> knobs in the cgroup will then be used to manage resource distribution
> between internal processes as a group and other child cgroups.

We would need to declare all major resource controllers to be needing
that special sub-directory.  That'd work around the
no-internal-process constraint but I don't think it is solving any
real problems.  It's just the kernel doing something that userland can
do with ease and more context.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

[Borislav Petkov]

On Fri, May 19, 2017 at 03:16:51PM -0500, Josh Poimboeuf wrote:
> I'm the stack validation guy, not the stack protection guy :-)

LOL. I thought you were *the* stacks guy. :-)))

But once you've validated it, you could protect it then too. :-)

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

[Tejun Heo]

Hello,

On Fri, May 19, 2017 at 03:33:14PM -0400, Waiman Long wrote:
> On 05/19/2017 03:21 PM, Tejun Heo wrote:
> > Yeah but it also shows up as an integral part of stable interface
> > rather than e.g. /sys/kernel/debug.  This isn't of any interest to
> > people who aren't developing cgroup core code.  There is no reason to
> > risk growing dependencies on it.
> 
> The debug controller is used to show information relevant to the cgroup
> its css'es are attached to. So it will be very hard to use if we
> relocate to /sys/kernel/debug, for example. Currently, nothing in the
> debug controller other than debug_cgrp_subsys are exported. I don't see
> any risk of having dependency on that controller from other parts of the
> kernel.

Oh, sure, I wasn't suggesting moving it under /sys/kernel/debug but
that we'd want to take extra precautions as we can't.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/29] printk-formats.txt: standardize document format

[Mauro Carvalho Chehab]

Em Fri, 19 May 2017 03:26:08 -0700
Joe Perches  escreveu:

> On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote:
> > Each text file under Documentation follows a different
> > format. Some doesn't even have titles!
> > 
> > Change its representation to follow the adopted standard,
> > using ReST markups for it to be parseable by Sphinx:
> > 
> > - add a title for the document;
> > - add markups for section titles;
> > - move authorship to the beginning and use :Author:;
> > - use right markup for tables;
> > - mark literals and literal blocks.  
> 
> I think the .rst markup is far uglier to read as text
> and harder to modify for new additions to %p
> given column alignments.
> 
> For instance below, but other than that, the .rst
> is easier to read.
> 
> > diff --git a/Documentation/printk-formats.txt 
> > b/Documentation/printk-formats.txt  
> []
> > @@ -1,139 +1,180 @@
> > -If variable is of Type,use printk format specifier:
> > --
> > -   int %d or %x
> > -   unsigned int%u or %x
> > -   long%ld or %lx
> > -   unsigned long   %lu or %lx
> > -   long long   %lld or %llx
> > -   unsigned long long  %llu or %llx
> > -   size_t  %zu or %zx
> > -   ssize_t %zd or %zx
> > -   s32 %d or %x
> > -   u32 %u or %x
> > -   s64 %lld or %llx
> > -   u64 %llu or %llx  
> []
> > +=== ===
> > +If variable is of Type use printk format specifier
> > +=== ===
> > +``int````%d or %x``
> > +``unsigned int``   ``%u or %x``
> > +``long``   ``%ld or %lx``
> > +``unsigned long``  ``%lu or %lx``
> > +``long long``  ``%lld or %llx``
> > +``unsigned long long`` ``%llu or %llx``
> > +``size_t`` ``%zu or %zx``
> > +``ssize_t````%zd or %zx``
> > +``s32````%d or %x``
> > +``u32````%u or %x``
> > +``s64````%lld or %llx``
> > +``u64````%llu or %llx``
> > +=== ===  

Well, we could,instead, use literal blocks, e. g. something like:

::

 -If variable is of Type,   use printk format specifier:
 --
 -  int %d or %x
 -  unsigned int%u or %x
 -  long%ld or %lx
 -  unsigned long   %lu or %lx
 -  long long   %lld or %llx
 -  unsigned long long  %llu or %llx
 -  size_t  %zu or %zx
 -  ssize_t %zd or %zx
 -  s32 %d or %x
 -  u32 %u or %x
 -  s64 %lld or %llx
 -  u64 %llu or %llx  



Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

[Tejun Heo]

Hello, Waiman.

On Mon, May 15, 2017 at 09:34:10AM -0400, Waiman Long wrote:
> Now we could have something like
> 
>   R -- A -- B
>\
> T1 -- T2
> 
> where R is the thread root, A and B are non-threaded cgroups, T1 and
> T2 are threaded cgroups. The cgroups R, T1, T2 form a threaded subtree
> where all the non-threaded resources are accounted for in R.  The no
> internal process constraint does not apply in the threaded subtree.
> Non-threaded controllers need to properly handle the competition
> between internal processes and child cgroups at the thread root.
> 
> This model will be flexible enough to support the need of the threaded
> controllers.

Maybe I'm misunderstanding the design, but this seems to push the
processes which belong to the threaded subtree to the parent which is
part of the usual resource domain hierarchy thus breaking the no
internal competition constraint.  I'm not sure this is something we'd
want.  Given that the limitation of the original threaded mode was the
required nesting below root and that we treat root special anyway
(exactly in the way necessary), I wonder whether it'd be better to
simply allow root to be both domain and thread root.

Specific review points below but we'd probably want to discuss the
overall design first.

> +static inline bool cgroup_is_threaded(const struct cgroup *cgrp)
> +{
> + return cgrp->proc_cgrp && (cgrp->proc_cgrp != cgrp);
> +}
> +
> +static inline bool cgroup_is_thread_root(const struct cgroup *cgrp)
> +{
> + return cgrp->proc_cgrp == cgrp;
> +}

Maybe add a bit of comments explaining what's going on with
->proc_cgrp?

>  /**
> + * threaded_children_count - returns # of threaded children
> + * @cgrp: cgroup to be tested
> + *
> + * cgroup_mutex must be held by the caller.
> + */
> +static int threaded_children_count(struct cgroup *cgrp)
> +{
> + struct cgroup *child;
> + int count = 0;
> +
> + lockdep_assert_held(_mutex);
> + cgroup_for_each_live_child(child, cgrp)
> + if (cgroup_is_threaded(child))
> + count++;
> + return count;
> +}

It probably would be a good idea to keep track of the count so that we
don't have to count them each time.  There are cases where people end
up creating a very high number of cgroups and we've already been
bitten a couple times with silly complexity issues.

> @@ -2982,22 +3010,48 @@ static int cgroup_enable_threaded(struct cgroup *cgrp)
>   LIST_HEAD(csets);
>   struct cgrp_cset_link *link;
>   struct css_set *cset, *cset_next;
> + struct cgroup *child;
>   int ret;
> + u16 ss_mask;
>  
>   lockdep_assert_held(_mutex);
>  
>   /* noop if already threaded */
> - if (cgrp->proc_cgrp)
> + if (cgroup_is_threaded(cgrp))
>   return 0;
>  
> - /* allow only if there are neither children or enabled controllers */
> - if (css_has_online_children(>self) || cgrp->subtree_control)
> + /*
> +  * Allow only if it is not the root and there are:
> +  * 1) no children,
> +  * 2) no non-threaded controllers are enabled, and
> +  * 3) no attached tasks.
> +  *
> +  * With no attached tasks, it is assumed that no css_sets will be
> +  * linked to the current cgroup. This may not be true if some dead
> +  * css_sets linger around due to task_struct leakage, for example.
> +  */

It doesn't look like the code is actually making this (incorrect)
assumption.  I suppose the comment is from before
cgroup_is_populated() was added?

>   spin_lock_irq(_set_lock);
>   list_for_each_entry(link, >cset_links, cset_link) {
>   cset = link->cset;
> + if (cset->dead)
> + continue;

Hmm... is this a bug fix which is necessary regardless of whether we
change the threadroot semantics or not?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

[Josh Poimboeuf]

On Fri, May 19, 2017 at 01:30:05PM +0200, Borislav Petkov wrote:
> > it is called so early. I can get past it by adding:
> > 
> > CFLAGS_mem_encrypt.o := $(nostackp)
> > 
> > in the arch/x86/mm/Makefile, but that obviously eliminates the support
> > for the whole file.  Would it be better to split out the sme_enable()
> > and other boot routines into a separate file or just apply the
> > $(nostackp) to the whole file?
> 
> Josh might have a better idea here... CCed.

I'm the stack validation guy, not the stack protection guy :-)

But there is a way to disable compiler options on a per-function basis
with the gcc __optimize__ function attribute.  For example:

  __attribute__((__optimize__("no-stack-protector")))

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 23/32] swiotlb: Add warnings for use of bounce buffers with SME

[Tom Lendacky]

On 5/16/2017 9:52 AM, Borislav Petkov wrote:

On Tue, Apr 18, 2017 at 04:20:19PM -0500, Tom Lendacky wrote:

Add warnings to let the user know when bounce buffers are being used for
DMA when SME is active.  Since the bounce buffers are not in encrypted
memory, these notifications are to allow the user to determine some
appropriate action - if necessary.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/mem_encrypt.h |   11 +++
 include/linux/dma-mapping.h|   11 +++
 include/linux/mem_encrypt.h|6 ++
 lib/swiotlb.c  |3 +++
 4 files changed, 31 insertions(+)

diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index 0637b4b..b406df2 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -26,6 +26,11 @@ static inline bool sme_active(void)
return !!sme_me_mask;
 }

+static inline u64 sme_dma_mask(void)
+{
+   return ((u64)sme_me_mask << 1) - 1;
+}
+
 void __init sme_early_encrypt(resource_size_t paddr,
  unsigned long size);
 void __init sme_early_decrypt(resource_size_t paddr,
@@ -50,6 +55,12 @@ static inline bool sme_active(void)
 {
return false;
 }
+
+static inline u64 sme_dma_mask(void)
+{
+   return 0ULL;
+}
+
 #endif

 static inline void __init sme_early_encrypt(resource_size_t paddr,
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 0977317..f825870 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 

 /**
  * List of possible attributes associated with a DMA mapping. The semantics
@@ -577,6 +578,11 @@ static inline int dma_set_mask(struct device *dev, u64 
mask)

if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
+
+   if (sme_active() && (mask < sme_dma_mask()))
+   dev_warn_ratelimited(dev,
+"SME is active, device will require DMA bounce 
buffers\n");


Bah, no need to break that line - just let it stick out. Ditto for the
others.


Ok.

Thanks,
Tom




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

Re: [PATCH v5 22/32] x86, swiotlb: DMA support for memory encryption

[Tom Lendacky]

On 5/16/2017 9:27 AM, Borislav Petkov wrote:

On Tue, Apr 18, 2017 at 04:20:10PM -0500, Tom Lendacky wrote:

Since DMA addresses will effectively look like 48-bit addresses when the
memory encryption mask is set, SWIOTLB is needed if the DMA mask of the
device performing the DMA does not support 48-bits. SWIOTLB will be
initialized to create decrypted bounce buffers for use by these devices.


Use a verb in the subject:

Subject: x86, swiotlb: Add memory encryption support

or similar.


Will do.

Thanks,
Tom




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

Re: [PATCH v5 19/32] x86/mm: Add support to access persistent memory in the clear

[Tom Lendacky]

On 5/16/2017 9:04 AM, Borislav Petkov wrote:

On Tue, Apr 18, 2017 at 04:19:42PM -0500, Tom Lendacky wrote:

Persistent memory is expected to persist across reboots. The encryption
key used by SME will change across reboots which will result in corrupted
persistent memory.  Persistent memory is handed out by block devices
through memory remapping functions, so be sure not to map this memory as
encrypted.

Signed-off-by: Tom Lendacky 
---
 arch/x86/mm/ioremap.c |   31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index bce0604..55317ba 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -425,17 +425,46 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
  * Examine the physical address to determine if it is an area of memory
  * that should be mapped decrypted.  If the memory is not part of the
  * kernel usable area it was accessed and created decrypted, so these
- * areas should be mapped decrypted.
+ * areas should be mapped decrypted. And since the encryption key can
+ * change across reboots, persistent memory should also be mapped
+ * decrypted.
  */
 static bool memremap_should_map_decrypted(resource_size_t phys_addr,
  unsigned long size)
 {
+   int is_pmem;
+
+   /*
+* Check if the address is part of a persistent memory region.
+* This check covers areas added by E820, EFI and ACPI.
+*/
+   is_pmem = region_intersects(phys_addr, size, IORESOURCE_MEM,
+   IORES_DESC_PERSISTENT_MEMORY);
+   if (is_pmem != REGION_DISJOINT)
+   return true;
+
+   /*
+* Check if the non-volatile attribute is set for an EFI
+* reserved area.
+*/
+   if (efi_enabled(EFI_BOOT)) {
+   switch (efi_mem_type(phys_addr)) {
+   case EFI_RESERVED_TYPE:
+   if (efi_mem_attributes(phys_addr) & EFI_MEMORY_NV)
+   return true;
+   break;
+   default:
+   break;
+   }
+   }
+
/* Check if the address is outside kernel usable area */
switch (e820__get_entry_type(phys_addr, phys_addr + size - 1)) {
case E820_TYPE_RESERVED:
case E820_TYPE_ACPI:
case E820_TYPE_NVS:
case E820_TYPE_UNUSABLE:
+   case E820_TYPE_PRAM:


Can't you simply add:

case E820_TYPE_PMEM:

here too and thus get rid of the region_intersects() thing above?

Because, for example, e820_type_to_iores_desc() maps E820_TYPE_PMEM to
IORES_DESC_PERSISTENT_MEMORY so those should be equivalent...


I'll have to double-check this, but I believe that when persistent
memory is identified through the NFIT table it adds it as a resource
but doesn't add it as an e820 entry so I can't rely on the type being
returned as E820_TYPE_PMEM by e820__get_entry_type().

Thanks,
Tom




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

Re: [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

[Waiman Long]

On 05/19/2017 03:21 PM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Thu, May 18, 2017 at 11:52:18AM -0400, Waiman Long wrote:
>> The controller name is "debug" and so it is obvious what this controller
>> is for. However, the config prompt "Example controller" is indeed vague
> Yeah but it also shows up as an integral part of stable interface
> rather than e.g. /sys/kernel/debug.  This isn't of any interest to
> people who aren't developing cgroup core code.  There is no reason to
> risk growing dependencies on it.

The debug controller is used to show information relevant to the cgroup
its css'es are attached to. So it will be very hard to use if we
relocate to /sys/kernel/debug, for example. Currently, nothing in the
debug controller other than debug_cgrp_subsys are exported. I don't see
any risk of having dependency on that controller from other parts of the
kernel.

>> in meaning. So we can make the prompt more descriptive here. As for the
>> boot param, are you saying something like "cgroup_debug" has to be
>> specified in the command line even if CGROUP_DEBUG config is there for
>> the debug controller to be enabled? I am fine with that if you think it
>> is necessary.
> Yeah, I think that'd be a good idea.  cgroup_debug should do.  While
> at it, can you also please make CGROUP_DEBUG depend on DEBUG_KERNEL?
>
> Thanks.
>
Sure. I will do that.

Cheers,
Longman


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

Re: [RFC PATCH v2 08/17] cgroup: Move debug cgroup to its own file

[Tejun Heo]

Hello, Waiman.

On Thu, May 18, 2017 at 11:52:18AM -0400, Waiman Long wrote:
> The controller name is "debug" and so it is obvious what this controller
> is for. However, the config prompt "Example controller" is indeed vague

Yeah but it also shows up as an integral part of stable interface
rather than e.g. /sys/kernel/debug.  This isn't of any interest to
people who aren't developing cgroup core code.  There is no reason to
risk growing dependencies on it.

> in meaning. So we can make the prompt more descriptive here. As for the
> boot param, are you saying something like "cgroup_debug" has to be
> specified in the command line even if CGROUP_DEBUG config is there for
> the debug controller to be enabled? I am fine with that if you think it
> is necessary.

Yeah, I think that'd be a good idea.  cgroup_debug should do.  While
at it, can you also please make CGROUP_DEBUG depend on DEBUG_KERNEL?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 10/10] arm64: dts: juno: Add Coresight CPU debug nodes

[Suzuki K Poulose]

On 19/05/17 18:44, Sudeep Holla wrote:

Hi Suzuki, Leo,

On 19/05/17 05:25, Leo Yan wrote:

From: Suzuki K Poulose 

Add Coresight CPU debug nodes for Juno r0, r1 & r2. The CPU
debug areas are mapped at the same address for all revisions,
like the ETM, even though the CPUs have changed from r1 to r2.

Cc: Sudeep Holla 
Cc: Leo Yan 
Cc: Mathieu Poirier 
Cc: Liviu Dudau 
Signed-off-by: Suzuki K Poulose 


ARM-SoC team expect DTS to be routed via platform tree.
So I have queued this for v4.13[1]


Sudeep

Thanks for picking that up.

Suzuki

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

Re: [PATCH v10 10/10] arm64: dts: juno: Add Coresight CPU debug nodes

[Sudeep Holla]

Hi Suzuki, Leo,

On 19/05/17 05:25, Leo Yan wrote:
> From: Suzuki K Poulose 
> 
> Add Coresight CPU debug nodes for Juno r0, r1 & r2. The CPU
> debug areas are mapped at the same address for all revisions,
> like the ETM, even though the CPUs have changed from r1 to r2.
> 
> Cc: Sudeep Holla 
> Cc: Leo Yan 
> Cc: Mathieu Poirier 
> Cc: Liviu Dudau 
> Signed-off-by: Suzuki K Poulose 

ARM-SoC team expect DTS to be routed via platform tree.
So I have queued this for v4.13[1]

-- 
Regards,
Sudeep

[1] https://git.kernel.org/sudeep.holla/linux/h/for-next/juno-updates
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/29] printk-formats.txt: standardize document format

[Joe Perches]

On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
> 
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
> 
> - add a title for the document;
> - add markups for section titles;
> - move authorship to the beginning and use :Author:;
> - use right markup for tables;
> - mark literals and literal blocks.

I think the .rst markup is far uglier to read as text
and harder to modify for new additions to %p
given column alignments.

For instance below, but other than that, the .rst
is easier to read.

> diff --git a/Documentation/printk-formats.txt 
> b/Documentation/printk-formats.txt
[]
> @@ -1,139 +1,180 @@
> -If variable is of Type,  use printk format specifier:
> --
> - int %d or %x
> - unsigned int%u or %x
> - long%ld or %lx
> - unsigned long   %lu or %lx
> - long long   %lld or %llx
> - unsigned long long  %llu or %llx
> - size_t  %zu or %zx
> - ssize_t %zd or %zx
> - s32 %d or %x
> - u32 %u or %x
> - s64 %lld or %llx
> - u64 %llu or %llx
[]
> +=== ===
> +If variable is of Type   use printk format specifier
> +=== ===
> +``int``  ``%d or %x``
> +``unsigned int`` ``%u or %x``
> +``long`` ``%ld or %lx``
> +``unsigned long````%lu or %lx``
> +``long long````%lld or %llx``
> +``unsigned long long``   ``%llu or %llx``
> +``size_t``   ``%zu or %zx``
> +``ssize_t``  ``%zd or %zx``
> +``s32``  ``%d or %x``
> +``u32``  ``%u or %x``
> +``s64``  ``%lld or %llx``
> +``u64``  ``%llu or %llx``
> +=== ===


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

Re: Clarify documentation license?

[Jonathan Corbet]

On Thu, 18 May 2017 17:15:17 -0400
Konstantin Ryabitsev  wrote:

> Would it be fair to say documentation is "GNU GPLv2 unless otherwise 
> indicated?" And if that's not the case (because I'm not sure GPLv2 is a 
> sane license for documentation), would it make sense to clearly indicate 
> the documentation license somewhere in the rendered docs?

The documentation is a part of the kernel as a whole, and much of it is
generated directly from (and is thus a derived product of) overtly
GPLv2-licensed source. So yes, GPLv2 is the license to assume for kernel
documentation.

I thought I had managed to chase the FDL references out of most of the
kernel documentation, since the FDL is not GPL-compatible.  The media UAPI
manual is a bit special, though.

It would make sense to describe the license explicitly, yes.  

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/31] cgroup-v2.txt: standardize document format

[Tejun Heo]

Hello, Mauro.

On Thu, May 18, 2017 at 10:22:11PM -0300, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
> 
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
> 
> - Comment the internal index;
> - Use :Date: and :Author: for authorship;
> - Mark titles;
> - Mark literal blocks;
> - Adjust witespaces;
> - Mark notes;
> - Use table notation for the existing tables.

If this is the direction we're taking for all docs, looks good to me.
Do you want me to take the patch through the cgroup tree?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 11/30] kprobes.txt: standardize document format

[Masami Hiramatsu]

On Thu, 18 May 2017 22:24:03 -0300
Mauro Carvalho Chehab  wrote:

> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
> 
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
> 
> - comment the contents;
> - add proper markups for titles;
> - mark literal blocks as such;
> - use :Author: for authorship;
> - use the right markups for footnotes;
> - escape some literals that would otherwise cause problems;
> - fix identation and add blank lines where needed.

OK, it seems good to me.

Acked-by: Masami Hiramatsu 

By the way, there are some words which referes other section
in this document, should it also be updated according to
Sphinx format?

e.g.
[snip]
> @@ -53,7 +59,8 @@ a post_handler, and how to use the maxactive and nmissed 
> fields of
>  a kretprobe.  But if you're in a hurry to start using Kprobes, you
>  can skip ahead to section 2.

here, it refers "section 2".

Thank you,


-- 
Masami Hiramatsu 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Clarify documentation license?

[Theodore Ts'o]

On Thu, May 18, 2017 at 05:15:17PM -0400, Konstantin Ryabitsev wrote:
> 
> I had someone ask me today whether https://www.kernel.org/doc/html/latest/
> is covered by GNU GPL or GNU FDL, and honestly I wasn't sure, as there is
> actually no clear indication. There's places where FDL is listed
> (https://www.kernel.org/doc/html/latest/media/uapi/fdl-appendix.html), but
> that particular instance appears to only cover items in "Linux Media
> Infrastructure Userspace API"), or at least that's the implication.
> 
> Would it be fair to say documentation is "GNU GPLv2 unless otherwise
> indicated?" And if that's not the case (because I'm not sure GPLv2 is a sane
> license for documentation), would it make sense to clearly indicate the
> documentation license somewhere in the rendered docs?

Given that there is no indication, and kernel as a whole is under
GPLv2, I think "GNU GPLv2 unless otherwise indicated" is an accurate
summary of the current state of affairs.

As far as whether or not GPLv2 is "sane" license for documentation,
the stated reasons[1] by the FSF for why they use the GFDL instead of the
GPL are:

1) They want to make it easier for somene to create printed
documentation which can be sold without requiring that "source" be
distributed, and

2) The FSF includes statements (some might describe them as political
screeds) which they want to designate as invariant.

[1] 
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#TOCWhyNotGPLForManuals


I don't think either of these reasons matter for kernel documentation.
For the first, the details of the kernel's internals too quickly for
it to be at all sane for anyone to want to create printed manuals.
For the second, we don't have anything that could be described as a
political manifesto in the kernel Documentation folder that we would
want to exempt from change.

- Ted





> 
> Best,
> Konstantin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 19/29] svga.txt: standardize document format

[Martin Mares]

> diff --git a/Documentation/svga.txt b/Documentation/svga.txt
> index cd66ec836e4f..119f1515b1ac 100644
> --- a/Documentation/svga.txt
> +++ b/Documentation/svga.txt
> @@ -1,24 +1,31 @@

Acked-By: Martin Mares 

Have a nice fortnight
-- 
Martin `MJ' Mares     http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Press any key to quit or any other key to continue
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/29] pinctrl.txt: standardize document format

[Geert Uytterhoeven]

Hi Mauro,

On Fri, May 19, 2017 at 3:25 AM, Mauro Carvalho Chehab
 wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx.
>
> This document is almost following the standard stile.
>
> There are only two things to adjust on it:
>
> - promote the level of the document title;
> - mark literal blocks as such.
>
> Signed-off-by: Mauro Carvalho Chehab 

Thanks for your patch!

> --- a/Documentation/pinctrl.txt
> +++ b/Documentation/pinctrl.txt
> @@ -1,4 +1,7 @@
> +===
>  PINCTRL (PIN CONTROL) subsystem
> +===
> +
>  This document outlines the pin control subsystem in Linux
>
>  This subsystem deals with:
> @@ -33,7 +36,7 @@ When a PIN CONTROLLER is instantiated, it will register a 
> descriptor to the
>  pin control framework, and this descriptor contains an array of pin 
> descriptors
>  describing the pins handled by this specific pin controller.
>
> -Here is an example of a PGA (Pin Grid Array) chip seen from underneath:
> +Here is an example of a PGA (Pin Grid Array) chip seen from underneath::
>
>  A   B   C   D   E   F   G   H
>
> @@ -54,39 +57,40 @@ Here is an example of a PGA (Pin Grid Array) chip seen 
> from underneath:
> 1o   o   o   o   o   o   o   o
>
>  To register a pin controller and name all the pins on this package we can do
> -this in our driver:
> +this in our driver::
>
> -#include 
> +   #include 
>
> -const struct pinctrl_pin_desc foo_pins[] = {
> -  PINCTRL_PIN(0, "A8"),
> -  PINCTRL_PIN(1, "B8"),
> -  PINCTRL_PIN(2, "C8"),
> -  ...
> -  PINCTRL_PIN(61, "F1"),
> -  PINCTRL_PIN(62, "G1"),
> -  PINCTRL_PIN(63, "H1"),
> -};
> +   const struct pinctrl_pin_desc foo_pins[] = {
> +   PINCTRL_PIN(0, "A8"),
> +   PINCTRL_PIN(1, "B8"),
> +   PINCTRL_PIN(2, "C8"),
> +   ...
> +   PINCTRL_PIN(61, "F1"),
> +   PINCTRL_PIN(62, "G1"),
> +   PINCTRL_PIN(63, "H1"),
> +   };

The above block is no longer indented correctly.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/30] isa.txt: standardize document format

[William Breathitt Gray]

On Fri, May 19, 2017 at 05:55:00AM -0300, Mauro Carvalho Chehab wrote:
>Hi William,
>
>Em Thu, 18 May 2017 22:13:55 -0400
>William Breathitt Gray  escreveu:
>
>> On Thu, May 18, 2017 at 10:24:00PM -0300, Mauro Carvalho Chehab wrote:
>> >Each text file under Documentation follows a different
>> >format. Some doesn't even have titles!
>> >
>> >Change its representation to follow the adopted standard,
>> >using ReST markups for it to be parseable by Sphinx:
>> >
>> >- Use the main title standard for this document;
>> >- replace _foo_ by **foo** for emphasis;
>> >- mark literal blocks as such.
>> >
>> >Signed-off-by: Mauro Carvalho Chehab   
>> 
>> I'm all right with this patch, but there's just one minor nitpick about
>> the title that I've inlined.
>> 
>> Acked-by: William Breathitt Gray 
>
>Thanks for review!
>
>> >---
>> > Documentation/isa.txt | 53 
>> > ++-
>> > 1 file changed, 27 insertions(+), 26 deletions(-)
>> >
>> >diff --git a/Documentation/isa.txt b/Documentation/isa.txt
>> >index f232c26a40be..def4a7b690b5 100644
>> >--- a/Documentation/isa.txt
>> >+++ b/Documentation/isa.txt
>> >@@ -1,5 +1,6 @@
>> >+===
>> > ISA Drivers
>> >  
>> 
>> There's no need for this single-dashed line now so just remove it.
>
>Actually, the patch is removing the single-dashed line. The first "-"
>character on the above line from diff :-)

Ah yes, my apologies, you're absolutely correct! This should be
perfectly fine then.

William Breathitt Gray

>
>> 
>> >+===
>
>
>Thanks,
>Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

[Borislav Petkov]

On Fri, Apr 21, 2017 at 01:56:13PM -0500, Tom Lendacky wrote:
> On 4/18/2017 4:22 PM, Tom Lendacky wrote:
> > Add support to check if SME has been enabled and if memory encryption
> > should be activated (checking of command line option based on the
> > configuration of the default state).  If memory encryption is to be
> > activated, then the encryption mask is set and the kernel is encrypted
> > "in place."
> > 
> > Signed-off-by: Tom Lendacky 
> > ---
> >  arch/x86/kernel/head_64.S |1 +
> >  arch/x86/mm/mem_encrypt.c |   83 
> > +++--
> >  2 files changed, 80 insertions(+), 4 deletions(-)
> > 
> 
> ...
> 
> > 
> > -unsigned long __init sme_enable(void)
> > +unsigned long __init sme_enable(struct boot_params *bp)
> >  {
> > +   const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
> > +   unsigned int eax, ebx, ecx, edx;
> > +   unsigned long me_mask;
> > +   bool active_by_default;
> > +   char buffer[16];
> 
> So it turns out that when KASLR is enabled (CONFIG_RAMDOMIZE_BASE=y)
> the stack-protector support causes issues with this function because

What issues?

> it is called so early. I can get past it by adding:
> 
> CFLAGS_mem_encrypt.o := $(nostackp)
> 
> in the arch/x86/mm/Makefile, but that obviously eliminates the support
> for the whole file.  Would it be better to split out the sme_enable()
> and other boot routines into a separate file or just apply the
> $(nostackp) to the whole file?

Josh might have a better idea here... CCed.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 32/32] x86/mm: Add support to make use of Secure Memory Encryption

[Borislav Petkov]

On Tue, Apr 18, 2017 at 04:22:23PM -0500, Tom Lendacky wrote:
> Add support to check if SME has been enabled and if memory encryption
> should be activated (checking of command line option based on the
> configuration of the default state).  If memory encryption is to be
> activated, then the encryption mask is set and the kernel is encrypted
> "in place."
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/kernel/head_64.S |1 +
>  arch/x86/mm/mem_encrypt.c |   83 
> +++--
>  2 files changed, 80 insertions(+), 4 deletions(-)

...

> +unsigned long __init sme_enable(struct boot_params *bp)
>  {
> + const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off;
> + unsigned int eax, ebx, ecx, edx;
> + unsigned long me_mask;
> + bool active_by_default;
> + char buffer[16];
> + u64 msr;
> +
> + /* Check for the SME support leaf */
> + eax = 0x8000;
> + ecx = 0;
> + native_cpuid(, , , );
> + if (eax < 0x801f)
> + goto out;
> +
> + /*
> +  * Check for the SME feature:
> +  *   CPUID Fn8000_001F[EAX] - Bit 0
> +  * Secure Memory Encryption support
> +  *   CPUID Fn8000_001F[EBX] - Bits 5:0
> +  * Pagetable bit position used to indicate encryption
> +  */
> + eax = 0x801f;
> + ecx = 0;
> + native_cpuid(, , , );
> + if (!(eax & 1))
> + goto out;

< newline here.

> + me_mask = 1UL << (ebx & 0x3f);
> +
> + /* Check if SME is enabled */
> + msr = __rdmsr(MSR_K8_SYSCFG);
> + if (!(msr & MSR_K8_SYSCFG_MEM_ENCRYPT))
> + goto out;
> +
> + /*
> +  * Fixups have not been applied to phys_base yet, so we must obtain
> +  * the address to the SME command line option data in the following
> +  * way.
> +  */
> + asm ("lea sme_cmdline_arg(%%rip), %0"
> +  : "=r" (cmdline_arg)
> +  : "p" (sme_cmdline_arg));
> + asm ("lea sme_cmdline_on(%%rip), %0"
> +  : "=r" (cmdline_on)
> +  : "p" (sme_cmdline_on));
> + asm ("lea sme_cmdline_off(%%rip), %0"
> +  : "=r" (cmdline_off)
> +  : "p" (sme_cmdline_off));
> +
> + if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT))
> + active_by_default = true;
> + else
> + active_by_default = false;
> +
> + cmdline_ptr = (const char *)((u64)bp->hdr.cmd_line_ptr |
> +  ((u64)bp->ext_cmd_line_ptr << 32));
> +
> + cmdline_find_option(cmdline_ptr, cmdline_arg, buffer, sizeof(buffer));
> +
> + if (strncmp(buffer, cmdline_on, sizeof(buffer)) == 0)
> + sme_me_mask = me_mask;

Why doesn't simply

if (!strncmp(buffer, "on", 2))
...

work?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/29] rfkill.txt: standardize document format

[Johannes Berg]

On Fri, 2017-05-19 at 08:11 -0300, Mauro Carvalho Chehab wrote:
> 
> Yes, it should work. Actually, you would need to use :depth: 2 to
> produce this output:
> 
> 
>   Contents
> 
>   . rfkill - RF kill switch support
>   . Introduction
>   . Implementation details
>   . Kernel API
>   . Userspace support

Sounds good to me.

> I opted to keep the contents as a comment just because, in the past,
> some maintainers complained about TOC removal, arguing that it makes
> harder for the ones that would be reading the file in ascii.

Ok. I don't really care much either way, I guess. The file is short
enough that the TOC isn't all that important to start with.

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mm: per-cgroup memory reclaim stats

[Michal Hocko]

On Thu 11-05-17 20:16:23, Roman Gushchin wrote:
> Track the following reclaim counters for every memory cgroup:
> PGREFILL, PGSCAN, PGSTEAL, PGACTIVATE, PGDEACTIVATE, PGLAZYFREE and
> PGLAZYFREED.
> 
> These values are exposed using the memory.stats interface of cgroup v2.
> 
> The meaning of each value is the same as for global counters,
> available using /proc/vmstat.
> 
> Also, for consistency, rename mem_cgroup_count_vm_event() to
> count_memcg_event_mm().
> 
> Signed-off-by: Roman Gushchin 
> Suggested-by: Johannes Weiner 
> Cc: Johannes Weiner 
> Cc: Tejun Heo 
> Cc: Li Zefan 
> Cc: Michal Hocko 
> Cc: Vladimir Davydov 
> Cc: cgro...@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux...@kvack.org

Acked-by: Michal Hocko 

Thanks!

> ---
>  Documentation/cgroup-v2.txt | 28 ++
>  fs/dax.c|  2 +-
>  fs/ncpfs/mmap.c |  2 +-
>  include/linux/memcontrol.h  | 48 
> ++---
>  mm/filemap.c|  2 +-
>  mm/memcontrol.c | 10 ++
>  mm/memory.c |  4 ++--
>  mm/shmem.c  |  3 +--
>  mm/swap.c   |  1 +
>  mm/vmscan.c | 30 +---
>  10 files changed, 113 insertions(+), 17 deletions(-)
> 
> diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
> index e50b95c..5804355 100644
> --- a/Documentation/cgroup-v2.txt
> +++ b/Documentation/cgroup-v2.txt
> @@ -918,6 +918,34 @@ PAGE_SIZE multiple when read back.
>  
>   Number of major page faults incurred
>  
> +   pgrefill
> +
> + Amount of scanned pages (in an active LRU list)
> +
> +   pgscan
> +
> + Amount of scanned pages (in an inactive LRU list)
> +
> +   pgsteal
> +
> + Amount of reclaimed pages
> +
> +   pgactivate
> +
> + Amount of pages moved to the active LRU list
> +
> +   pgdeactivate
> +
> + Amount of pages moved to the inactive LRU lis
> +
> +   pglazyfree
> +
> + Amount of pages postponed to be freed under memory pressure
> +
> +   pglazyfreed
> +
> + Amount of reclaimed lazyfree pages
> +
>memory.swap.current
>  
>   A read-only single value file which exists on non-root
> diff --git a/fs/dax.c b/fs/dax.c
> index 66d7906..9aac521d 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1230,7 +1230,7 @@ static int dax_iomap_pte_fault(struct vm_fault *vmf,
>   case IOMAP_MAPPED:
>   if (iomap.flags & IOMAP_F_NEW) {
>   count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
>   major = VM_FAULT_MAJOR;
>   }
>   error = dax_insert_mapping(mapping, iomap.bdev, iomap.dax_dev,
> diff --git a/fs/ncpfs/mmap.c b/fs/ncpfs/mmap.c
> index 0c3905e..6719c0b 100644
> --- a/fs/ncpfs/mmap.c
> +++ b/fs/ncpfs/mmap.c
> @@ -89,7 +89,7 @@ static int ncp_file_mmap_fault(struct vm_fault *vmf)
>* -- nyc
>*/
>   count_vm_event(PGMAJFAULT);
> - mem_cgroup_count_vm_event(vmf->vma->vm_mm, PGMAJFAULT);
> + count_memcg_event_mm(vmf->vma->vm_mm, PGMAJFAULT);
>   return VM_FAULT_MAJOR;
>  }
>  
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index 899949b..b2a5b1c 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -357,6 +357,17 @@ static inline unsigned short mem_cgroup_id(struct 
> mem_cgroup *memcg)
>  }
>  struct mem_cgroup *mem_cgroup_from_id(unsigned short id);
>  
> +static inline struct mem_cgroup *lruvec_memcg(struct lruvec *lruvec)
> +{
> + struct mem_cgroup_per_node *mz;
> +
> + if (mem_cgroup_disabled())
> + return NULL;
> +
> + mz = container_of(lruvec, struct mem_cgroup_per_node, lruvec);
> + return mz->memcg;
> +}
> +
>  /**
>   * parent_mem_cgroup - find the accounting parent of a memcg
>   * @memcg: memcg whose parent to find
> @@ -546,8 +557,23 @@ unsigned long mem_cgroup_soft_limit_reclaim(pg_data_t 
> *pgdat, int order,
>   gfp_t gfp_mask,
>   unsigned long *total_scanned);
>  
> -static inline void mem_cgroup_count_vm_event(struct mm_struct *mm,
> -  enum vm_event_item idx)
> +static inline void count_memcg_events(struct mem_cgroup *memcg,
> +   enum vm_event_item idx,
> +   unsigned long count)
> +{
> + if (!mem_cgroup_disabled())
> + this_cpu_add(memcg->stat->events[idx], count);
> +}
> +
> +static inline 

[PATCH 07/41] mmc: host: omap_hsmmc: Allow io voltage switch even for fixed vdd

[Kishon Vijay Abraham I]

Now that vmmc regulator is made optional, do not bail out if vmmc
regulator is not found.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d8970a7ff4be..d47ef51fbe51 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -416,13 +416,6 @@ static int omap_hsmmc_set_power(struct omap_hsmmc_host 
*host, int power_on,
if (mmc_pdata(host)->set_power)
return mmc_pdata(host)->set_power(host->dev, power_on, iov);
 
-   /*
-* If we don't see a Vcc regulator, assume it's a fixed
-* voltage always-on regulator.
-*/
-   if (!mmc->supply.vmmc)
-   return 0;
-
if (mmc_pdata(host)->before_set_reg)
mmc_pdata(host)->before_set_reg(host->dev, power_on, iov);
 
-- 
2.11.0

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

Re: [PATCH 08/29] rfkill.txt: standardize document format

[Johannes Berg]

On Thu, 2017-05-18 at 22:25 -0300, Mauro Carvalho Chehab wrote:
> 
> +.. CONTENTS
>  
> +  1. Introduction
> +  2. Implementation details
> +  3. Kernel API
> +  4. Userspace support

Why not let this be auto-generated?

.. contents::
   :depth: 1

should work, no?

johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/30] isa.txt: standardize document format

[Mauro Carvalho Chehab]

Hi William,

Em Thu, 18 May 2017 22:13:55 -0400
William Breathitt Gray  escreveu:

> On Thu, May 18, 2017 at 10:24:00PM -0300, Mauro Carvalho Chehab wrote:
> >Each text file under Documentation follows a different
> >format. Some doesn't even have titles!
> >
> >Change its representation to follow the adopted standard,
> >using ReST markups for it to be parseable by Sphinx:
> >
> >- Use the main title standard for this document;
> >- replace _foo_ by **foo** for emphasis;
> >- mark literal blocks as such.
> >
> >Signed-off-by: Mauro Carvalho Chehab   
> 
> I'm all right with this patch, but there's just one minor nitpick about
> the title that I've inlined.
> 
> Acked-by: William Breathitt Gray 

Thanks for review!

> >---
> > Documentation/isa.txt | 53 
> > ++-
> > 1 file changed, 27 insertions(+), 26 deletions(-)
> >
> >diff --git a/Documentation/isa.txt b/Documentation/isa.txt
> >index f232c26a40be..def4a7b690b5 100644
> >--- a/Documentation/isa.txt
> >+++ b/Documentation/isa.txt
> >@@ -1,5 +1,6 @@
> >+===
> > ISA Drivers
> >  
> 
> There's no need for this single-dashed line now so just remove it.

Actually, the patch is removing the single-dashed line. The first "-"
character on the above line from diff :-)

> 
> >+===


Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 00/41] omap_hsmmc: Add ADMA support and UHS/HS200/DDR support

[Kishon Vijay Abraham I]

This series adds UHS, HS200, DDR mode and ADMA support to
omap_hsmmc driver used to improve the throughput of MMC/SD in dra7
SoCs.

The functionality implemented in this series was sent before ([1]) but
was never followed up since supporting high speed modes in dra7 required
IODelay values to be configured. With IODelay driver being merged into
kernel, sending it as a fresh series with support for configuring IODelay
values.

Suggestions of migrating to sdhci driver (from omap_hsmmc driver) is not
addressed since
*) tuning ratio of MMC in dra7 is different from sdhci
*) IOdelay is required for dra7
*) GPIO based card detect is not supported in sdhci
*) Some of the registers don't always have correct values as in sdhci
   (like PSTATE).
Supporting all of these in sdhci will result in adding lot of quirks in
sdhci driver.

This series has been tested on beagleboard, pandaboard, beaglebone-black,
beaglebone, am335x-evm, am437x-evm, dra7xx-evm, dra72x-evm, am571x-idk
and am572x-idk.

I can split the series to go into Ulf Hansson's tree and Tony's tree 
separately if that is required.

[1] -> https://lkml.org/lkml/2015/8/25/213

Balaji T K (1):
  mmc: host: omap_hsmmc: Add voltage switch support for UHS SD card

Kishon Vijay Abraham I (30):
  mmc: host: omap_hsmmc: Support pbias and vmmc_aux to switch to 1.8v
  mmc: host: omap_hsmmc: Separate setting voltage capabilities from bus
power
  mmc: host: omap_hsmmc: Program HCTL based on signal_voltage set by mmc
core
  mmc: host: omap_hsmmc: Set clk rate to the max frequency
  mmc: host: omap_hsmmc: Add tuning support
  mmc: host: omap_hsmmc: Allow io voltage switch even for fixed vdd
  mmc: host: omap_hsmmc: Remove incorrect voltage switch  sequence
  mmc: host: omap_hsmmc: Prepare *set_timing() to be used for iodelay
setting
  mmc: host: omap_hsmmc: Add new compatible string to support dra7
  mmc: host: omap_hsmmc: Fix error path sequence
  mmc: host: omap_hsmmc: Add support to set IODELAY values
  mmc: host: omap_hsmmc: Remove *use_dma* member
  mmc: host: omap_hsmmc: Enable ADMA2
  ARM: dts: dra72-evm: Add vmmc_aux supply to mmc1
  ARM: dts: dra72-evm-revc: Add vmmc_aux supply to mmc1
  ARM: dts: am57xx-beagle-x15-revb1: Fix supply name used for MMC1 IO
lines
  ARM: dts: dra7-evm: Add pinmux configuration for MMC
  ARM: dts: am57xx-beagle-x15: Add pinmux configuration for MMC
  ARM: dts: am571x-idk: Add pinmux configuration for MMC
  ARM: dts: am572x-idk: Add pinmux configuration for MMC
  ARM: dts: dra72-evm: Add pinmux configuration for MMC
  ARM: dts: dra72-evm-revc: Add pinmux configuration for MMC
  ARM: dts: dra71-evm: Add pinmux configuration for MMC
  ARM: dts: dra7: Add "max-frequency" property to MMC dt nodes
  ARM: dts: dra7: Use new dra7-specific compatible string
  ARM: dts: dra7: Add supported MMC/SD modes in MMC dt nodes
  ARM: dts: am57xx-beagle-x15-common: Set MMC2 IO voltage to 3.3V
  ARM: omap2plus_defconfig: Enable PINCTRL_TI_IODELAY
  ARM: multi_v7_defconfig: Enable PINCTRL_TI_IODELAY
  Documentation: ARM: Document new dependencies for MMC on DRA7

Mugunthan V N (1):
  mmc: host: omap_hsmmc: Add software timer when timeout greater than
hardware capablility

Ravikumar Kattekola (2):
  ARM: dts: dra7-evm: Correct the vmmc-supply for mmc2
  ARM: dts: dra72-evm-common: Correct vmmc-supply for mmc2

Sekhar Nori (6):
  mmc: omap_hsmmc: Support non-1.8V IO controllers
  ARM: dts: dra72x: Create a common file with MMC/SD IOdelay data
  ARM: dts: dra74x: Create a common file with MMC/SD IOdelay data
  ARM: dts: am57xx-idk: Move common MMC/SD properties to common file
  ARM: dts: am57xx-idk: Set MMC2 IO voltage to 3.3V
  ARM: OMAP2+: Add pdata-quirks for MMC/SD on DRA74x EVM

Tony Lindgren (1):
  ARM: dts: Add dra7 iodelay configuration

 Documentation/arm/OMAP/README  |4 +
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |6 +
 arch/arm/boot/dts/am571x-idk.dts   |   27 +-
 arch/arm/boot/dts/am572x-idk.dts   |   27 +-
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi|   30 +-
 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts  |   18 +-
 arch/arm/boot/dts/am57xx-beagle-x15.dts|   17 +
 arch/arm/boot/dts/am57xx-idk-common.dtsi   |   10 +
 arch/arm/boot/dts/dra7-evm.dts |   28 +-
 arch/arm/boot/dts/dra7.dtsi|   35 +-
 arch/arm/boot/dts/dra71-evm.dts|   28 +
 arch/arm/boot/dts/dra72-evm-common.dtsi|2 -
 arch/arm/boot/dts/dra72-evm-revc.dts   |   32 +
 arch/arm/boot/dts/dra72-evm.dts|   32 +
 arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi  |  350 ++
 arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi  |  648 +++
 arch/arm/configs/multi_v7_defconfig|1 +
 arch/arm/configs/omap2plus_defconfig   |1 +
 arch/arm/mach-omap2/pdata-quirks.c |   31 +
 drivers/mmc/host/omap_hsmmc.c   

[PATCH 02/41] mmc: host: omap_hsmmc: Separate setting voltage capabilities from bus power

[Kishon Vijay Abraham I]

Add a separate function to set the voltage capabilities of the host
controller. Voltage capabilities should be set only once during
controller initialization but bus power can be changed every time there
is a voltage switch and whenever a different card is inserted.
This allows omap_hsmmc_conf_bus_power to be invoked every time there
is a voltage switch.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 28 +++-
 1 file changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2000aaa359c8..42954efe12f7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1809,25 +1809,34 @@ static int omap_hsmmc_configure_wake_irq(struct 
omap_hsmmc_host *host)
return ret;
 }
 
+static void omap_hsmmc_set_capabilities(struct omap_hsmmc_host *host)
+{
+   u32 val;
+
+   val = OMAP_HSMMC_READ(host->base, CAPA);
+
+   /* Only MMC1 supports 3.0V */
+   if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
+   val |= (VS30 | VS18);
+   else
+   val |= VS18;
+
+   OMAP_HSMMC_WRITE(host->base, CAPA, val);
+}
+
 static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
 {
-   u32 hctl, capa, value;
+   u32 hctl, value;
 
/* Only MMC1 supports 3.0V */
-   if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
+   if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
hctl = SDVS30;
-   capa = VS30 | VS18;
-   } else {
+   else
hctl = SDVS18;
-   capa = VS18;
-   }
 
value = OMAP_HSMMC_READ(host->base, HCTL) & ~SDVS_MASK;
OMAP_HSMMC_WRITE(host->base, HCTL, value | hctl);
 
-   value = OMAP_HSMMC_READ(host->base, CAPA);
-   OMAP_HSMMC_WRITE(host->base, CAPA, value | capa);
-
/* Set SD bus power bit */
set_sd_bus_power(host);
 }
@@ -2134,6 +2143,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
 
mmc->pm_caps |= mmc_pdata(host)->pm_caps;
 
+   omap_hsmmc_set_capabilities(host);
omap_hsmmc_conf_bus_power(host);
 
host->rx_chan = dma_request_chan(>dev, "rx");
-- 
2.11.0

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

[PATCH 01/41] mmc: host: omap_hsmmc: Support pbias and vmmc_aux to switch to 1.8v

[Kishon Vijay Abraham I]

Add support for vmmc_aux to switch to 1.8v. Also use "iov" instead of
"vdd" to indicate io voltage. This is in preparation for adding support
for io signal voltage switch.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 50 ---
 1 file changed, 33 insertions(+), 17 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8c39dccacf39..2000aaa359c8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -244,11 +244,12 @@ static int omap_hsmmc_get_cover_state(struct device *dev)
return mmc_gpio_get_cd(host->mmc);
 }
 
-static int omap_hsmmc_enable_supply(struct mmc_host *mmc)
+static int omap_hsmmc_enable_supply(struct mmc_host *mmc, int iov)
 {
int ret;
struct omap_hsmmc_host *host = mmc_priv(mmc);
struct mmc_ios *ios = >ios;
+   int uvoltage;
 
if (mmc->supply.vmmc) {
ret = mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, ios->vdd);
@@ -257,7 +258,25 @@ static int omap_hsmmc_enable_supply(struct mmc_host *mmc)
}
 
/* Enable interface voltage rail, if needed */
-   if (mmc->supply.vqmmc && !host->vqmmc_enabled) {
+   if (mmc->supply.vqmmc) {
+   if (host->vqmmc_enabled) {
+   ret = regulator_disable(mmc->supply.vqmmc);
+   if (ret) {
+   dev_err(mmc_dev(mmc),
+   "vmmc_aux reg disable failed\n");
+   goto err_vqmmc;
+   }
+   host->vqmmc_enabled = 0;
+   }
+
+   uvoltage = (iov == VDD_165_195) ? VDD_1V8 : VDD_3V0;
+   ret = regulator_set_voltage(mmc->supply.vqmmc, uvoltage,
+   uvoltage);
+   if (ret) {
+   dev_err(mmc_dev(mmc), "vmmc_aux set voltage failed\n");
+   goto err_vqmmc;
+   }
+
ret = regulator_enable(mmc->supply.vqmmc);
if (ret) {
dev_err(mmc_dev(mmc), "vmmc_aux reg enable failed\n");
@@ -309,22 +328,19 @@ static int omap_hsmmc_disable_supply(struct mmc_host *mmc)
 }
 
 static int omap_hsmmc_set_pbias(struct omap_hsmmc_host *host, bool power_on,
-   int vdd)
+   int iov)
 {
int ret;
+   int uvoltage;
 
if (!host->pbias)
return 0;
 
if (power_on) {
-   if (vdd <= VDD_165_195)
-   ret = regulator_set_voltage(host->pbias, VDD_1V8,
-   VDD_1V8);
-   else
-   ret = regulator_set_voltage(host->pbias, VDD_3V0,
-   VDD_3V0);
-   if (ret < 0) {
-   dev_err(host->dev, "pbias set voltage fail\n");
+   uvoltage = (iov <= VDD_165_195) ? VDD_1V8 : VDD_3V0;
+   ret = regulator_set_voltage(host->pbias, uvoltage, uvoltage);
+   if (ret) {
+   dev_err(host->dev, "pbias set voltage failed\n");
return ret;
}
 
@@ -351,13 +367,13 @@ static int omap_hsmmc_set_pbias(struct omap_hsmmc_host 
*host, bool power_on,
 }
 
 static int omap_hsmmc_set_power(struct omap_hsmmc_host *host, int power_on,
-   int vdd)
+   int iov)
 {
struct mmc_host *mmc = host->mmc;
int ret = 0;
 
if (mmc_pdata(host)->set_power)
-   return mmc_pdata(host)->set_power(host->dev, power_on, vdd);
+   return mmc_pdata(host)->set_power(host->dev, power_on, iov);
 
/*
 * If we don't see a Vcc regulator, assume it's a fixed
@@ -367,7 +383,7 @@ static int omap_hsmmc_set_power(struct omap_hsmmc_host 
*host, int power_on,
return 0;
 
if (mmc_pdata(host)->before_set_reg)
-   mmc_pdata(host)->before_set_reg(host->dev, power_on, vdd);
+   mmc_pdata(host)->before_set_reg(host->dev, power_on, iov);
 
ret = omap_hsmmc_set_pbias(host, false, 0);
if (ret)
@@ -387,11 +403,11 @@ static int omap_hsmmc_set_power(struct omap_hsmmc_host 
*host, int power_on,
 * chips/cards need an interface voltage rail too.
 */
if (power_on) {
-   ret = omap_hsmmc_enable_supply(mmc);
+   ret = omap_hsmmc_enable_supply(mmc, iov);
if (ret)
return ret;
 
-   ret = omap_hsmmc_set_pbias(host, true, vdd);
+   ret = omap_hsmmc_set_pbias(host, true, iov);
if (ret)
goto err_set_voltage;
} else {
@@ -401,7 +417,7 @@ static int 

[PATCH 04/41] mmc: host: omap_hsmmc: Add voltage switch support for UHS SD card

[Kishon Vijay Abraham I]

From: Balaji T K 

UHS SD card i/o data line operates at 1.8V when in UHS speed
mode.

Add support for signal voltage switch to support UHS cards.

Also, enable CIRQ before checking for CLEV/DLEV. MMC module can
sense when the clock lines and data lines are driven high by the
card, if MMC is active and CIRQ can be used to keep the MMC
module active. This is required for voltage switching to succeed
and the card to enumerate in UHS mode.

Signed-off-by: Balaji T K 
Signed-off-by: Sourav Poddar 
[kis...@ti.com : cleanup the voltage switch sequence]
Signed-off-by: Kishon Vijay Abraham I 
[nsek...@ti.com: make card busy functions preempt safe]
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 165 ++
 1 file changed, 165 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 893d1624a5a3..4dbf75ad2376 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* OMAP HSMMC Host Controller Registers */
 #define OMAP_HSMMC_SYSSTATUS   0x0014
@@ -111,6 +112,9 @@
 /* PSTATE */
 #define DLEV_DAT(x)(1 << (20 + (x)))
 
+/* AC12 */
+#define AC12_V1V8_SIGEN(1 << 19)
+
 /* Interrupt masks for IE and ISE register */
 #define CC_EN  (1 << 0)
 #define TC_EN  (1 << 1)
@@ -150,6 +154,13 @@
 #define VDD_1V8180 /* 18 uV */
 #define VDD_3V0300 /* 30 uV */
 #define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
+#define VDD_30_31  (ffs(MMC_VDD_30_31) - 1)
+
+#define CON_CLKEXTFREE (1 << 16)
+#define CON_PADEN  (1 << 15)
+#define PSTATE_CLEV(1 << 24)
+#define PSTATE_DLEV(0xF << 20)
+#define PSTATE_DLEV_DAT0   (0x1 << 20)
 
 /*
  * One controller can have multiple slots, like on some omap boards using
@@ -177,6 +188,7 @@ struct omap_hsmmc_host {
struct  mmc_host*mmc;
struct  mmc_request *mrq;
struct  mmc_command *cmd;
+   u32 last_cmd;
struct  mmc_data*data;
struct  clk *fclk;
struct  clk *dbclk;
@@ -209,6 +221,7 @@ struct omap_hsmmc_host {
unsigned intflags;
 #define AUTO_CMD23 (1 << 0)/* Auto CMD23 support */
 #define HSMMC_SDIO_IRQ_ENABLED (1 << 1)/* SDIO irq enabled */
+#define CLKEXTFREE_ENABLED (1 << 2)/* CLKEXTFREE enabled */
struct omap_hsmmc_next  next_data;
struct  omap_hsmmc_platform_data*pdata;
 
@@ -604,6 +617,9 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host 
*host,
if (cmd->opcode == MMC_ERASE)
irq_mask &= ~DTO_EN;
 
+   if (host->flags & CLKEXTFREE_ENABLED)
+   irq_mask |= CIRQ_EN;
+
spin_lock_irqsave(>irq_lock, flags);
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
@@ -947,6 +963,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, 
struct mmc_command *cmd,
cmdreg |= DMAE;
 
host->req_in_progress = 1;
+   host->last_cmd = cmd->opcode;
 
OMAP_HSMMC_WRITE(host->base, ARG, cmd->arg);
OMAP_HSMMC_WRITE(host->base, CMD, cmdreg);
@@ -1848,6 +1865,152 @@ static int omap_hsmmc_multi_io_quirk(struct mmc_card 
*card,
return blk_size;
 }
 
+static int omap_hsmmc_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+   struct omap_hsmmc_host *host;
+   u32 val = 0;
+   int ret = 0;
+
+   host  = mmc_priv(mmc);
+
+   if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
+   val = OMAP_HSMMC_READ(host->base, CAPA);
+   if (!(val & VS30))
+   return -EOPNOTSUPP;
+
+   omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
+
+   val = OMAP_HSMMC_READ(host->base, AC12);
+   val &= ~AC12_V1V8_SIGEN;
+   OMAP_HSMMC_WRITE(host->base, AC12, val);
+
+   ret = omap_hsmmc_set_power(host, 1, VDD_30_31);
+   if (ret) {
+   dev_err(mmc_dev(host->mmc), "failed to switch to 3v\n");
+   return ret;
+   }
+
+   dev_dbg(mmc_dev(host->mmc), " i/o voltage switch to 3V\n");
+   } else if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_180) {
+   val = OMAP_HSMMC_READ(host->base, CAPA);
+   if (!(val & VS18))
+   return -EOPNOTSUPP;
+
+   omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
+
+   val = OMAP_HSMMC_READ(host->base, AC12);
+   val |= AC12_V1V8_SIGEN;
+

[PATCH 08/41] mmc: host: omap_hsmmc: Remove incorrect voltage switch sequence

[Kishon Vijay Abraham I]

ios->vdd is set only in mmc_power_up and mmc_power_off and not in
mmc_select_voltage() as mentioned in the code comment. This seems to be
legacy code that has been carried for a long time without being
tested.

This will be replaced with the correct voltage switch sequence and
populated in start_signal_voltage_switch ops to be used by mmc core
for switching voltages.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/mmc/host/omap_hsmmc.c | 79 ---
 1 file changed, 79 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d47ef51fbe51..30cd2be7141c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1292,67 +1292,6 @@ static void set_sd_bus_power(struct omap_hsmmc_host 
*host)
}
 }
 
-/*
- * Switch MMC interface voltage ... only relevant for MMC1.
- *
- * MMC2 and MMC3 use fixed 1.8V levels, and maybe a transceiver.
- * The MMC2 transceiver controls are used instead of DAT4..DAT7.
- * Some chips, like eMMC ones, use internal transceivers.
- */
-static int omap_hsmmc_switch_opcond(struct omap_hsmmc_host *host, int vdd)
-{
-   u32 reg_val = 0;
-   int ret;
-
-   /* Disable the clocks */
-   if (host->dbclk)
-   clk_disable_unprepare(host->dbclk);
-
-   /* Turn the power off */
-   ret = omap_hsmmc_set_power(host, 0, 0);
-
-   /* Turn the power ON with given VDD 1.8 or 3.0v */
-   if (!ret)
-   ret = omap_hsmmc_set_power(host, 1, vdd);
-   if (host->dbclk)
-   clk_prepare_enable(host->dbclk);
-
-   if (ret != 0)
-   goto err;
-
-   OMAP_HSMMC_WRITE(host->base, HCTL,
-   OMAP_HSMMC_READ(host->base, HCTL) & SDVSCLR);
-   reg_val = OMAP_HSMMC_READ(host->base, HCTL);
-
-   /*
-* If a MMC dual voltage card is detected, the set_ios fn calls
-* this fn with VDD bit set for 1.8V. Upon card removal from the
-* slot, omap_hsmmc_set_ios sets the VDD back to 3V on MMC_POWER_OFF.
-*
-* Cope with a bit of slop in the range ... per data sheets:
-*  - "1.8V" for vdds_mmc1/vdds_mmc1a can be up to 2.45V max,
-*but recommended values are 1.71V to 1.89V
-*  - "3.0V" for vdds_mmc1/vdds_mmc1a can be up to 3.5V max,
-*but recommended values are 2.7V to 3.3V
-*
-* Board setup code shouldn't permit anything very out-of-range.
-* TWL4030-family VMMC1 and VSIM regulators are fine (avoiding the
-* middle range) but VSIM can't power DAT4..DAT7 at more than 3V.
-*/
-   if ((1 << vdd) <= MMC_VDD_23_24)
-   reg_val |= SDVS18;
-   else
-   reg_val |= SDVS30;
-
-   OMAP_HSMMC_WRITE(host->base, HCTL, reg_val);
-   set_sd_bus_power(host);
-
-   return 0;
-err:
-   dev_err(mmc_dev(host->mmc), "Unable to switch operating voltage\n");
-   return ret;
-}
-
 /* Protect the card while the cover is open */
 static void omap_hsmmc_protect_card(struct omap_hsmmc_host *host)
 {
@@ -1763,24 +1702,6 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
 
omap_hsmmc_set_bus_width(host);
 
-   if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
-   /* Only MMC1 can interface at 3V without some flavor
-* of external transceiver; but they all handle 1.8V.
-*/
-   if ((OMAP_HSMMC_READ(host->base, HCTL) & SDVSDET) &&
-   (ios->vdd == DUAL_VOLT_OCR_BIT)) {
-   /*
-* The mmc_select_voltage fn of the core does
-* not seem to set the power_mode to
-* MMC_POWER_UP upon recalculating the voltage.
-* vdd 1.8v.
-*/
-   if (omap_hsmmc_switch_opcond(host, ios->vdd) != 0)
-   dev_dbg(mmc_dev(host->mmc),
-   "Switch operation failed\n");
-   }
-   }
-
omap_hsmmc_set_clock(host);
 
if (ios->timing != host->timing) {
-- 
2.11.0

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

[PATCH 03/41] mmc: host: omap_hsmmc: Program HCTL based on signal_voltage set by mmc core

[Kishon Vijay Abraham I]

HCTL is now set based on ios.signal_voltage set by mmc core and not
hardcoded to 3V0 if OMAP_HSMMC_SUPPORTS_DUAL_VOLT is set. If
OMAP_HSMMC_SUPPORTS_DUAL_VOLT is set, it means HCTL can be set to either
3V0 or 1V8. And it should be set to 3V0 or 1V8 depending on
ios.signal_voltage.
Also it is now set on power mode status being changed to MMC_POWER_ON.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 42954efe12f7..893d1624a5a3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -229,6 +229,7 @@ struct omap_mmc_of_data {
 };
 
 static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host);
+static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov);
 
 static int omap_hsmmc_card_detect(struct device *dev)
 {
@@ -1664,6 +1665,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc, 
struct mmc_ios *ios)
omap_hsmmc_set_power(host, 1, ios->vdd);
break;
case MMC_POWER_ON:
+   omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
do_send_init_stream = 1;
break;
}
@@ -1824,17 +1826,12 @@ static void omap_hsmmc_set_capabilities(struct 
omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host->base, CAPA, val);
 }
 
-static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
+static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov)
 {
u32 hctl, value;
 
-   /* Only MMC1 supports 3.0V */
-   if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
-   hctl = SDVS30;
-   else
-   hctl = SDVS18;
-
value = OMAP_HSMMC_READ(host->base, HCTL) & ~SDVS_MASK;
+   hctl = (iov == MMC_SIGNAL_VOLTAGE_180) ? SDVS18 : SDVS30;
OMAP_HSMMC_WRITE(host->base, HCTL, value | hctl);
 
/* Set SD bus power bit */
@@ -2144,7 +2141,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
mmc->pm_caps |= mmc_pdata(host)->pm_caps;
 
omap_hsmmc_set_capabilities(host);
-   omap_hsmmc_conf_bus_power(host);
 
host->rx_chan = dma_request_chan(>dev, "rx");
if (IS_ERR(host->rx_chan)) {
@@ -2281,6 +2277,7 @@ static int omap_hsmmc_suspend(struct device *dev)
 static int omap_hsmmc_resume(struct device *dev)
 {
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+   struct mmc_ios *ios;
 
if (!host)
return 0;
@@ -2290,8 +2287,9 @@ static int omap_hsmmc_resume(struct device *dev)
if (host->dbclk)
clk_prepare_enable(host->dbclk);
 
+   ios = >mmc->ios;
if (!(host->mmc->pm_flags & MMC_PM_KEEP_POWER))
-   omap_hsmmc_conf_bus_power(host);
+   omap_hsmmc_conf_bus_power(host, ios->signal_voltage);
 
omap_hsmmc_protect_card(host);
pm_runtime_mark_last_busy(host->dev);
-- 
2.11.0

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

[PATCH 09/41] mmc: host: omap_hsmmc: Add software timer when timeout greater than hardware capablility

[Kishon Vijay Abraham I]

From: Mugunthan V N 

DRA7 Errata No i834: When using high speed HS200 and SDR104
cards, the functional clock for MMC module will be 192MHz.
At this frequency, the maximum obtainable timeout (DTO =0xE)
in hardware is (1/192MHz)*2^27 = 700ms. Commands taking longer
than 700ms will be affected by this small window frame and
will be timing out frequently even without a genune timeout
from the card. Workarround for this errata is use a software
timer instead of hardware timer to provide the delay requested
by the upper layer

So adding a software timer as a work around for the errata.
Instead of using software timeout only for larger delays requested
when using HS200/SDR104 cards which results in hardware and
software timer race conditions, so move all the timeout request
to use software timer when HS200/SDR104 card is connected and
use hardware timer when other type cards are connected.

Also start the software timer after queueing to DMA to ensure
we are more likely to expire within correct limits. To be ever
more sure that we won't expire this soft timer too early, we're
adding a 100ns slack to the data timeout requested by the
upper layer.

[r...@ti.com: fix compiler warning in sw timeout function and
use sw timeout for busy timeout]
Signed-off-by: Ravikumar Kattekola 
Signed-off-by: Mugunthan V N 
[kis...@ti.com: Fix the timeout value to account for the entire
transfer to complete here.]
Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 126 --
 1 file changed, 109 insertions(+), 17 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 30cd2be7141c..9ac18521e097 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -185,6 +185,11 @@
 #define PSTATE_DLEV(0xF << 20)
 #define PSTATE_DLEV_DAT0   (0x1 << 20)
 
+#define MMC_BLOCK_TRANSFER_TIME_NS(blksz, bus_width, freq) \
+  ((unsigned long long)\
+  (2 * (((blksz) * NSEC_PER_SEC *  \
+  (8 / (bus_width))) / (freq
+
 /*
  * One controller can have multiple slots, like on some omap boards using
  * omap.c controller driver. Luckily this is not currently done on any known
@@ -250,6 +255,8 @@ struct omap_hsmmc_host {
struct  omap_hsmmc_platform_data*pdata;
 
boolis_tuning;
+   struct timer_list   timer;
+   unsigned long long  data_timeout;
 
/* return MMC cover switch state, can be NULL if not supported.
 *
@@ -642,8 +649,8 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host 
*host,
if (host->use_dma)
irq_mask &= ~(BRR_EN | BWR_EN);
 
-   /* Disable timeout for erases */
-   if (cmd->opcode == MMC_ERASE)
+   /* Disable timeout for erases or when using software timeout */
+   if (cmd && (cmd->opcode == MMC_ERASE || host->data_timeout))
irq_mask &= ~DTO_EN;
 
if (host->flags & CLKEXTFREE_ENABLED)
@@ -1250,8 +1257,16 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
}
 
OMAP_HSMMC_WRITE(host->base, STAT, status);
-   if (end_cmd || ((status & CC_EN) && host->cmd))
+   if (end_cmd || ((status & CC_EN) && host->cmd)) {
omap_hsmmc_cmd_done(host, host->cmd);
+   if (host->data_timeout) {
+   unsigned long timeout;
+
+   timeout = jiffies +
+ nsecs_to_jiffies(host->data_timeout);
+   mod_timer(>timer, timeout);
+   }
+   }
if ((end_trans || (status & TC_EN)) && host->mrq)
omap_hsmmc_xfer_done(host, data);
 }
@@ -1265,7 +1280,19 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
 
status = OMAP_HSMMC_READ(host->base, STAT);
+
while (status & (INT_EN_MASK | CIRQ_EN)) {
+   /*
+* During a successful bulk data transfer command-completion
+* interrupt and transfer-completion interrupt will be
+* generated, but software-timeout timer should be deleted
+* only on non-cc interrupts (transfer complete or error)
+*/
+   if (host->data_timeout && (status & (~CC_EN))) {
+   del_timer(>timer);
+   host->data_timeout = 0;
+   }
+
if (host->req_in_progress)
omap_hsmmc_do_irq(host, status);
 
@@ -1279,6 +1306,25 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+static void omap_hsmmc_soft_timeout(unsigned long data)
+{
+   struct omap_hsmmc_host *host = 

[PATCH 05/41] mmc: host: omap_hsmmc: Set clk rate to the max frequency

[Kishon Vijay Abraham I]

Set the clock rate of the functional clock to the max frequency
that is passed to the driver either using pdata or dt.

Also remove unnecessary setting of host->fclk to NULL.

This is in preparation for supporting high frequency modes
of operation.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4dbf75ad2376..77be27c8e18c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2244,22 +2244,29 @@ static int omap_hsmmc_probe(struct platform_device 
*pdev)
 
mmc->ops= _hsmmc_ops;
 
-   mmc->f_min = OMAP_MMC_MIN_CLOCK;
-
-   if (pdata->max_freq > 0)
-   mmc->f_max = pdata->max_freq;
-   else if (mmc->f_max == 0)
-   mmc->f_max = OMAP_MMC_MAX_CLOCK;
-
spin_lock_init(>irq_lock);
 
host->fclk = devm_clk_get(>dev, "fck");
if (IS_ERR(host->fclk)) {
ret = PTR_ERR(host->fclk);
-   host->fclk = NULL;
goto err1;
}
 
+   mmc->f_min = OMAP_MMC_MIN_CLOCK;
+   if (pdata->max_freq > 0)
+   mmc->f_max = pdata->max_freq;
+
+   if (mmc->f_max) {
+   ret = clk_set_rate(host->fclk, mmc->f_max);
+   if (ret) {
+   dev_err(>dev, "failed to set clock to %d\n",
+   mmc->f_max);
+   goto err1;
+   }
+   } else {
+   mmc->f_max = OMAP_MMC_MAX_CLOCK;
+   }
+
if (host->pdata->controller_flags & OMAP_HSMMC_BROKEN_MULTIBLOCK_READ) {
dev_info(>dev, "multiblock reads disabled due to 35xx 
erratum 2.1.1.128; MMC read performance may suffer\n");
omap_hsmmc_ops.multi_io_quirk = omap_hsmmc_multi_io_quirk;
-- 
2.11.0

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

[PATCH 12/41] mmc: host: omap_hsmmc: Fix error path sequence

[Kishon Vijay Abraham I]

Fix the error path sequence so that clk_disable, runtime_disable etc
are done in the reverse order of how they were enabled.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8114b8b73491..b28f0e9631ce 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2602,16 +2602,16 @@ static int omap_hsmmc_probe(struct platform_device 
*pdev)
 err_slot_name:
mmc_remove_host(mmc);
 err_irq:
-   device_init_wakeup(>dev, false);
if (!IS_ERR_OR_NULL(host->tx_chan))
dma_release_channel(host->tx_chan);
if (!IS_ERR_OR_NULL(host->rx_chan))
dma_release_channel(host->rx_chan);
+   if (host->dbclk)
+   clk_disable_unprepare(host->dbclk);
pm_runtime_dont_use_autosuspend(host->dev);
pm_runtime_put_sync(host->dev);
pm_runtime_disable(host->dev);
-   if (host->dbclk)
-   clk_disable_unprepare(host->dbclk);
+   device_init_wakeup(>dev, false);
 err1:
 err_gpio:
mmc_free_host(mmc);
-- 
2.11.0

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

[PATCH 10/41] mmc: host: omap_hsmmc: Prepare *set_timing() to be used for iodelay setting

[Kishon Vijay Abraham I]

No functional change. Add separate case statements for certain timing
like MMC_TIMING_SD_HS and MMC_TIMING_MMC_HS even though AC12_UHSMC_RES
has to be written to the AC12 register (same as for default modes).
Also have separate case sections for MMC_TIMING_UHS_SDR104 and
MMC_TIMING_UHS_HS200 even though the same UHSMC value has to be written
to the AC12 register. This is in preparation for setting iodelay
values.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9ac18521e097..7088a88074a8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1737,6 +1737,8 @@ static void omap_hsmmc_set_timing(struct omap_hsmmc_host 
*host)
val &= ~AC12_UHSMC_MASK;
switch (ios->timing) {
case MMC_TIMING_UHS_SDR104:
+   val |= AC12_UHSMC_SDR104;
+   break;
case MMC_TIMING_MMC_HS200:
val |= AC12_UHSMC_SDR104;
break;
@@ -1752,6 +1754,13 @@ static void omap_hsmmc_set_timing(struct omap_hsmmc_host 
*host)
case MMC_TIMING_UHS_SDR12:
val |= AC12_UHSMC_SDR12;
break;
+   case MMC_TIMING_SD_HS:
+   case MMC_TIMING_MMC_HS:
+   val |= AC12_UHSMC_RES;
+   break;
+   case MMC_TIMING_MMC_DDR52:
+   val |= AC12_UHSMC_RES;
+   break;
default:
val |= AC12_UHSMC_RES;
break;
-- 
2.11.0

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

[PATCH 11/41] mmc: host: omap_hsmmc: Add new compatible string to support dra7

[Kishon Vijay Abraham I]

Add a new compatible string "ti,dra7-hsmmc" to support
dra7 and dra72 controllers. Also create a new controller flag
"OMAP_HSMMC_REQUIRE_IODELAY" to specify all controllers that use
"ti,dra7-hsmmc" require iodealy configuration to be set.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt |  1 +
 drivers/mmc/host/omap_hsmmc.c   | 10 ++
 include/linux/platform_data/hsmmc-omap.h|  1 +
 3 files changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 74166a0d460d..258e25af10f7 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -12,6 +12,7 @@ Required properties:
  Should be "ti,omap3-hsmmc", for OMAP3 controllers
  Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
  Should be "ti,omap4-hsmmc", for OMAP4 controllers
+ Should be "ti,dra7-hsmmc", for dra7 and dra72 controllers
  Should be "ti,am33xx-hsmmc", for AM335x controllers
 - ti,hwmods: Must be "mmc", n is controller instance starting 1
 
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7088a88074a8..8114b8b73491 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2314,6 +2314,12 @@ static const struct omap_mmc_of_data am33xx_mmc_of_data 
= {
.controller_flags = OMAP_HSMMC_SWAKEUP_MISSING,
 };
 
+static const struct omap_mmc_of_data dra7_mmc_of_data = {
+   .reg_offset = 0x100,
+   .controller_flags = OMAP_HSMMC_SWAKEUP_MISSING |
+   OMAP_HSMMC_REQUIRE_IODELAY,
+};
+
 static const struct of_device_id omap_mmc_of_match[] = {
{
.compatible = "ti,omap2-hsmmc",
@@ -2333,6 +2339,10 @@ static const struct of_device_id omap_mmc_of_match[] = {
.compatible = "ti,am33xx-hsmmc",
.data = _mmc_of_data,
},
+   {
+   .compatible = "ti,dra7-hsmmc",
+   .data = _mmc_of_data,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, omap_mmc_of_match);
diff --git a/include/linux/platform_data/hsmmc-omap.h 
b/include/linux/platform_data/hsmmc-omap.h
index 8e981be2e2c2..21832a357654 100644
--- a/include/linux/platform_data/hsmmc-omap.h
+++ b/include/linux/platform_data/hsmmc-omap.h
@@ -27,6 +27,7 @@
 #define OMAP_HSMMC_SUPPORTS_DUAL_VOLT  BIT(0)
 #define OMAP_HSMMC_BROKEN_MULTIBLOCK_READ  BIT(1)
 #define OMAP_HSMMC_SWAKEUP_MISSING BIT(2)
+#define OMAP_HSMMC_REQUIRE_IODELAY BIT(3)
 
 struct omap_hsmmc_dev_attr {
u8 flags;
-- 
2.11.0

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

[PATCH 21/41] ARM: dts: dra72-evm-common: Correct vmmc-supply for mmc2

[Kishon Vijay Abraham I]

From: Ravikumar Kattekola 

On dra72/dra71 evms, mmc2 vdd/ios are connected to a common 1.8V supply
not 3.3V. Also the regulator that supplies 1.8V is different on dra71-evm
so move the supply property from common dtsi to evm specific dts files.

Fixes: a4240d3af677 ("ARM: dts: Add support for dra72-evm rev C (SR2.0)")
Signed-off-by: Ravikumar Kattekola 
Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra71-evm.dts | 14 ++
 arch/arm/boot/dts/dra72-evm-common.dtsi |  2 --
 arch/arm/boot/dts/dra72-evm-revc.dts| 14 ++
 arch/arm/boot/dts/dra72-evm.dts | 14 ++
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index 4d57a55473af..c7a56b6263a6 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -32,6 +32,16 @@
  300 0x1>;
};
 
+   evm_1v8_sw: fixedregulator-evm_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "evm_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_buck0_reg>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
poweroff: gpio-poweroff {
compatible = "gpio-poweroff";
gpios = < 30 GPIO_ACTIVE_HIGH>;
@@ -165,6 +175,10 @@
vmmc_aux-supply = <_sd_1v8_3v3>;
 };
 
+ {
+   vmmc-supply = <_1v8_sw>;
+};
+
  {
mode-gpios = <_gpio_21 4 GPIO_ACTIVE_LOW>,
 <_hdmi 9 GPIO_ACTIVE_LOW>, /* P11 */
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi 
b/arch/arm/boot/dts/dra72-evm-common.dtsi
index ad24544adf0f..d97370217eff 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -418,8 +418,6 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
-
-   vmmc-supply = <_3v3_sw>;
bus-width = <8>;
ti,non-removable;
max-frequency = <19200>;
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index 58a2e6599ea7..40a399735533 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -15,6 +15,16 @@
device_type = "memory";
reg = <0x0 0x8000 0x0 0x8000>; /* 2GB */
};
+
+   evm_1v8_sw: fixedregulator-evm_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "evm_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_reg>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
  {
@@ -86,3 +96,7 @@
  {
vmmc_aux-supply = <_reg>;
 };
+
+ {
+   vmmc-supply = <_1v8_sw>;
+};
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 1c570236a1a0..b25e7c67badf 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -13,6 +13,16 @@
device_type = "memory";
reg = <0x0 0x8000 0x0 0x4000>; /* 1024 MB */
};
+
+   evm_1v8_sw: fixedregulator-evm_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "evm_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   vin-supply = <_reg>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
  {
@@ -47,3 +57,7 @@
  {
vmmc_aux-supply = <_reg>;
 };
+
+ {
+   vmmc-supply = <_1v8_sw>;
+};
-- 
2.11.0

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

[PATCH 25/41] ARM: dts: dra7-evm: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

Include dra74x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for dra74 SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in dra7-evm.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7-evm.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index fbcb3199defd..64955e8f06d2 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -8,6 +8,7 @@
 /dts-v1/;
 
 #include "dra74x.dtsi"
+#include "dra74x-mmc-iodelay.dtsi"
 #include 
 #include 
 #include 
@@ -451,6 +452,16 @@
 * is always hardwired.
 */
cd-gpios = < 27 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", 
"ddr50-rev11", "sdr104-rev11", "ddr50", "sdr104";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_sdr12>;
+   pinctrl-3 = <_pins_sdr25>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50 _iodelay_ddr_rev11_conf>;
+   pinctrl-6 = <_pins_sdr104 _iodelay_sdr104_rev11_conf>;
+   pinctrl-7 = <_pins_ddr50 _iodelay_ddr_rev20_conf>;
+   pinctrl-8 = <_pins_sdr104 _iodelay_sdr104_rev20_conf>;
 };
 
  {
@@ -459,6 +470,13 @@
pinctrl-0 = <_pins_default>;
vmmc-supply = <_1v8_sw>;
bus-width = <8>;
+   pinctrl-names = "default", "hs", "ddr_1_8v-rev11", "ddr_1_8v", 
"hs200_1_8v-rev11", "hs200_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_1_8v_rev11 
_iodelay_ddr_1_8v_rev11_conf>;
+   pinctrl-3 = <_pins_ddr_rev20>;
+   pinctrl-4 = <_pins_hs200 _iodelay_hs200_rev11_conf>;
+   pinctrl-5 = <_pins_hs200 _iodelay_hs200_rev20_conf>;
 };
 
  {
-- 
2.11.0

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

[PATCH 16/41] mmc: omap_hsmmc: Support non-1.8V IO controllers

[Kishon Vijay Abraham I]

From: Sekhar Nori 

OMAP HSMMC driver assumes that if the controller does
not support dual-volt, then it supports only 1.8V IO.

This assumption can be incorrect. For example, on K2G
MMC0 supports 3.3V IO only. AM57x Beagle-x15 and IDK
boards support only 3.3V IO on eMMC interface.

Support device-tree property "no-1-8-v" to for
controllers which are not dual-voltage and do not
support 1.8V IO.

Note that lack of support for this property has not
led to any known regression in affected platforms so
far. But it will be nice to be in sync with hardware
configuration.

Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/mmc/host/omap_hsmmc.c| 15 ---
 include/linux/platform_data/hsmmc-omap.h |  5 +
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c6e3efb0f8fb..7c555e3ecce8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -865,6 +865,9 @@ static int omap_hsmmc_context_restore(struct 
omap_hsmmc_host *host)
else
hctl = SDVS30;
capa = VS30 | VS18;
+   } else if (host->pdata->controller_flags & OMAP_HSMMC_NO_1_8_V) {
+   hctl = SDVS30;
+   capa = VS30;
} else {
hctl = SDVS18;
capa = VS18;
@@ -2121,11 +2124,14 @@ static void omap_hsmmc_set_capabilities(struct 
omap_hsmmc_host *host)
 
val = OMAP_HSMMC_READ(host->base, CAPA);
 
-   /* Only MMC1 supports 3.0V */
-   if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT)
+   if (host->pdata->controller_flags & OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
val |= (VS30 | VS18);
-   else
+   } else if (host->pdata->controller_flags & OMAP_HSMMC_NO_1_8_V) {
+   val |= VS30;
+   val &= ~VS18;
+   } else {
val |= VS18;
+   }
 
OMAP_HSMMC_WRITE(host->base, CAPA, val);
 }
@@ -2567,6 +2573,9 @@ static struct omap_hsmmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, "ti,dual-volt", NULL))
pdata->controller_flags |= OMAP_HSMMC_SUPPORTS_DUAL_VOLT;
 
+   if (of_find_property(np, "no-1-8-v", NULL))
+   pdata->controller_flags |= OMAP_HSMMC_NO_1_8_V;
+
pdata->gpio_cd = -EINVAL;
pdata->gpio_cod = -EINVAL;
pdata->gpio_wp = -EINVAL;
diff --git a/include/linux/platform_data/hsmmc-omap.h 
b/include/linux/platform_data/hsmmc-omap.h
index c3f2a34db97a..d7be21dc9ffd 100644
--- a/include/linux/platform_data/hsmmc-omap.h
+++ b/include/linux/platform_data/hsmmc-omap.h
@@ -23,12 +23,17 @@
  *for example Advisory 2.1.1.128 "MMC: Multiple Block Read
  *Operation Issue" in _OMAP3530/3525/3515/3503 Silicon Errata_
  *Revision F (October 2010) (SPRZ278F).
+ *
+ * OMAP_HSMMC_NO_1_8_V: The controller does not support 1.8V IO voltage
+ *irrespective of what the capability states.
+ *
  */
 #define OMAP_HSMMC_SUPPORTS_DUAL_VOLT  BIT(0)
 #define OMAP_HSMMC_BROKEN_MULTIBLOCK_READ  BIT(1)
 #define OMAP_HSMMC_SWAKEUP_MISSING BIT(2)
 #define OMAP_HSMMC_REQUIRE_IODELAY BIT(3)
 #define OMAP_HSMMC_HAS_HWPARAM BIT(4)
+#define OMAP_HSMMC_NO_1_8_VBIT(5)
 
 struct omap_hsmmc_dev_attr {
u8 flags;
-- 
2.11.0

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

[PATCH 22/41] ARM: dts: Add dra7 iodelay configuration

[Kishon Vijay Abraham I]

From: Tony Lindgren 

Add dra7 iodelay configuration.

Signed-off-by: Tony Lindgren 
Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/dra7.dtsi   | 8 
 include/dt-bindings/pinctrl/dra.h | 3 +++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 57892f264cea..5a262e1a0313 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -418,6 +418,14 @@
reg = <0x40d0 0x100>;
};
 
+   dra7_iodelay_core: padconf@4844a000 {
+   compatible = "ti,dra7-iodelay";
+   reg = <0x4844a000 0x0d1c>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   #pinctrl-cells = <2>;
+   };
+
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
diff --git a/include/dt-bindings/pinctrl/dra.h 
b/include/dt-bindings/pinctrl/dra.h
index 5c75e80915fc..18ec5df5a581 100644
--- a/include/dt-bindings/pinctrl/dra.h
+++ b/include/dt-bindings/pinctrl/dra.h
@@ -73,5 +73,8 @@
  */
 #define DRA7XX_CORE_IOPAD(pa, val) (((pa) & 0x) - 0x3400) (val)
 
+/* DRA7 IODELAY configuration parameters */
+#define A_DELAY_PS(val)((val) & 0x)
+#define G_DELAY_PS(val)((val) & 0x)
 #endif
 
-- 
2.11.0

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

[PATCH 29/41] ARM: dts: am572x-idk: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

Include dra74x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for dra74x SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in am572x-idk.dts.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am572x-idk.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index 1c112eb25db4..79fac687428c 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include "am57xx-idk-common.dtsi"
+#include "dra74x-mmc-iodelay.dtsi"
 
 / {
model = "TI AM5728 IDK";
@@ -67,6 +68,24 @@
};
 };
 
+ {
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_sdr12>;
+   pinctrl-3 = <_pins_sdr25>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50 _iodelay_ddr_rev20_conf>;
+   pinctrl-6 = <_pins_sdr104 _iodelay_sdr104_rev20_conf>;
+};
+
+ {
+   pinctrl-names = "default", "hs", "ddr_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_rev20>;
+};
+
 _dwc3_2 {
extcon = <_usb2>;
 };
-- 
2.11.0

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

[PATCH 28/41] ARM: dts: am571x-idk: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

Include dra72x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for dra72 SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in am571x-idk.dts.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am571x-idk.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
index e685c8e811b0..875291d1bdd7 100644
--- a/arch/arm/boot/dts/am571x-idk.dts
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include "am57xx-idk-common.dtsi"
+#include "dra72x-mmc-iodelay.dtsi"
 
 / {
model = "TI AM5718 IDK";
@@ -72,3 +73,21 @@
id-gpio = < 7 GPIO_ACTIVE_HIGH>;
vbus-gpio = < 22 GPIO_ACTIVE_HIGH>;
 };
+
+ {
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_sdr12>;
+   pinctrl-3 = <_pins_sdr25>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50_rev20 _iodelay_ddr50_conf>;
+   pinctrl-6 = <_pins_sdr104 _iodelay_sdr104_rev20_conf>;
+};
+
+ {
+   pinctrl-names = "default", "hs", "ddr_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_rev20 _iodelay_ddr_conf>;
+};
-- 
2.11.0

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

[PATCH 13/41] mmc: host: omap_hsmmc: Add support to set IODELAY values

[Kishon Vijay Abraham I]

The data manual of J6/J6 Eco recommends to set different IODELAY values
depending on the mode in which the MMC/SD is enumerated in order to
ensure IO timings are met.

Add support to set the IODELAY values depending on the various MMC
modes using the pinctrl APIs.

Signed-off-by: Kishon Vijay Abraham I 
[nsek...@ti.com: introduce OMAP_HSMMC_SETUP_PINCTRL()]
Signed-off-by: Sekhar Nori 
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |   5 +
 drivers/mmc/host/omap_hsmmc.c  | 124 -
 include/linux/platform_data/hsmmc-omap.h   |   3 +
 3 files changed, 129 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 258e25af10f7..dcf0b777c031 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,6 +20,11 @@ Optional properties:
 ti,dual-volt: boolean, supports dual voltage cards
 -supply: phandle to the regulator device tree node
 "supply-name" examples are "vmmc", "vmmc_aux" etc
+pinctrl-names: Should be a list of pinctrl state names and can be "sdr104",
+"hs200_1_8v", "ddr50", "sdr50", "sdr25", "sdr12", "hs", "ddr_1_8v" or
+"default".
+pinctrl-: Phandle referencing pin configuration of the sd/emmc controller.
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
 ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b28f0e9631ce..7271c7e3144c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -258,6 +258,18 @@ struct omap_hsmmc_host {
struct timer_list   timer;
unsigned long long  data_timeout;
 
+   struct pinctrl  *pinctrl;
+   struct pinctrl_state*pinctrl_state;
+   struct pinctrl_state*default_pinctrl_state;
+   struct pinctrl_state*sdr104_pinctrl_state;
+   struct pinctrl_state*hs200_1_8v_pinctrl_state;
+   struct pinctrl_state*ddr50_pinctrl_state;
+   struct pinctrl_state*sdr50_pinctrl_state;
+   struct pinctrl_state*sdr25_pinctrl_state;
+   struct pinctrl_state*sdr12_pinctrl_state;
+   struct pinctrl_state*hs_pinctrl_state;
+   struct pinctrl_state*ddr_1_8v_pinctrl_state;
+
/* return MMC cover switch state, can be NULL if not supported.
 *
 * possible return values:
@@ -1729,6 +1741,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
struct mmc_request *req)
 static void omap_hsmmc_set_timing(struct omap_hsmmc_host *host)
 {
u32 val;
+   int ret;
+   struct pinctrl_state *pinctrl_state;
struct mmc_ios *ios = >mmc->ios;
 
omap_hsmmc_stop_clock(host);
@@ -1738,35 +1752,54 @@ static void omap_hsmmc_set_timing(struct 
omap_hsmmc_host *host)
switch (ios->timing) {
case MMC_TIMING_UHS_SDR104:
val |= AC12_UHSMC_SDR104;
+   pinctrl_state = host->sdr104_pinctrl_state;
break;
case MMC_TIMING_MMC_HS200:
val |= AC12_UHSMC_SDR104;
+   pinctrl_state = host->hs200_1_8v_pinctrl_state;
break;
case MMC_TIMING_UHS_DDR50:
val |= AC12_UHSMC_DDR50;
+   pinctrl_state = host->ddr50_pinctrl_state;
break;
case MMC_TIMING_UHS_SDR50:
val |= AC12_UHSMC_SDR50;
+   pinctrl_state = host->sdr50_pinctrl_state;
break;
case MMC_TIMING_UHS_SDR25:
val |= AC12_UHSMC_SDR25;
+   pinctrl_state = host->sdr25_pinctrl_state;
break;
case MMC_TIMING_UHS_SDR12:
val |= AC12_UHSMC_SDR12;
+   pinctrl_state = host->sdr12_pinctrl_state;
break;
case MMC_TIMING_SD_HS:
case MMC_TIMING_MMC_HS:
val |= AC12_UHSMC_RES;
+   pinctrl_state = host->hs_pinctrl_state;
break;
case MMC_TIMING_MMC_DDR52:
val |= AC12_UHSMC_RES;
+   pinctrl_state = host->ddr_1_8v_pinctrl_state;
break;
default:
val |= AC12_UHSMC_RES;
+   pinctrl_state = host->default_pinctrl_state;
break;
}
OMAP_HSMMC_WRITE(host->base, AC12, val);
 
+   if (host->pdata->controller_flags & OMAP_HSMMC_REQUIRE_IODELAY) {
+   ret = pinctrl_select_state(host->pinctrl, pinctrl_state);
+   if (ret) {
+   dev_err(mmc_dev(host->mmc),
+   "failed to select pinctrl state\n");
+   return;
+   }
+   

[PATCH 14/41] mmc: host: omap_hsmmc: Remove *use_dma* member

[Kishon Vijay Abraham I]

omap_hsmmc doesn't support polled I/O. So remove *use_dma*
which is always set to '1'.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 37 -
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7271c7e3144c..90bf097484ae 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -238,7 +238,7 @@ struct omap_hsmmc_host {
u32 capa;
int irq;
int wake_irq;
-   int use_dma, dma_ch;
+   int dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
int response_busy;
@@ -658,8 +658,8 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host 
*host,
 */
irq_mask &= ~(DCRC_EN | DEB_EN);
 
-   if (host->use_dma)
-   irq_mask &= ~(BRR_EN | BWR_EN);
+   /* BRR and BWR need not be enabled for DMA */
+   irq_mask &= ~(BRR_EN | BWR_EN);
 
/* Disable timeout for erases or when using software timeout */
if (cmd && (cmd->opcode == MMC_ERASE || host->data_timeout))
@@ -1012,8 +1012,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, 
struct mmc_command *cmd,
(cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200))
cmdreg |= DP_SELECT | DDIR;
 
-   if (host->use_dma)
-   cmdreg |= DMAE;
+   cmdreg |= DMAE;
 
host->req_in_progress = 1;
host->last_cmd = cmd->opcode;
@@ -1040,7 +1039,7 @@ static void omap_hsmmc_request_done(struct 
omap_hsmmc_host *host, struct mmc_req
 
omap_hsmmc_disable_irq(host);
/* Do not complete the request if DMA is still in progress */
-   if (mrq->data && host->use_dma && dma_ch != -1)
+   if (mrq->data && dma_ch != -1)
return;
host->mrq = NULL;
mmc_request_done(host->mmc, mrq);
@@ -1127,7 +1126,7 @@ static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host 
*host, int errno)
host->dma_ch = -1;
spin_unlock_irqrestore(>irq_lock, flags);
 
-   if (host->use_dma && dma_ch != -1) {
+   if (dma_ch != -1) {
struct dma_chan *chan = omap_hsmmc_get_dma_chan(host, 
host->data);
 
dmaengine_terminate_all(chan);
@@ -1645,12 +1644,10 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host *host, 
struct mmc_request *req)
return 0;
}
 
-   if (host->use_dma) {
-   ret = omap_hsmmc_setup_dma_transfer(host, req);
-   if (ret != 0) {
-   dev_err(mmc_dev(host->mmc), "MMC start dma failure\n");
-   return ret;
-   }
+   ret = omap_hsmmc_setup_dma_transfer(host, req);
+   if (ret != 0) {
+   dev_err(mmc_dev(host->mmc), "MMC start dma failure\n");
+   return ret;
}
return 0;
 }
@@ -1661,7 +1658,7 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc, 
struct mmc_request *mrq,
struct omap_hsmmc_host *host = mmc_priv(mmc);
struct mmc_data *data = mrq->data;
 
-   if (host->use_dma && data->host_cookie) {
+   if (data->host_cookie) {
struct dma_chan *c = omap_hsmmc_get_dma_chan(host, data);
 
dma_unmap_sg(c->device->dev, data->sg, data->sg_len,
@@ -1673,19 +1670,18 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc, 
struct mmc_request *mrq,
 static void omap_hsmmc_pre_req(struct mmc_host *mmc, struct mmc_request *mrq)
 {
struct omap_hsmmc_host *host = mmc_priv(mmc);
+   struct dma_chan *c = NULL;
 
if (mrq->data->host_cookie) {
mrq->data->host_cookie = 0;
return ;
}
 
-   if (host->use_dma) {
-   struct dma_chan *c = omap_hsmmc_get_dma_chan(host, mrq->data);
+   c = omap_hsmmc_get_dma_chan(host, mrq->data);
 
-   if (omap_hsmmc_pre_dma_transfer(host, mrq->data,
-   >next_data, c))
-   mrq->data->host_cookie = 0;
-   }
+   if (omap_hsmmc_pre_dma_transfer(host, mrq->data,
+   >next_data, c))
+   mrq->data->host_cookie = 0;
 }
 
 /*
@@ -2547,7 +2543,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host->mmc   = mmc;
host->pdata = pdata;
host->dev   = >dev;
-   host->use_dma   = 1;
host->dma_ch= -1;
host->irq   = irq;
host->mapbase   = res->start + pdata->reg_offset;
-- 
2.11.0

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

[PATCH 15/41] mmc: host: omap_hsmmc: Enable ADMA2

[Kishon Vijay Abraham I]

omap hsmmc host controller has ADMA2 feature. Enable it here
for better read and write throughput.

Signed-off-by: Kishon Vijay Abraham I 
[misael.lo...@ti.com: handle ADMA errors]
Signed-off-by: Misael Lopez Cruz 
[nsek...@ti.com: restore adma settings after context loss]
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c| 307 +++
 include/linux/platform_data/hsmmc-omap.h |   1 +
 2 files changed, 271 insertions(+), 37 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 90bf097484ae..c6e3efb0f8fb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -48,6 +48,9 @@
 #include 
 
 /* OMAP HSMMC Host Controller Registers */
+#define OMAP_HSMMC_HL_REV  0x
+#define OMAP_HSMMC_HL_HWINFO   0x0004
+#define OMAP_HSMMC_HL_SYSCONFIG0x0010
 #define OMAP_HSMMC_SYSSTATUS   0x0014
 #define OMAP_HSMMC_CON 0x002C
 #define OMAP_HSMMC_DLL 0x0034
@@ -69,7 +72,10 @@
 #define OMAP_HSMMC_AC120x013C
 #define OMAP_HSMMC_CAPA0x0140
 #define OMAP_HSMMC_CAPA2   0x0144
+#define OMAP_HSMMC_ADMAES  0x0154
+#define OMAP_HSMMC_ADMASAL 0x0158
 
+#define MADMA_EN   (1 << 0)
 #define VS18   (1 << 26)
 #define VS30   (1 << 25)
 #define HSS(1 << 21)
@@ -79,6 +85,7 @@
 #define SDVS_MASK  0x0E00
 #define SDVSCLR0xF1FF
 #define SDVSDET0x0400
+#define DMA_SELECT (2 << 3)
 #define AUTOIDLE   0x1
 #define SDBP   (1 << 8)
 #define DTO0xe
@@ -100,6 +107,7 @@
 #define FOUR_BIT   (1 << 1)
 #define HSPE   (1 << 2)
 #define IWE(1 << 24)
+#define DMA_MASTER (1 << 20)
 #define DDR(1 << 19)
 #define CLKEXTFREE (1 << 16)
 #define CTPL   (1 << 11)
@@ -153,10 +161,11 @@
 #define DCRC_EN(1 << 21)
 #define DEB_EN (1 << 22)
 #define ACE_EN (1 << 24)
+#define ADMAE_EN   (1 << 25)
 #define CERR_EN(1 << 28)
 #define BADA_EN(1 << 29)
 
-#define INT_EN_MASK (BADA_EN | CERR_EN | ACE_EN | DEB_EN | DCRC_EN |\
+#define INT_EN_MASK (BADA_EN | CERR_EN | ADMAE_EN | ACE_EN | DEB_EN | DCRC_EN 
|\
DTO_EN | CIE_EN | CEB_EN | CCRC_EN | CTO_EN | \
BRR_EN | BWR_EN | TC_EN | CC_EN)
 
@@ -206,6 +215,33 @@
 #define OMAP_HSMMC_WRITE(base, reg, val) \
__raw_writel((val), (base) + OMAP_HSMMC_##reg)
 
+struct omap_hsmmc_adma_desc {
+   u8 attr;
+   u8 reserved;
+   u16 len;
+   u32 addr;
+} __packed;
+
+#define ADMA_DESC_SIZE 8
+
+#define ADMA_MAX_LEN   65532
+
+/* Decriptor table defines */
+#define ADMA_DESC_ATTR_VALID   BIT(0)
+#define ADMA_DESC_ATTR_END BIT(1)
+#define ADMA_DESC_ATTR_INT BIT(2)
+#define ADMA_DESC_ATTR_ACT1BIT(4)
+#define ADMA_DESC_ATTR_ACT2BIT(5)
+
+#define ADMA_DESC_TRANSFER_DATAADMA_DESC_ATTR_ACT2
+#define ADMA_DESC_LINK_DESC(ADMA_DESC_ATTR_ACT1 | ADMA_DESC_ATTR_ACT2)
+
+/* ADMA error status */
+#define AES_MASK   0x3
+#define ST_STOP0x0
+#define ST_FDS 0x1
+#define ST_TFR 0x3
+
 struct omap_hsmmc_next {
unsigned intdma_len;
s32 cookie;
@@ -239,6 +275,7 @@ struct omap_hsmmc_host {
int irq;
int wake_irq;
int dma_ch;
+   int use_adma;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
int response_busy;
@@ -270,6 +307,9 @@ struct omap_hsmmc_host {
struct pinctrl_state*hs_pinctrl_state;
struct pinctrl_state*ddr_1_8v_pinctrl_state;
 
+   struct omap_hsmmc_adma_desc *adma_desc_table;
+   dma_addr_t  adma_desc_table_addr;
+
/* return MMC cover switch state, can be NULL if not supported.
 *
 * possible return values:
@@ -851,6 +891,18 @@ static int omap_hsmmc_context_restore(struct 
omap_hsmmc_host *host)
OMAP_HSMMC_WRITE(host->base, IE, 0);
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
 
+   if (host->use_adma) {
+   u32 val;
+
+   val = OMAP_HSMMC_READ(host->base, CON);
+   val |= DMA_MASTER;
+   OMAP_HSMMC_WRITE(host->base, CON, val);
+
+   val = OMAP_HSMMC_READ(host->base, HCTL);
+   val |= DMA_SELECT;
+   OMAP_HSMMC_WRITE(host->base, HCTL, val);
+   }
+
/* Do not initialize card-specific things if the 

[PATCH 31/41] ARM: dts: dra72-evm-revc: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

Include dra72x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for dra72 SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in dra72-evm-revc.dts.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index 40a399735533..b2f1eedcf60d 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -6,6 +6,7 @@
  * published by the Free Software Foundation.
  */
 #include "dra72-evm-common.dtsi"
+#include "dra72x-mmc-iodelay.dtsi"
 #include 
 
 / {
@@ -94,9 +95,22 @@
 };
 
  {
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_sdr12>;
+   pinctrl-3 = <_pins_sdr25>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50_rev20 _iodelay_ddr50_conf>;
+   pinctrl-6 = <_pins_sdr104 _iodelay_sdr104_rev20_conf>;
vmmc_aux-supply = <_reg>;
 };
 
  {
+   pinctrl-names = "default", "hs", "ddr_1_8v", "hs200_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_rev20 _iodelay_ddr_conf>;
+   pinctrl-3 = <_pins_hs200 _iodelay_hs200_rev20_conf>;
vmmc-supply = <_1v8_sw>;
 };
-- 
2.11.0

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

[PATCH 35/41] ARM: dts: dra7: Add supported MMC/SD modes in MMC dt nodes

[Kishon Vijay Abraham I]

On DRA7 family SoCs, MMC1 controller supports SDR104,
SDR50, DDR50, SDR25 and SDR12 UHS modes (These UHS modes
are not supported in beagle-x15 because it's not possible
to switch IO lines supply voltage to 1.8v).

MMC2 controller supports HS200 and DDR modes. (Since some of the
boards like am57xx-evm reva3, beagle-x15 and am57xx idk has
3.3v line connected to IO lines, HS200 cannot be supported
in these boards).

MMC3 controller supports SDR12, SDR25 and SDR50 modes.

MMC4 controller supports SDR12 and SDR25 modes.

Add these supported modes in device-tree file.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/am571x-idk.dts  |  1 +
 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts |  1 +
 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  6 ++
 arch/arm/boot/dts/am57xx-idk-common.dtsi  |  1 +
 arch/arm/boot/dts/dra7.dtsi   | 14 ++
 5 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
index 875291d1bdd7..bdf39d47948f 100644
--- a/arch/arm/boot/dts/am571x-idk.dts
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -90,4 +90,5 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_hs>;
pinctrl-2 = <_pins_ddr_rev20 _iodelay_ddr_conf>;
+   /delete-property/ mmc-hs200-1_8v;
 };
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
index d1786a8af7ae..e26d3bdda8f2 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
@@ -36,6 +36,7 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_hs>;
pinctrl-2 = <_pins_ddr_3_3v_rev11 
_iodelay_ddr_3_3v_rev11_conf>;
+   /delete-property/ mmc-hs200-1_8v;
 };
 
 /* errata i880 "Ethernet RGMII2 Limited to 10/100 Mbps" */
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index d6689106d2a8..8d9bdf10a7be 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -25,6 +25,11 @@
pinctrl-1 = <_pins_hs>;
 
vmmc-supply = <_reg>;
+   /delete-property/ sd-uhs-sdr104;
+   /delete-property/ sd-uhs-sdr50;
+   /delete-property/ sd-uhs-ddr50;
+   /delete-property/ sd-uhs-sdr25;
+   /delete-property/ sd-uhs-sdr12;
 };
 
  {
@@ -32,6 +37,7 @@
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_hs>;
pinctrl-2 = <_pins_ddr_3_3v_rev11 
_iodelay_ddr_3_3v_rev11_conf>;
+   /delete-property/ mmc-hs200-1_8v;
 };
 
 /* errata i880 "Ethernet RGMII2 Limited to 10/100 Mbps" */
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi 
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 0270b01a8e1d..5d6965ab7339 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -413,6 +413,7 @@
bus-width = <8>;
ti,non-removable;
max-frequency = <9600>;
+   /delete-property/ mmc-hs200-1_8v;
 };
 
  {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 40b9eb96cdeb..b813db662caf 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1046,6 +1046,11 @@
status = "disabled";
pbias-supply = <_mmc_reg>;
max-frequency = <19200>;
+   sd-uhs-sdr104;
+   sd-uhs-sdr50;
+   sd-uhs-ddr50;
+   sd-uhs-sdr25;
+   sd-uhs-sdr12;
};
 
mmc2: mmc@480b4000 {
@@ -1058,6 +1063,10 @@
dma-names = "tx", "rx";
status = "disabled";
max-frequency = <19200>;
+   sd-uhs-sdr25;
+   sd-uhs-sdr12;
+   mmc-hs200-1_8v;
+   mmc-ddr-1_8v;
};
 
mmc3: mmc@480ad000 {
@@ -1071,6 +1080,9 @@
status = "disabled";
/* Errata i887 limits max-frequency of MMC3 to 64 MHz */
max-frequency = <6400>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr50;
};
 
mmc4: mmc@480d1000 {
@@ -1083,6 +1095,8 @@
dma-names = "tx", "rx";
status = "disabled";
max-frequency = <19200>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
};
 
mmu0_dsp1: mmu@40d01000 {
-- 
2.11.0

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

[PATCH 37/41] ARM: dts: am57xx-beagle-x15-common: Set MMC2 IO voltage to 3.3V

[Kishon Vijay Abraham I]

MMC2 interface on AM57xx Beagle-x15, connected to
onboard eMMC, has IO voltage fixed to 3.3V.

Add no-1-8-v device-tree property to mmc2 node
in the board's device-tree file to reflect
this.

Note that the AM57xx SoC itself supports dual-voltage
on MMC2. The limitation above is due to the board.

Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 064755e6fac5..8cef5d1460ec 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -445,6 +445,7 @@
bus-width = <8>;
ti,non-removable;
cap-mmc-dual-data-rate;
+   no-1-8-v;
 };
 
  {
-- 
2.11.0

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

[PATCH 38/41] ARM: OMAP2+: Add pdata-quirks for MMC/SD on DRA74x EVM

[Kishon Vijay Abraham I]

From: Sekhar Nori 

DRA74x EVM Rev H EVM comes with revision 2.0 silicon.
However, earlier versions of EVM can come with either
revision 1.1 or revision 1.0 of silicon.

The device-tree file is written to support rev 2.0 of
silicon. pdata quirks are used to then override the
settings needed for PG 1.1 silicon.

PG 1.1 silicon has limitations w.r.t frequencies at
which MMC1/2/3 can operate as well as different IOdelay
numbers.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 arch/arm/mach-omap2/pdata-quirks.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 9700a8ef0f16..6b433fce65a5 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -434,6 +434,26 @@ static void __init omap5_uevm_legacy_init(void)
 }
 #endif
 
+#ifdef CONFIG_SOC_DRA7XX
+static struct omap_hsmmc_platform_data dra7_hsmmc_data_mmc1;
+static struct omap_hsmmc_platform_data dra7_hsmmc_data_mmc2;
+static struct omap_hsmmc_platform_data dra7_hsmmc_data_mmc3;
+
+static void __init dra7x_evm_mmc_quirk(void)
+{
+   if (omap_rev() == DRA752_REV_ES1_1 || omap_rev() == DRA752_REV_ES1_0) {
+   dra7_hsmmc_data_mmc1.version = "rev11";
+   dra7_hsmmc_data_mmc1.max_freq = 9600;
+
+   dra7_hsmmc_data_mmc2.version = "rev11";
+   dra7_hsmmc_data_mmc2.max_freq = 4800;
+
+   dra7_hsmmc_data_mmc3.version = "rev11";
+   dra7_hsmmc_data_mmc3.max_freq = 4800;
+   }
+}
+#endif
+
 static struct pcs_pdata pcs_pdata;
 
 void omap_pcs_legacy_init(int irq, void (*rearm)(void))
@@ -561,6 +581,14 @@ static struct of_dev_auxdata omap_auxdata_lookup[] 
__initdata = {
OF_DEV_AUXDATA("ti,omap4-iommu", 0x55082000, "55082000.mmu",
   _iommu_pdata),
 #endif
+#ifdef CONFIG_SOC_DRA7XX
+   OF_DEV_AUXDATA("ti,dra7-hsmmc", 0x4809c000, "4809c000.mmc",
+  _hsmmc_data_mmc1),
+   OF_DEV_AUXDATA("ti,dra7-hsmmc", 0x480b4000, "480b4000.mmc",
+  _hsmmc_data_mmc2),
+   OF_DEV_AUXDATA("ti,dra7-hsmmc", 0x480ad000, "480ad000.mmc",
+  _hsmmc_data_mmc3),
+#endif
/* Common auxdata */
OF_DEV_AUXDATA("pinctrl-single", 0, NULL, _pdata),
{ /* sentinel */ },
@@ -590,6 +618,9 @@ static struct pdata_init pdata_quirks[] __initdata = {
 #ifdef CONFIG_SOC_OMAP5
{ "ti,omap5-uevm", omap5_uevm_legacy_init, },
 #endif
+#ifdef CONFIG_SOC_DRA7XX
+   { "ti,dra7-evm", dra7x_evm_mmc_quirk, },
+#endif
{ /* sentinel */ },
 };
 
-- 
2.11.0

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

[PATCH 17/41] ARM: dts: dra72-evm: Add vmmc_aux supply to mmc1

[Kishon Vijay Abraham I]

Add vmmc_aux-supply property to mmc1 dt node and populate
it with ldo1_reg to reflect ldo1_out is connected to mmc1 IO lines.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72-evm.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index cd9c4ff12654..1c570236a1a0 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -43,3 +43,7 @@
phy_id = <_mdio>, <3>;
phy-mode = "rgmii";
 };
+
+ {
+   vmmc_aux-supply = <_reg>;
+};
-- 
2.11.0

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

[PATCH 39/41] ARM: omap2plus_defconfig: Enable PINCTRL_TI_IODELAY

[Kishon Vijay Abraham I]

Enable PINCTRL_TI_IODELAY since it is required for MMC module in
DRA7 family of processors to configure "IODelay" values
depending on the enumerated MMC modes.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/configs/omap2plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index a120ae816260..4d92f308349f 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -246,6 +246,7 @@ CONFIG_HSI=m
 CONFIG_OMAP_SSI=m
 CONFIG_SSI_PROTOCOL=m
 CONFIG_PINCTRL_SINGLE=y
+CONFIG_PINCTRL_TI_IODELAY=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_PCA953X=m
-- 
2.11.0

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

[PATCH 40/41] ARM: multi_v7_defconfig: Enable PINCTRL_TI_IODELAY

[Kishon Vijay Abraham I]

Enable PINCTRL_TI_IODELAY since it is required for MMC module in
DRA7 family of processors to configure "IODelay" values
depending on the enumerated MMC modes.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 2685e03600b1..9fc8cafe88f5 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -412,6 +412,7 @@ CONFIG_PINCTRL_MSM8X74=y
 CONFIG_PINCTRL_MSM8916=y
 CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
+CONFIG_PINCTRL_TI_IODELAY=y
 CONFIG_GPIO_GENERIC_PLATFORM=y
 CONFIG_GPIO_DAVINCI=y
 CONFIG_GPIO_DWAPB=y
-- 
2.11.0

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

[PATCH 33/41] ARM: dts: dra7: Add "max-frequency" property to MMC dt nodes

[Kishon Vijay Abraham I]

Add "max-frequency" property to MMC dt nodes and set the
maximum frequency to 192MHz for MMC1/MMC2, 64MHz for MMC3
and 192MHz for MMC4. pdata quirks must be utilized to
detect presence of rev 1.1/1.0 of silicon and adjust
maximum frequencies as per restrictions documented in i843.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/dra7.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5a262e1a0313..38fb1828e26a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1045,6 +1045,7 @@
dma-names = "tx", "rx";
status = "disabled";
pbias-supply = <_mmc_reg>;
+   max-frequency = <19200>;
};
 
mmc2: mmc@480b4000 {
@@ -1056,6 +1057,7 @@
dmas = <_xbar 47>, <_xbar 48>;
dma-names = "tx", "rx";
status = "disabled";
+   max-frequency = <19200>;
};
 
mmc3: mmc@480ad000 {
@@ -1067,6 +1069,8 @@
dmas = <_xbar 77>, <_xbar 78>;
dma-names = "tx", "rx";
status = "disabled";
+   /* Errata i887 limits max-frequency of MMC3 to 64 MHz */
+   max-frequency = <6400>;
};
 
mmc4: mmc@480d1000 {
@@ -1078,6 +1082,7 @@
dmas = <_xbar 57>, <_xbar 58>;
dma-names = "tx", "rx";
status = "disabled";
+   max-frequency = <19200>;
};
 
mmu0_dsp1: mmu@40d01000 {
-- 
2.11.0

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

[PATCH 23/41] ARM: dts: dra72x: Create a common file with MMC/SD IOdelay data

[Kishon Vijay Abraham I]

From: Sekhar Nori 

Add pinmux configuration for MMC module including IODELAY
values suggested in the data manual for the various supported
modes.

IOdelay data for both silicon revision 1.0 and 2.0 is
added here.

The datamanual revisions used are:
 * AM571x Silicon Revision 2.0: SPRS957D, Revised January 2017
 * AM571x Silicon Revision 1.0: SPRS919M, Revised November 2017
 * DRA71x : SPRS960B, Revised February 2017

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi | 350 ++
 1 file changed, 350 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi

diff --git a/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi 
b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
new file mode 100644
index ..088013c6dc6e
--- /dev/null
+++ b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
@@ -0,0 +1,350 @@
+/*
+ * MMC IOdelay values for TI's DRA72x, DRA71x and AM571x SoCs.
+ *
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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.
+ */
+
+/*
+ * Rules for modifying this file:
+ * a) Update of this file should typically correspond to a datamanual revision.
+ *Datamanual revision that was used should be updated in comment below.
+ *If there is no update to datamanual, do not update the values. If you
+ *need to use values different from that recommended by the datamanual
+ *for your design, then you should consider adding values to the device-
+ *-tree file for your board directly.
+ * b) We keep the mode names as close to the datamanual as possible. So
+ *if the manual calls a mode, DDR50, or DDR or DDR 1.8v or DDR 3.3v,
+ *we follow that in code too.
+ * c) If the values change between multiple revisions of silicon, we add
+ *a revision tag to both the new and old entry. Use 'rev10' for PG 1.0,
+ *'rev20' for PG 2.0 and so on.
+ * d) The node name and node label should be the exact same string. This is
+ *to curb naming creativity and achieve consistency.
+ * e) If in future, DRA71x and DRA72x values differ, then add 'dra71_' and
+ *'dra72_' tag to entries. Both the new and old entries should gain a tag.
+ *
+ * Datamanual Revisions:
+ *
+ * AM571x Silicon Revision 2.0: SPRS957D, Revised January 2017
+ * AM571x Silicon Revision 1.0: SPRS919M, Revised November 2017
+ * DRA71x : SPRS960B, Revised February 2017
+ */
+
+_pmx_core {
+   mmc1_pins_default: mmc1_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   >;
+   };
+
+   mmc1_pins_sdr12: mmc1_pins_sdr12 {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   >;
+   };
+
+   mmc1_pins_hs: mmc1_pins_hs {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* 

[PATCH 20/41] ARM: dts: dra7-evm: Correct the vmmc-supply for mmc2

[Kishon Vijay Abraham I]

From: Ravikumar Kattekola 

On DRA75x EVM, MMC2 vdd/ios are connected to a common supply fixed at 1.8V
not 3.3V

Fixes: 6cf02dbb4b71 ("ARM: dts: dra7-evm: Add mmc2 node for eMMC support")
Signed-off-by: Ravikumar Kattekola 
Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7-evm.dts | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4bc4b575c99b..fbcb3199defd 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -25,6 +25,14 @@
stdout-path = 
};
 
+   evm_1v8_sw: fixedregulator-evm_1v8 {
+   compatible = "regulator-fixed";
+   regulator-name = "evm_1v8";
+   vin-supply = <_reg>;
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
evm_3v3_sd: fixedregulator-sd {
compatible = "regulator-fixed";
regulator-name = "evm_3v3_sd";
@@ -449,7 +457,7 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
-   vmmc-supply = <_3v3_sw>;
+   vmmc-supply = <_1v8_sw>;
bus-width = <8>;
 };
 
-- 
2.11.0

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

[PATCH 30/41] ARM: dts: dra72-evm: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

Include dra72x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for dra72 SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in dra72-evm.dts.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72-evm.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index b25e7c67badf..6a47d2abf1ee 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -6,6 +6,7 @@
  * published by the Free Software Foundation.
  */
 #include "dra72-evm-common.dtsi"
+#include "dra72x-mmc-iodelay.dtsi"
 / {
model = "TI DRA722";
 
@@ -55,9 +56,22 @@
 };
 
  {
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_sdr12>;
+   pinctrl-3 = <_pins_sdr25>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50_rev10>;
+   pinctrl-6 = <_pins_sdr104 _iodelay_sdr104_rev10_conf>;
vmmc_aux-supply = <_reg>;
 };
 
  {
+   pinctrl-names = "default", "hs", "ddr_1_8v", "hs200_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_rev10>;
+   pinctrl-3 = <_pins_hs200 _iodelay_hs200_rev10_conf>;
vmmc-supply = <_1v8_sw>;
 };
-- 
2.11.0

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

[PATCH 36/41] ARM: dts: am57xx-idk: Set MMC2 IO voltage to 3.3V

[Kishon Vijay Abraham I]

From: Sekhar Nori 

MMC2 interface on AM57xx IDK, connected to
onboard eMMC, has IO voltage fixed to 3.3V.

Add no-1-8-v device-tree property to mmc2 node
in the board's device-tree file to reflect
this.

Note that the AM57xx SoC itself supports
dual-voltage on MMC2. The limitation above is
due to the board.

Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am57xx-idk-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi 
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 5d6965ab7339..a8c9e5f714e4 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -413,6 +413,7 @@
bus-width = <8>;
ti,non-removable;
max-frequency = <9600>;
+   no-1-8-v;
/delete-property/ mmc-hs200-1_8v;
 };
 
-- 
2.11.0

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

[PATCH 41/41] Documentation: ARM: Document new dependencies for MMC on DRA7

[Kishon Vijay Abraham I]

MMC on DRA7 SoCs require different IO Delay values to be configured
depending on the MMC mode. In order to confgiure these IO Delay values
CONFIG_PINCTRL_TI_IODELAY must be enabled. Document this dependency
here so that it can be added by anyone using custom .config.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/arm/OMAP/README | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/arm/OMAP/README b/Documentation/arm/OMAP/README
index 75645c45d14a..df018c59e36a 100644
--- a/Documentation/arm/OMAP/README
+++ b/Documentation/arm/OMAP/README
@@ -5,3 +5,7 @@ KERNEL  NEW DEPENDENCIES
 v4.3+  Update is needed for custom .config files to make sure
CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work
properly.
+
+v4.13+ Update is needed for custom .config files to make sure
+   CONFIG_PINCTRL_TI_IODELAY is enabled for all MMC instances
+   to work properly in DRA7 based boards.
-- 
2.11.0

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

[PATCH 34/41] ARM: dts: dra7: Use new dra7-specific compatible string

[Kishon Vijay Abraham I]

Use the new compatible string "ti,dra7-hsmmc" that was specifically
added for dra7 and dra72. This is required since for dra7 and dra72
processors iodelay values has to be set unlike other processors.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/dra7.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 38fb1828e26a..40b9eb96cdeb 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1035,7 +1035,7 @@
};
 
mmc1: mmc@4809c000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x4809c000 0x400>;
interrupts = ;
ti,hwmods = "mmc1";
@@ -1049,7 +1049,7 @@
};
 
mmc2: mmc@480b4000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x480b4000 0x400>;
interrupts = ;
ti,hwmods = "mmc2";
@@ -1061,7 +1061,7 @@
};
 
mmc3: mmc@480ad000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x480ad000 0x400>;
interrupts = ;
ti,hwmods = "mmc3";
@@ -1074,7 +1074,7 @@
};
 
mmc4: mmc@480d1000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-hsmmc", "ti,omap4-hsmmc";
reg = <0x480d1000 0x400>;
interrupts = ;
ti,hwmods = "mmc4";
-- 
2.11.0

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

[PATCH 24/41] ARM: dts: dra74x: Create a common file with MMC/SD IOdelay data

[Kishon Vijay Abraham I]

From: Sekhar Nori 

Add pinmux configuration for MMC module including IODELAY
values suggested in the data manual for the various supported
modes.

IOdelay data for both silicon revision 1.1 and 2.0 is
added here.

The datamanual revisions used are:
* AM572x Silicon Revision 2.0: SPRS953B, Revised November 2016
* AM572x Silicon Revision 1.1: SPRS915R, Revised November 2016

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi | 648 ++
 1 file changed, 648 insertions(+)
 create mode 100644 arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi

diff --git a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi 
b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
new file mode 100644
index ..1b88332248fd
--- /dev/null
+++ b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
@@ -0,0 +1,648 @@
+/*
+ * MMC IOdelay values for TI's DRA74x, DRA75x and AM572x SoCs.
+ *
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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.
+ */
+
+/*
+ * Rules for modifying this file:
+ * a) Update of this file should typically correspond to a datamanual revision.
+ *Datamanual revision that was used should be updated in comment below.
+ *If there is no update to datamanual, do not update the values. If you
+ *need to use values different from that recommended by the datamanual
+ *for your design, then you should consider adding values to the device-
+ *-tree file for your board directly.
+ * b) We keep the mode names as close to the datamanual as possible. So
+ *if the manual calls a mode, DDR50, or DDR or DDR 1.8v or DDR 3.3v,
+ *we follow that in code too.
+ * c) If the values change between multiple revisions of silicon, we add
+ *a revision tag to both the new and old entry. Use 'rev11' for PG 1.1,
+ *'rev20' for PG 2.0 and so on.
+ * d) The node name and node label should be the exact same string. This is
+ *to curb naming creativity and achieve consistency.
+ *
+ * Datamanual Revisions:
+ *
+ * AM572x Silicon Revision 2.0: SPRS953B, Revised November 2016
+ * AM572x Silicon Revision 1.1: SPRS915R, Revised November 2016
+ *
+ */
+
+_pmx_core {
+   mmc1_pins_default: mmc1_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   >;
+   };
+
+   mmc1_pins_sdr12: mmc1_pins_sdr12 {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   >;
+   };
+
+   mmc1_pins_hs: mmc1_pins_hs {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | 
MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | 
MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | 
MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | 
MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | 
MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | 
MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_dat3.dat3 */
+   >;
+   };
+
+   mmc1_pins_sdr25: mmc1_pins_sdr25 {
+   

[PATCH 27/41] ARM: dts: am57xx-idk: Move common MMC/SD properties to common file

[Kishon Vijay Abraham I]

From: Sekhar Nori 

AM572x IDK and AM571x IDK boards have equivalent
design of how SD card and eMMC are connected.

The two EVMs mainly differ in IOdelay configuration
needed (because of difference in SoC used).

Move the common properties to am57xx-idk-common.dtsi
file which is common for both EVMs.

Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am571x-idk.dts | 7 ---
 arch/arm/boot/dts/am572x-idk.dts | 8 
 arch/arm/boot/dts/am57xx-idk-common.dtsi | 8 
 3 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
index ad68d1eb3bc3..e685c8e811b0 100644
--- a/arch/arm/boot/dts/am571x-idk.dts
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -64,13 +64,6 @@
};
 };
 
- {
-   status = "okay";
-   vmmc-supply = <_reg>;
-   bus-width = <4>;
-   cd-gpios = < 27 0>; /* gpio 219 */
-};
-
 _dwc3_2 {
extcon = <_usb2>;
 };
diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index 8350b4b34b08..1c112eb25db4 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -76,14 +76,6 @@
vbus-gpio = < 26 GPIO_ACTIVE_HIGH>;
 };
 
- {
-   status = "okay";
-   vmmc-supply = <_3d>;
-   vmmc_aux-supply = <_reg>;
-   bus-width = <4>;
-   cd-gpios = < 27 0>; /* gpio 219 */
-};
-
  {
load-gpios = < 19 GPIO_ACTIVE_LOW>;
 };
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi 
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index c536b2f5389f..0270b01a8e1d 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -399,6 +399,14 @@
dr_mode = "peripheral";
 };
 
+ {
+   status = "okay";
+   vmmc-supply = <_3d>;
+   vmmc_aux-supply = <_reg>;
+   bus-width = <4>;
+   cd-gpios = < 27 0>; /* gpio 219 */
+};
+
  {
status = "okay";
vmmc-supply = <_3d>;
-- 
2.11.0

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

[PATCH 32/41] ARM: dts: dra71-evm: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

Include dra72x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for dra72 SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in dra71-evm.dts.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra71-evm.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index c7a56b6263a6..c87eab0721b6 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -7,6 +7,7 @@
  */
 
 #include "dra72-evm-common.dtsi"
+#include "dra72x-mmc-iodelay.dtsi"
 #include 
 
 / {
@@ -172,10 +173,23 @@
 };
 
  {
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_sdr12>;
+   pinctrl-3 = <_pins_sdr25>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50_rev20 _iodelay_ddr50_conf>;
+   pinctrl-6 = <_pins_sdr104 _iodelay_sdr104_rev20_conf>;
vmmc_aux-supply = <_sd_1v8_3v3>;
 };
 
  {
+   pinctrl-names = "default", "hs", "ddr_1_8v", "hs200_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_rev20 _iodelay_ddr_conf>;
+   pinctrl-3 = <_pins_hs200 _iodelay_hs200_rev20_conf>;
vmmc-supply = <_1v8_sw>;
 };
 
-- 
2.11.0

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

[PATCH 06/41] mmc: host: omap_hsmmc: Add tuning support

[Kishon Vijay Abraham I]

MMC tuning procedure is required to support SD card
UHS1-SDR104 mode and EMMC HS200 mode.

The tuning function omap_execute_tuning() will only be
called by the MMC/SD core if the corresponding speed modes
are supported by the OMAP silicon which is set in the mmc
host "caps" field.

Add a separate function to set the UHSMS field to one of
SDR104, SDR50, DDR50, SDR25 or SDR12 depending on the
inserted SD card. This is required for tuning to succeed in
the case of SDR104/HS200 or SDR50.

Signed-off-by: Balaji T K 
[r...@ti.com: disable DEB interrupt during tuning]
Signed-off-by: Ravikumar Kattekola 
Signed-off-by: Viswanath Puttagunta 
Signed-off-by: Sourav Poddar 
[kis...@ti.com : cleanup the tuning sequence]
Signed-off-by: Kishon Vijay Abraham I 
[nsek...@ti.com: add comment for tuning timeout]
Signed-off-by: Sekhar Nori 
---
 drivers/mmc/host/omap_hsmmc.c | 200 ++
 1 file changed, 200 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 77be27c8e18c..d8970a7ff4be 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,6 +50,7 @@
 /* OMAP HSMMC Host Controller Registers */
 #define OMAP_HSMMC_SYSSTATUS   0x0014
 #define OMAP_HSMMC_CON 0x002C
+#define OMAP_HSMMC_DLL 0x0034
 #define OMAP_HSMMC_SDMASA  0x0100
 #define OMAP_HSMMC_BLK 0x0104
 #define OMAP_HSMMC_ARG 0x0108
@@ -66,6 +68,7 @@
 #define OMAP_HSMMC_ISE 0x0138
 #define OMAP_HSMMC_AC120x013C
 #define OMAP_HSMMC_CAPA0x0140
+#define OMAP_HSMMC_CAPA2   0x0144
 
 #define VS18   (1 << 26)
 #define VS30   (1 << 25)
@@ -114,6 +117,26 @@
 
 /* AC12 */
 #define AC12_V1V8_SIGEN(1 << 19)
+#define AC12_SCLK_SEL  (1 << 23)
+#define AC12_UHSMC_MASK(7 << 16)
+#define AC12_UHSMC_SDR12   (0 << 16)
+#define AC12_UHSMC_SDR25   (1 << 16)
+#define AC12_UHSMC_SDR50   (2 << 16)
+#define AC12_UHSMC_SDR104  (3 << 16)
+#define AC12_UHSMC_DDR50   (4 << 16)
+#define AC12_UHSMC_RES (0x7 << 16)
+
+/* DLL */
+#define DLL_SWT(1 << 20)
+#define DLL_FORCE_SR_C_SHIFT   13
+#define DLL_FORCE_SR_C_MASK0x7f
+#define DLL_FORCE_VALUE(1 << 12)
+#define DLL_CALIB  (1 << 1)
+
+#define MAX_PHASE_DELAY0x7c
+
+/* CAPA2 */
+#define CAPA2_TSDR50   (1 << 13)
 
 /* Interrupt masks for IE and ISE register */
 #define CC_EN  (1 << 0)
@@ -202,6 +225,7 @@ struct omap_hsmmc_host {
unsigned intdma_sg_idx;
unsigned char   bus_mode;
unsigned char   power_mode;
+   unsigned char   timing;
int suspended;
u32 con;
u32 hctl;
@@ -225,6 +249,8 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next  next_data;
struct  omap_hsmmc_platform_data*pdata;
 
+   boolis_tuning;
+
/* return MMC cover switch state, can be NULL if not supported.
 *
 * possible return values:
@@ -243,6 +269,7 @@ struct omap_mmc_of_data {
 
 static void omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host);
 static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host, int iov);
+static void omap_hsmmc_disable_tuning(struct omap_hsmmc_host *host);
 
 static int omap_hsmmc_card_detect(struct device *dev)
 {
@@ -610,6 +637,15 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host 
*host,
u32 irq_mask = INT_EN_MASK;
unsigned long flags;
 
+   if (host->is_tuning)
+   /*
+* OMAP5/DRA74X/DRA72x Errata i802:
+* DCRC error interrupts (MMCHS_STAT[21] DCRC=0x1) can occur
+* during the tuning procedure. So disable it during the
+* tuning procedure.
+*/
+   irq_mask &= ~(DCRC_EN | DEB_EN);
+
if (host->use_dma)
irq_mask &= ~(BRR_EN | BWR_EN);
 
@@ -959,6 +995,11 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, 
struct mmc_command *cmd,
cmdreg &= ~(DDIR);
}
 
+   /* Tuning command is special. Data Present Select should be set */
+   if ((cmd->opcode == MMC_SEND_TUNING_BLOCK) ||
+   (cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200))
+   cmdreg |= DP_SELECT | DDIR;
+
if (host->use_dma)
cmdreg |= DMAE;
 
@@ -1667,6 +1708,41 @@ static void omap_hsmmc_request(struct mmc_host *mmc, 
struct mmc_request *req)
omap_hsmmc_start_command(host, req->cmd, req->data);
 }
 
+static void omap_hsmmc_set_timing(struct omap_hsmmc_host 

[PATCH 26/41] ARM: dts: am57xx-beagle-x15: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

Include dra74x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for dra74 SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in am57xx-beagle-x15/am57xx-beagle-x15-revb1.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 29 +
 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts   | 15 +
 arch/arm/boot/dts/am57xx-beagle-x15.dts | 11 ++
 3 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 585d792a8fdd..064755e6fac5 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -9,6 +9,7 @@
 
 #include "dra74x.dtsi"
 #include "am57xx-commercial-grade.dtsi"
+#include "dra74x-mmc-iodelay.dtsi"
 #include 
 #include 
 
@@ -166,34 +167,6 @@
};
 };
 
-_pmx_core {
-   mmc1_pins_default: mmc1_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14)   
/* mmc1sdcd.gpio219 */
-   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
-   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
-   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
-   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
-   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
-   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
-   >;
-   };
-
-   mmc2_pins_default: mmc2_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a23.mmc2_clk */
-   DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_cs1.mmc2_cmd */
-   DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a24.mmc2_dat0 */
-   DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a25.mmc2_dat1 */
-   DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a26.mmc2_dat2 */
-   DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a27.mmc2_dat3 */
-   DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a19.mmc2_dat4 */
-   DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a20.mmc2_dat5 */
-   DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a21.mmc2_dat6 */
-   DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a22.mmc2_dat7 */
-   >;
-   };
-};
  {
status = "okay";
clock-frequency = <40>;
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
index 6ae94ab52b7b..d1786a8af7ae 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
@@ -19,10 +19,25 @@
 };
 
  {
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_sdr12>;
+   pinctrl-3 = <_pins_sdr25>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50 _iodelay_ddr_rev11_conf>;
+   pinctrl-6 = <_pins_sdr104 _iodelay_sdr104_rev11_conf>;
vmmc-supply = <_3v3>;
vmmc_aux-supply = <_reg>;
 };
 
+ {
+   pinctrl-names = "default", "hs", "ddr_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_3_3v_rev11 
_iodelay_ddr_3_3v_rev11_conf>;
+};
+
 /* errata i880 "Ethernet RGMII2 Limited to 10/100 Mbps" */
  {
max-speed = <100>;
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 19a60a11c198..d6689106d2a8 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -20,9 +20,20 @@
 };
 
  {
+   pinctrl-names = "default", "hs";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+
vmmc-supply = <_reg>;
 };
 
+ {
+   pinctrl-names = "default", "hs", "ddr_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_ddr_3_3v_rev11 
_iodelay_ddr_3_3v_rev11_conf>;
+};
+
 /* errata i880 "Ethernet RGMII2 Limited to 10/100 Mbps" */
  {
max-speed = <100>;
-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH 19/41] ARM: dts: am57xx-beagle-x15-revb1: Fix supply name used for MMC1 IO lines

[Kishon Vijay Abraham I]

The dt binding documentation of omap-hsmmc recommends using
"vmmc_aux" for IO supply lines. However
commit 0af28cc92690d8c ("ARM: dts: am57xx-beagle-x15: Add support
for rev B1") added it as "vmmc-aux". Fix it here.

Fixes: commit 0af28cc92690d8c ("ARM: dts: am57xx-beagle-x15: Add
support for rev B1")
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
index 39a92aff0a0d..6ae94ab52b7b 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-revb1.dts
@@ -20,7 +20,7 @@
 
  {
vmmc-supply = <_3v3>;
-   vmmc-aux-supply = <_reg>;
+   vmmc_aux-supply = <_reg>;
 };
 
 /* errata i880 "Ethernet RGMII2 Limited to 10/100 Mbps" */
-- 
2.11.0

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

[PATCH 18/41] ARM: dts: dra72-evm-revc: Add vmmc_aux supply to mmc1

[Kishon Vijay Abraham I]

Add vmmc_aux-supply property to mmc1 dt node and populate
it with ldo1_reg to reflect ldo1_out is connected to mmc1 IO lines.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72-evm-revc.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts 
b/arch/arm/boot/dts/dra72-evm-revc.dts
index 3ecac56bf504..58a2e6599ea7 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -82,3 +82,7 @@
interrupts = <16 IRQ_TYPE_EDGE_FALLING>;
};
 };
+
+ {
+   vmmc_aux-supply = <_reg>;
+};
-- 
2.11.0

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

Re: [RFC PATCH] mm, oom: cgroup-aware OOM-killer

[Michal Hocko]

On Thu 18-05-17 14:11:17, Johannes Weiner wrote:
> On Thu, May 18, 2017 at 07:30:04PM +0200, Michal Hocko wrote:
> > On Thu 18-05-17 17:28:04, Roman Gushchin wrote:
> > > Traditionally, the OOM killer is operating on a process level.
> > > Under oom conditions, it finds a process with the highest oom score
> > > and kills it.
> > > 
> > > This behavior doesn't suit well the system with many running
> > > containers. There are two main issues:
> > > 
> > > 1) There is no fairness between containers. A small container with
> > > a few large processes will be chosen over a large one with huge
> > > number of small processes.
> > > 
> > > 2) Containers often do not expect that some random process inside
> > > will be killed. So, in general, a much safer behavior is
> > > to kill the whole cgroup. Traditionally, this was implemented
> > > in userspace, but doing it in the kernel has some advantages,
> > > especially in a case of a system-wide OOM.
> > > 
> > > To address these issues, cgroup-aware OOM killer is introduced.
> > > Under OOM conditions, it looks for a memcg with highest oom score,
> > > and kills all processes inside.
> > > 
> > > Memcg oom score is calculated as a size of active and inactive
> > > anon LRU lists, unevictable LRU list and swap size.
> > > 
> > > For a cgroup-wide OOM, only cgroups belonging to the subtree of
> > > the OOMing cgroup are considered.
> > 
> > While this might make sense for some workloads/setups it is not a
> > generally acceptable policy IMHO. We have discussed that different OOM
> > policies might be interesting few years back at LSFMM but there was no
> > real consensus on how to do that. One possibility was to allow bpf like
> > mechanisms. Could you explore that path?
> 
> OOM policy is an orthogonal discussion, though.
> 
> The OOM killer's job is to pick a memory consumer to kill. Per default
> the unit of the memory consumer is a process, but cgroups allow
> grouping processes into compound consumers. Extending the OOM killer
> to respect the new definition of "consumer" is not a new policy.

I do not want to play word games here but picking a task or more tasks
is a policy from my POV but that is not all that important. My primary
point is that this new "implementation" is most probably not what people
who use memory cgroups outside of containers want. Why? Mostly because
they do not care that only a part of the memcg is still alive pretty
much like the current global OOM behavior when a single task (or its
children) are gone all of the sudden. Why should I kill the whole user
slice just because one of its processes went wild?
 
> I don't think it's reasonable to ask the person who's trying to make
> the OOM killer support group-consumers to design a dynamic OOM policy
> framework instead.
> 
> All we want is the OOM policy, whatever it is, applied to cgroups.

And I am not dismissing this usecase. I believe it is valid but not
universally applicable when memory cgroups are deployed. That is why
I think that we need a way to define those policies in some sane way.
Our current oom policies are basically random -
/proc/sys/vm/oom_kill_allocating_task resp. /proc/sys/vm/panic_on_oom.

I am not really sure we want another hardcoded one e.g.
/proc/sys/vm/oom_kill_container because even that might turn out not the
great fit for different container usecases. Do we want to kill the
largest container or the one with the largest memory hog? Should some
containers have a higher priority over others? I am pretty sure more
criterion would pop up with more usecases.

That's why I think that the current OOM killer implementation should
stay as a last resort and be process oriented and we should think about
a way to override it for particular usecases. The exact mechanism is not
completely clear to me to be honest.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 0/2] dm: boot a mapped device without an initramfs

[Enric Balletbo i Serra]

Dear all,

So here is a new version of the patches to be reviewed, this time as
suggested by Alasdair the patches are reworked to match with the new
dmsetup bootformat feature [1]. These patches are not reviewed yet but
the format was discussed in the IRC and was suggested to send the
kernel patches in parallel.

Changes since v7:
 - Fix build error due commit
e516db4f67 (dm ioctl: add a new DM_DEV_ARM_POLL ioctl)

Changes since v6:
 - Add a new function to issue the equivalent of a DM ioctl programatically.
 - Use the new ioctl interface to create the devices.
 - Use a comma-delimited and semi-colon delimited dmsetup-like commands.

Changes since v5:
 - https://www.redhat.com/archives/dm-devel/2016-February/msg00112.html

[1] https://www.redhat.com/archives/linux-lvm/2017-May/msg00047.html

Wating for your feedback,

Enric Balletbo i Serra (1):
  dm ioctl: add a device mapper ioctl function.

Will Drewry (1):
  init: add support to directly boot to a mapped device

 Documentation/admin-guide/kernel-parameters.rst |   1 +
 Documentation/admin-guide/kernel-parameters.txt |   3 +
 Documentation/device-mapper/dm-boot.txt |  65 
 drivers/md/dm-ioctl.c   |  50 +++
 include/linux/device-mapper.h   |   6 +
 init/Makefile   |   1 +
 init/do_mounts.c|   1 +
 init/do_mounts.h|  10 +
 init/do_mounts_dm.c | 459 
 9 files changed, 596 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-boot.txt
 create mode 100644 init/do_mounts_dm.c

-- 
2.9.3

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

[PATCH v8 2/2] dm ioctl: add a device mapper ioctl function.

[Enric Balletbo i Serra]

Add a dm_ioctl_cmd to issue the equivalent of a DM ioctl call in kernel.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/md/dm-ioctl.c | 50 +++
 include/linux/device-mapper.h |  6 ++
 2 files changed, 56 insertions(+)

diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index d45c681..033e31d 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -2011,3 +2011,53 @@ int dm_copy_name_and_uuid(struct mapped_device *md, char 
*name, char *uuid)
 
return r;
 }
+
+/**
+ * dm_ioctl_cmd - Device mapper ioctl's
+ * @command: ioctl command
+ * @param: Pointer to device mapped ioctl struct
+ */
+int dm_ioctl_cmd(uint command, struct dm_ioctl *param)
+{
+   int r = 0;
+   int ioctl_flags;
+   unsigned int cmd;
+   ioctl_fn fn = NULL;
+   size_t input_param_size;
+   struct file *filp = NULL;
+
+   if (_IOC_TYPE(command) != DM_IOCTL)
+   return -ENOTTY;
+
+   /* DM_DEV_ARM_POLL is not supported */
+   if (command == DM_DEV_ARM_POLL)
+   return -EINVAL;
+
+   cmd = _IOC_NR(command);
+
+   /*
+* Nothing more to do for the version command.
+*/
+   if (cmd == DM_VERSION_CMD)
+   return 0;
+
+   fn = lookup_ioctl(cmd, _flags);
+   if (!fn) {
+   DMWARN("dm_ioctl: unknown command 0x%x", command);
+   return -ENOTTY;
+   }
+
+   input_param_size = param->data_size;
+   r = validate_params(cmd, param);
+   if (r)
+   return r;
+
+   param->data_size = sizeof(*param);
+   r = fn(filp, param, input_param_size);
+
+   if (unlikely(param->flags & DM_BUFFER_FULL_FLAG) &&
+   unlikely(ioctl_flags & IOCTL_FLAGS_NO_PARAMS))
+   DMERR("ioctl %d tried to output some data but has 
IOCTL_FLAGS_NO_PARAMS set", cmd);
+
+   return r;
+}
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index f4c639c..f81ba42 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct dm_dev;
 struct dm_target;
@@ -446,6 +447,11 @@ int dm_noflush_suspending(struct dm_target *ti);
 void dm_accept_partial_bio(struct bio *bio, unsigned n_sectors);
 union map_info *dm_get_rq_mapinfo(struct request *rq);
 
+/*
+ * Device mapper ioctl function.
+ */
+int dm_ioctl_cmd(unsigned int command, struct dm_ioctl *param);
+
 struct queue_limits *dm_get_queue_limits(struct mapped_device *md);
 
 /*
-- 
2.9.3

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

[PATCH v8 1/2] init: add support to directly boot to a mapped device

[Enric Balletbo i Serra]

From: Will Drewry 

Add a dm= kernel parameter modeled after the md= parameter from
do_mounts_md. It allows for device-mapper targets to be configured at
boot time for use early in the boot process (as the root device or
otherwise).

Signed-off-by: Will Drewry 
Signed-off-by: Kees Cook 
[rework to use dm_ioctl calls]
Signed-off-by: Enric Balletbo i Serra 
---
 Documentation/admin-guide/kernel-parameters.rst |   1 +
 Documentation/admin-guide/kernel-parameters.txt |   3 +
 Documentation/device-mapper/dm-boot.txt |  65 
 init/Makefile   |   1 +
 init/do_mounts.c|   1 +
 init/do_mounts.h|  10 +
 init/do_mounts_dm.c | 459 
 7 files changed, 540 insertions(+)
 create mode 100644 Documentation/device-mapper/dm-boot.txt
 create mode 100644 init/do_mounts_dm.c

diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index d76ab39..5301f45 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -92,6 +92,7 @@ parameter is applicable::
BLACKFIN Blackfin architecture is enabled.
CLK Common clock infrastructure is enabled.
CMA Contiguous Memory Area support is enabled.
+   DM  Device mapper support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index f85bfe0..0ea65c2 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -829,6 +829,9 @@
 
dis_ucode_ldr   [X86] Disable the microcode loader.
 
+   dm= [DM] Allows early creation of a device-mapper device.
+   See Documentation/device-mapper/boot.txt.
+
dma_debug=off   If the kernel is compiled with DMA_API_DEBUG support,
this option disables the debugging code at boot.
 
diff --git a/Documentation/device-mapper/dm-boot.txt 
b/Documentation/device-mapper/dm-boot.txt
new file mode 100644
index 000..50f08ec
--- /dev/null
+++ b/Documentation/device-mapper/dm-boot.txt
@@ -0,0 +1,65 @@
+Boot time creation of mapped devices
+
+
+It is possible to configure a device mapper device to act as the root
+device for your system in two ways.
+
+The first is to build an initial ramdisk which boots to a minimal
+userspace which configures the device, then pivot_root(8) in to it.
+
+The second is to possible when the device-mapper and any targets are
+compiled into the kernel (not a module), one or more device-mappers may
+be created and used as the root device at boot time with the parameters
+given with the boot line dm=...
+
+The format is specified as a simple string of data separated by commas and
+optionally semi-colons, where:
+ - a comma is used to separate fields like name, uuid, flags and table 
(specifies
+   one device)
+ - a semi-colon is used to separate devices.
+
+So the format will look like this:
+
+ 
dm=,,,[,+][;,,,[,+]]+
+
+Where,
+ ::= The device name.
+ ::= ---- | ""
+::= "ro" | "rw"
+::=
+ ::= "verity" | "bootcache" | ...
+
+The dm line may be as normal when using the dmsetup tool when using the
+--bootformat argument.
+
+Unless renamed by udev, the device node created will be dm-0 as the
+first minor number for the device-mapper is used during early creation.
+
+Examples
+
+An example of booting to a linear array made up of user-mode linux block
+devices:
+
+  dm="lroot,,rw, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" \
+  root=/dev/dm-0
+
+This will boot to a rw dm-linear target of 8192 sectors split across two
+block devices identified by their major:minor numbers.  After boot, udev
+will rename this target to /dev/mapper/lroot (depending on the rules).
+No uuid was assigned.
+
+An example of multiple device-mappers, with the dm="..." contents shown
+here split on multiple lines for readability:
+
+vboot,,ro,
+  0 1768000 bootcache
+aa55b119-2a47-8c45-946a-5ac57765011f+1
+76e9be054b15884a9fa85973e9cb274c93afadb6
+1768000 10 23 2;
+vroot,,ro,
+  0 1740800 verity 254:0 254:0 1740800 sha1
+76e9be054b15884a9fa85973e9cb274c93afadb6
+5b3549d54d6c7a3837b9b81ed72e49463a64c03680c47835bef94d768e5646fe;
+vram,,rw,
+  0 32768 linear 1:0 0,
+  32768 32768 linear 1:1 0
diff --git a/init/Makefile b/init/Makefile
index 

Re: [dm-devel] [PATCH v7 0/2] dm: boot a mapped device without an initramfs

[Enric Balletbo Serra]

Hi,

2017-05-18 18:29 GMT+02:00 Enric Balletbo i Serra
:
> Dear all,
>
> So here is a new version of the patches to be reviewed, this time as
> suggested by Alasdair the patches are reworked to match with the new
> dmsetup bootformat feature [1]. These patches are not reviewed yet but
> the format was discussed in the IRC and was suggested to send the
> kernel patches in parallel.
>
> Changes since v6:
>  - Add a new function to issue the equivalent of a DM ioctl programatically.
>  - Use the new ioctl interface to create the devices.
>  - Use a comma-delimited and semi-colon delimited dmsetup-like commands.
>
> Changes since v5:
>  - https://www.redhat.com/archives/dm-devel/2016-February/msg00112.html
>
> [1] https://www.redhat.com/archives/linux-lvm/2017-May/msg00047.html
>
> Wating for your feedback,
>
> Enric Balletbo i Serra (1):
>   dm ioctl: add a device mapper ioctl function.
>
> Will Drewry (1):
>   init: add support to directly boot to a mapped device
>
>  Documentation/admin-guide/kernel-parameters.rst |   1 +
>  Documentation/admin-guide/kernel-parameters.txt |   3 +
>  Documentation/device-mapper/dm-boot.txt |  65 
>  drivers/md/dm-ioctl.c   |  45 +++
>  include/linux/device-mapper.h   |   6 +
>  init/Makefile   |   1 +
>  init/do_mounts.c|   1 +
>  init/do_mounts.h|  10 +
>  init/do_mounts_dm.c | 459 
> 
>  9 files changed, 591 insertions(+)
>  create mode 100644 Documentation/device-mapper/dm-boot.txt
>  create mode 100644 init/do_mounts_dm.c
>
> --
> 2.9.3
>
> --
> dm-devel mailing list
> dm-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Rebasing the patches against current linux-next I just noticied that
there is a build error due commit

commit e516db4f676ac88c7c7f698f8047178e8accc3b8
Author: Mikulas Patocka 
Date:   Fri May 5 11:12:52 2017 -0700

dm ioctl: add a new DM_DEV_ARM_POLL ioctl

So I'll send v8 to fix this.

Best regards,
  Enric
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 21/30] men-chameleon-bus.txt: standardize document format

[Johannes Thumshirn]

On 05/19/2017 03:24 AM, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphinx:
>
> - Adjust identations;
> - Remove title numbering;
> - mark literal blocks;
> - comment its TOC.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
Looks good,
Acked-by: Johannes Thumshirn 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html