* [PATCH v3] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Mark Rutland @ 2016-10-09 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-V+OKoeNFqvHvQOOFYi4VLm5mLKrmf9Z5oZY4KQkirsQ@mail.gmail.com>
On Fri, Oct 07, 2016 at 10:31:14AM +0100, Ard Biesheuvel wrote:
> On 12 September 2016 at 17:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Move the statically allocated zero page from the .bss section to right
> > before swapper_pg_dir. This allows us to refer to its physical address
> > by simply reading TTBR1_EL1 (which always points to swapper_pg_dir and
> > always has its ASID field cleared), and subtracting PAGE_SIZE.
> >
> > To protect the zero page from inadvertent modification, carve out a
> > segment that covers it as well as idmap_pg_dir[], and mark it read-only
> > in both the primary and the linear mappings of the kernel.
[...]
> > - map_kernel_segment(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
> > + map_kernel_segment(pgd, _data, __robss_start, PAGE_KERNEL,
> > + &vmlinux_data);
> > + map_kernel_segment(pgd, __robss_start, __robss_end, PAGE_KERNEL_RO,
> > + &vmlinux_robss);
>
> I realised it is actually unnecessary to map the idmap and the zero
> page into the kernel mapping, so we could drop this line.
Given that drivers use the zero page, I wouldn't be entirely surprised to see
phys_to_virt(virt_to_phys(zero_page)) happen indirectly, and the end result
read. Are we sure that doesn't happen anywhere?
For the idmap, I think we might walk that were we to take a fault (though
perhaps we don't). Otherwise, unless we add a sysfs walker for it I guess we
don't strictly need it in the linear map.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Alan Stern @ 2016-10-09 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009163446.GA9672@kozik-lap>
On Sun, 9 Oct 2016, Krzysztof Kozlowski wrote:
> On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> > Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> > as to avoid them being build when not used. This also allows us to use the
> > SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
> >
> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > ---
> > drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> > 1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> > index 42e5b66..1899900 100644
> > --- a/drivers/usb/host/ehci-exynos.c
> > +++ b/drivers/usb/host/ehci-exynos.c
> > @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> > return 0;
> > }
> >
> > -#ifdef CONFIG_PM
> > +#ifdef CONFIG_PM_SLEEP
>
> Does not look like an equivalent change. How will it behave in a config
> with !SUSPEND && !HIBERNATE && PM?
It's hard to say what Anand originally had in mind. To me, it looks
like it will behave exactly the same as before, the only difference
being that the object image will not contain unused exynos_ehci_suspend
and exynos_ehci_resume routines. And the compiler won't issue a
warning at build time that the routines are unused.
Alan Stern
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Chris Wilson @ 2016-10-09 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEi0qNnozbib-92NwWpUV=_YiiUHYGzzBuuY8kDZY9gaZm-W7Q@mail.gmail.com>
On Sun, Oct 09, 2016 at 12:00:31PM -0700, Joel Fernandes wrote:
> Ok. So I'll submit a patch with mutex for purge_lock and use
> cond_resched_lock for the vmap_area_lock as you suggested. I'll also
> drop the lazy_max_pages to 8MB as Andi suggested to reduce the lock
> hold time. Let me know if you have any objections.
The downside of using a mutex here though, is that we may be called
from contexts that cannot sleep (alloc_vmap_area), or reschedule for
that matter! If we change the notion of purged, we can forgo the mutex
in favour of spinning on the direct reclaim path. That just leaves the
complication of whether to use cond_resched_lock() or a lock around
the individual __free_vmap_area().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009183933.GA15270@kozik-lap>
hi Krzysztof,
On 10 October 2016 at 00:09, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, Oct 09, 2016 at 11:57:59PM +0530, Anand Moon wrote:
>> hi Krzysztof,
>>
>> On 9 October 2016 at 22:57, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
>> >> Hi Krzysztof,
>> >>
>> >> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> >> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> >> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> >> >> as to avoid them being build when not used. This also allows us to use the
>> >> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>> >> >>
>> >> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> >> ---
>> >> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> >> >> 1 file changed, 6 insertions(+), 8 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> >> >> index 42e5b66..1899900 100644
>> >> >> --- a/drivers/usb/host/ehci-exynos.c
>> >> >> +++ b/drivers/usb/host/ehci-exynos.c
>> >> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> >> >> return 0;
>> >> >> }
>> >> >>
>> >> >> -#ifdef CONFIG_PM
>> >> >> +#ifdef CONFIG_PM_SLEEP
>> >> >
>> >> > Does not look like an equivalent change. How will it behave in a config
>> >> > with !SUSPEND && !HIBERNATE && PM?
>> >> >
>> >>
>> >> [snip]
>> >>
>> >> I just wanted to update suspend and resume callback to use
>> >> SET_SYSTEM_SLEEP_PM_OPS
>> >> as they are define under CONFIG_PM_SLEEP so I update above to avoid
>> >> compilation warning/error.
>> >
>> Apologize: for not understanding your question.
>>
>> > First of all you did not answer to my question, so let me rephrase into
>> > two:
>> > 1. Is the code equivalent?
>>
>> No CONFIG_PM and CONFIG_PM_SLEEP are different options.
>> But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig
>
> So the code is not equivalent...
>
>>
>> CONFIG_PM_SLEEP=n or
>> # CONFIG_PM_SLEEP is not set
>>
>> > 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
>>
>> #
>> # Power management options
>> #
>> # CONFIG_SUSPEND is not set
>> # CONFIG_HIBERNATION is not set
>> # CONFIG_PM is not set
>>
>> When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
>> CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
>
> In my config, the CONFIG_PM was enabled thus the code changes the
> functionality... Maybe this was intented but I really don't get it from
> the commit message or from your explanations here.
>
> Krzysztof
Ok I will keep the changes to use CONFIG_PM,
but use the SET_SYSTEM_SLEEP_PM_OPS option in V2 patch.
Is that ok.
-Best Regards
-Anand Moon
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Joel Fernandes @ 2016-10-09 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009124242.GA2718@nuc-i3427.alporthouse.com>
On Sun, Oct 9, 2016 at 5:42 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
[..]
>> > My understanding is that
>> >
>> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> > index 91f44e78c516..3f7c6d6969ac 100644
>> > --- a/mm/vmalloc.c
>> > +++ b/mm/vmalloc.c
>> > @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
>> > static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> > int sync, int force_flush)
>> > {
>> > - static DEFINE_SPINLOCK(purge_lock);
>> > struct llist_node *valist;
>> > struct vmap_area *va;
>> > struct vmap_area *n_va;
>> > @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> > * should not expect such behaviour. This just simplifies locking for
>> > * the case that isn't actually used at the moment anyway.
>> > */
>> > - if (!sync && !force_flush) {
>> > - if (!spin_trylock(&purge_lock))
>> > - return;
>> > - } else
>> > - spin_lock(&purge_lock);
>> > -
>> > if (sync)
>> > purge_fragmented_blocks_allcpus();
>> >
>> > @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> > __free_vmap_area(va);
>> > spin_unlock(&vmap_area_lock);
>> > }
>> > - spin_unlock(&purge_lock);
>> > }
>> >
>> [..]
>> > should now be safe. That should significantly reduce the preempt-disabled
>> > section, I think.
>>
>> I believe that the purge_lock is supposed to prevent concurrent purges
>> from happening.
>>
>> For the case where if you have another concurrent overflow happen in
>> alloc_vmap_area() between the spin_unlock and purge :
>>
>> spin_unlock(&vmap_area_lock);
>> if (!purged)
>> purge_vmap_area_lazy();
>>
>> Then the 2 purges would happen at the same time and could subtract
>> vmap_lazy_nr twice.
>
> That itself is not the problem, as each instance of
> __purge_vmap_area_lazy() operates on its own freelist, and so there will
> be no double accounting.
>
> However, removing the lock removes the serialisation which does mean
> that alloc_vmap_area() will not block on another thread conducting the
> purge, and so it will try to reallocate before that is complete and the
> free area made available. It also means that we are doing the
> atomic_sub(vmap_lazy_nr) too early.
>
> That supports making the outer lock a mutex as you suggested. But I think
> cond_resched_lock() is better for the vmap_area_lock (just because it
> turns out to be an expensive loop and we may want the reschedule).
> -Chris
Ok. So I'll submit a patch with mutex for purge_lock and use
cond_resched_lock for the vmap_area_lock as you suggested. I'll also
drop the lazy_max_pages to 8MB as Andi suggested to reduce the lock
hold time. Let me know if you have any objections.
Thanks,
Joel
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Krzysztof Kozlowski @ 2016-10-09 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgS9tbhPK4jwoqR6G1=iKAo15H3Dizu3Lp03KMGbQ4aj9A@mail.gmail.com>
On Sun, Oct 09, 2016 at 11:57:59PM +0530, Anand Moon wrote:
> hi Krzysztof,
>
> On 9 October 2016 at 22:57, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
> >> Hi Krzysztof,
> >>
> >> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> >> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> >> >> as to avoid them being build when not used. This also allows us to use the
> >> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
> >> >>
> >> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >> >> ---
> >> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> >> >> 1 file changed, 6 insertions(+), 8 deletions(-)
> >> >>
> >> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> >> >> index 42e5b66..1899900 100644
> >> >> --- a/drivers/usb/host/ehci-exynos.c
> >> >> +++ b/drivers/usb/host/ehci-exynos.c
> >> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> >> >> return 0;
> >> >> }
> >> >>
> >> >> -#ifdef CONFIG_PM
> >> >> +#ifdef CONFIG_PM_SLEEP
> >> >
> >> > Does not look like an equivalent change. How will it behave in a config
> >> > with !SUSPEND && !HIBERNATE && PM?
> >> >
> >>
> >> [snip]
> >>
> >> I just wanted to update suspend and resume callback to use
> >> SET_SYSTEM_SLEEP_PM_OPS
> >> as they are define under CONFIG_PM_SLEEP so I update above to avoid
> >> compilation warning/error.
> >
> Apologize: for not understanding your question.
>
> > First of all you did not answer to my question, so let me rephrase into
> > two:
> > 1. Is the code equivalent?
>
> No CONFIG_PM and CONFIG_PM_SLEEP are different options.
> But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig
So the code is not equivalent...
>
> CONFIG_PM_SLEEP=n or
> # CONFIG_PM_SLEEP is not set
>
> > 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
>
> #
> # Power management options
> #
> # CONFIG_SUSPEND is not set
> # CONFIG_HIBERNATION is not set
> # CONFIG_PM is not set
>
> When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
> CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
In my config, the CONFIG_PM was enabled thus the code changes the
functionality... Maybe this was intented but I really don't get it from
the commit message or from your explanations here.
Krzysztof
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009172757.GA11916@kozik-lap>
hi Krzysztof,
On 9 October 2016 at 22:57, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> >> as to avoid them being build when not used. This also allows us to use the
>> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>> >>
>> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> ---
>> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> >> 1 file changed, 6 insertions(+), 8 deletions(-)
>> >>
>> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> >> index 42e5b66..1899900 100644
>> >> --- a/drivers/usb/host/ehci-exynos.c
>> >> +++ b/drivers/usb/host/ehci-exynos.c
>> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> >> return 0;
>> >> }
>> >>
>> >> -#ifdef CONFIG_PM
>> >> +#ifdef CONFIG_PM_SLEEP
>> >
>> > Does not look like an equivalent change. How will it behave in a config
>> > with !SUSPEND && !HIBERNATE && PM?
>> >
>>
>> [snip]
>>
>> I just wanted to update suspend and resume callback to use
>> SET_SYSTEM_SLEEP_PM_OPS
>> as they are define under CONFIG_PM_SLEEP so I update above to avoid
>> compilation warning/error.
>
Apologize: for not understanding your question.
> First of all you did not answer to my question, so let me rephrase into
> two:
> 1. Is the code equivalent?
No CONFIG_PM and CONFIG_PM_SLEEP are different options.
But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig
CONFIG_PM_SLEEP=n or
# CONFIG_PM_SLEEP is not set
> 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
#
# Power management options
#
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM is not set
When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
Best Regards
-Anand Moon
>
> You didn't mention compilation warning/error in message commit so I do
> not know what you are thinking about...
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v3 00/17] pinctrl: exynos/samsung: Add header with values used for configuration
From: Krzysztof Kozlowski @ 2016-10-09 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22GgjF=wVzL3fF7xzvOZtJpiZjVcFTrvDQAu6T2RCfY89g@mail.gmail.com>
On Mon, Oct 10, 2016 at 02:49:01AM +0900, Tomasz Figa wrote:
> 2016-10-10 1:39 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> > On Sun, Oct 09, 2016 at 04:04:11PM +0900, Tomasz Figa wrote:
> >> Hi Krzysztof,
> >>
> >> 2016-09-04 20:04 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> >> >
> >> > Hi,
> >> >
> >> > Changes since v2
> >> > ================
> >> > 1. Combine separate patchsets into one. Previously I sent separately the fixes
> >> > and changes for S3C platforms.
> >> > 2. Fix issues pointed during review.
> >> > 3. Add review tags.
> >> >
> >> > Changes since v1
> >> > ================
> >> > 1. Follow Arnd's suggestion about moving the macros to common place.
> >> > 2. Subjects: replace "GPIO" with "pinctrl".
> >> > 3. There were some major changes here so I did not add Javier's
> >> > reviewed-by and tested-by tags.
> >> >
> >> > Merging
> >> > =======
> >> > Patches #1 and #2 should probably go through pinctrl tree. In that case I would
> >> > appreciate a stable branch/tag so DTS could base on top of it.
> >> >
> >> > Goal
> >> > ====
> >> > Increase readability:
> >> > uart0_data: uart0-data {
> >> > samsung,pins = "gpa0-0", "gpa0-1";
> >> > - samsung,pin-function = <2>;
> >> > - samsung,pin-pud = <0>;
> >> > - samsung,pin-drv = <0>;
> >> > + samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
> >> > + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> >> > + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
> >>
> >> I like the idea, thanks for cleaning this up. However I'd like to
> >> bikeshed the prefix a bit. Since the properties are already prefixed
> >> by "samsung,", I think it would make much more sense to also prefix
> >> the generic values with "SAMSUNG_". Of course for soc/family-specific
> >> values, the soc/family name prefix sounds right.
> >
> > I am lost. Sorry, I don't get what kind of final prefixes you would like
> > to have.
> >
> > SAMSUNG_EXYNOS4_PIN_DRV_LV1
> > SAMSUNG_EXYNOS5260_PIN_DRV_LV1
> > ?
>
> For SoC-specific definitions:
>
> EXYNOS4_PIN_DRV_LV1
> EXYNOS5260_PIN_DRV_LV1
ok... so no change needed in my patch.
>
> >
> >> Similarly for rest of the value names, such as SAMSUNG_PIN_PUD instead
> >> of SAMSUNG_PIN_PULL, which obviously sounds more like correct English,
> >> however hurts the consistency and could confuse the people writing new
> >> dts files.
> >
> > SAMSUNG_S3C64XX_PIN_PUD_NONE
> > SAMSUNG_EXYNOS_PIN_PUD_NONE
>
> For definitions common for the whole Samsung pinctrl driver:
>
> SAMSUNG_PIN_PUD_NONE
These are not the same. The "none" is the same but rest is not.
> But actually I think I missed the fact that there is almost no common
> definitions. Is that correct? Was that the missing part of my
> understanding?
Yes. The only common definition for all Samsung SoCs would be the
function of a pin. On the other hand this will bring inconsistency:
everything prefixed with SoC except the function.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 00/17] pinctrl: exynos/samsung: Add header with values used for configuration
From: Tomasz Figa @ 2016-10-09 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009163910.GB9672@kozik-lap>
2016-10-10 1:39 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Sun, Oct 09, 2016 at 04:04:11PM +0900, Tomasz Figa wrote:
>> Hi Krzysztof,
>>
>> 2016-09-04 20:04 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>> >
>> > Hi,
>> >
>> > Changes since v2
>> > ================
>> > 1. Combine separate patchsets into one. Previously I sent separately the fixes
>> > and changes for S3C platforms.
>> > 2. Fix issues pointed during review.
>> > 3. Add review tags.
>> >
>> > Changes since v1
>> > ================
>> > 1. Follow Arnd's suggestion about moving the macros to common place.
>> > 2. Subjects: replace "GPIO" with "pinctrl".
>> > 3. There were some major changes here so I did not add Javier's
>> > reviewed-by and tested-by tags.
>> >
>> > Merging
>> > =======
>> > Patches #1 and #2 should probably go through pinctrl tree. In that case I would
>> > appreciate a stable branch/tag so DTS could base on top of it.
>> >
>> > Goal
>> > ====
>> > Increase readability:
>> > uart0_data: uart0-data {
>> > samsung,pins = "gpa0-0", "gpa0-1";
>> > - samsung,pin-function = <2>;
>> > - samsung,pin-pud = <0>;
>> > - samsung,pin-drv = <0>;
>> > + samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
>> > + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>> > + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
>>
>> I like the idea, thanks for cleaning this up. However I'd like to
>> bikeshed the prefix a bit. Since the properties are already prefixed
>> by "samsung,", I think it would make much more sense to also prefix
>> the generic values with "SAMSUNG_". Of course for soc/family-specific
>> values, the soc/family name prefix sounds right.
>
> I am lost. Sorry, I don't get what kind of final prefixes you would like
> to have.
>
> SAMSUNG_EXYNOS4_PIN_DRV_LV1
> SAMSUNG_EXYNOS5260_PIN_DRV_LV1
> ?
For SoC-specific definitions:
EXYNOS4_PIN_DRV_LV1
EXYNOS5260_PIN_DRV_LV1
>
>> Similarly for rest of the value names, such as SAMSUNG_PIN_PUD instead
>> of SAMSUNG_PIN_PULL, which obviously sounds more like correct English,
>> however hurts the consistency and could confuse the people writing new
>> dts files.
>
> SAMSUNG_S3C64XX_PIN_PUD_NONE
> SAMSUNG_EXYNOS_PIN_PUD_NONE
For definitions common for the whole Samsung pinctrl driver:
SAMSUNG_PIN_PUD_NONE
...
But actually I think I missed the fact that there is almost no common
definitions. Is that correct? Was that the missing part of my
understanding?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 6/6] crypto: arm64/aes-neon - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The AES implementation using pure NEON instructions relies on the generic
AES key schedule generation routines, which store the round keys as arrays
of 32-bit quantities stored in memory using native endianness. This means
we should refer to these round keys using 4x4 loads rather than 16x1 loads.
In addition, the ShiftRows tables are loading using a single scalar load,
which is also affected by endianness, so emit these tables in the correct
order depending on whether we are building for big endian or not.
Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-neon.S | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-neon.S b/arch/arm64/crypto/aes-neon.S
index b93170e1cc93..85f07ead7c5c 100644
--- a/arch/arm64/crypto/aes-neon.S
+++ b/arch/arm64/crypto/aes-neon.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#define AES_ENTRY(func) ENTRY(neon_ ## func)
#define AES_ENDPROC(func) ENDPROC(neon_ ## func)
@@ -83,13 +84,13 @@
.endm
.macro do_block, enc, in, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in\().16b, \in\().16b, v15.16b /* ^round key */
tbl \in\().16b, {\in\().16b}, v13.16b /* ShiftRows */
sub_bytes \in
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -229,7 +230,7 @@
.endm
.macro do_block_2x, enc, in0, in1 rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -237,7 +238,7 @@
sub_bytes_2x \in0, \in1
tbl \in0\().16b, {\in0\().16b}, v13.16b /* ShiftRows */
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -254,7 +255,7 @@
.endm
.macro do_block_4x, enc, in0, in1, in2, in3, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -266,7 +267,7 @@
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
tbl \in2\().16b, {\in2\().16b}, v13.16b /* ShiftRows */
tbl \in3\().16b, {\in3\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -306,12 +307,16 @@
.text
.align 4
.LForward_ShiftRows:
- .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3
- .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb
+CPU_LE( .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3 )
+CPU_LE( .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb )
+CPU_BE( .byte 0xb, 0x6, 0x1, 0xc, 0x7, 0x2, 0xd, 0x8 )
+CPU_BE( .byte 0x3, 0xe, 0x9, 0x4, 0xf, 0xa, 0x5, 0x0 )
.LReverse_ShiftRows:
- .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb
- .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3
+CPU_LE( .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb )
+CPU_LE( .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3 )
+CPU_BE( .byte 0x3, 0x6, 0x9, 0xc, 0xf, 0x2, 0x5, 0x8 )
+CPU_BE( .byte 0xb, 0xe, 0x1, 0x4, 0x7, 0xa, 0xd, 0x0 )
.LForward_Sbox:
.byte 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] crypto: arm64/aes-ccm-ce: fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
refers to the AES round keys as pairs of 64-bit quantities, which causes
failures when building the code for big endian. In addition, it byte swaps
the input counter unconditionally, while this is only required for little
endian builds. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
index a2a7fbcacc14..3363560c79b7 100644
--- a/arch/arm64/crypto/aes-ce-ccm-core.S
+++ b/arch/arm64/crypto/aes-ce-ccm-core.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
.text
.arch armv8-a+crypto
@@ -19,7 +20,7 @@
*/
ENTRY(ce_aes_ccm_auth_data)
ldr w8, [x3] /* leftover from prev round? */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v0.16b}, [x0] /* load mac */
cbz w8, 1f
sub w8, w8, #16
eor v1.16b, v1.16b, v1.16b
@@ -31,7 +32,7 @@ ENTRY(ce_aes_ccm_auth_data)
beq 8f /* out of input? */
cbnz w8, 0b
eor v0.16b, v0.16b, v1.16b
-1: ld1 {v3.2d}, [x4] /* load first round key */
+1: ld1 {v3.16b}, [x4] /* load first round key */
prfm pldl1strm, [x1]
cmp w5, #12 /* which key size? */
add x6, x4, #16
@@ -41,17 +42,17 @@ ENTRY(ce_aes_ccm_auth_data)
mov v5.16b, v3.16b
b 4f
2: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x6], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x6], #16 /* load 2nd round key */
3: aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
-4: ld1 {v3.2d}, [x6], #16 /* load next round key */
+4: ld1 {v3.16b}, [x6], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
-5: ld1 {v4.2d}, [x6], #16 /* load next round key */
+5: ld1 {v4.16b}, [x6], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
- ld1 {v5.2d}, [x6], #16 /* load next round key */
+ ld1 {v5.16b}, [x6], #16 /* load next round key */
bpl 3b
aese v0.16b, v4.16b
subs w2, w2, #16 /* last data? */
@@ -60,7 +61,7 @@ ENTRY(ce_aes_ccm_auth_data)
ld1 {v1.16b}, [x1], #16 /* load next input block */
eor v0.16b, v0.16b, v1.16b /* xor with mac */
bne 1b
-6: st1 {v0.2d}, [x0] /* store mac */
+6: st1 {v0.16b}, [x0] /* store mac */
beq 10f
adds w2, w2, #16
beq 10f
@@ -79,7 +80,7 @@ ENTRY(ce_aes_ccm_auth_data)
adds w7, w7, #1
bne 9b
eor v0.16b, v0.16b, v1.16b
- st1 {v0.2d}, [x0]
+ st1 {v0.16b}, [x0]
10: str w8, [x3]
ret
ENDPROC(ce_aes_ccm_auth_data)
@@ -89,27 +90,27 @@ ENDPROC(ce_aes_ccm_auth_data)
* u32 rounds);
*/
ENTRY(ce_aes_ccm_final)
- ld1 {v3.2d}, [x2], #16 /* load first round key */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v3.16b}, [x2], #16 /* load first round key */
+ ld1 {v0.16b}, [x0] /* load mac */
cmp w3, #12 /* which key size? */
sub w3, w3, #2 /* modified # of rounds */
- ld1 {v1.2d}, [x1] /* load 1st ctriv */
+ ld1 {v1.16b}, [x1] /* load 1st ctriv */
bmi 0f
bne 3f
mov v5.16b, v3.16b
b 2f
0: mov v4.16b, v3.16b
-1: ld1 {v5.2d}, [x2], #16 /* load next round key */
+1: ld1 {v5.16b}, [x2], #16 /* load next round key */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-2: ld1 {v3.2d}, [x2], #16 /* load next round key */
+2: ld1 {v3.16b}, [x2], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-3: ld1 {v4.2d}, [x2], #16 /* load next round key */
+3: ld1 {v4.16b}, [x2], #16 /* load next round key */
subs w3, w3, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
@@ -120,47 +121,47 @@ ENTRY(ce_aes_ccm_final)
aese v1.16b, v4.16b
/* final round key cancels out */
eor v0.16b, v0.16b, v1.16b /* en-/decrypt the mac */
- st1 {v0.2d}, [x0] /* store result */
+ st1 {v0.16b}, [x0] /* store result */
ret
ENDPROC(ce_aes_ccm_final)
.macro aes_ccm_do_crypt,enc
ldr x8, [x6, #8] /* load lower ctr */
- ld1 {v0.2d}, [x5] /* load mac */
- rev x8, x8 /* keep swabbed ctr in reg */
+ ld1 {v0.16b}, [x5] /* load mac */
+CPU_LE( rev x8, x8 ) /* keep swabbed ctr in reg */
0: /* outer loop */
- ld1 {v1.1d}, [x6] /* load upper ctr */
+ ld1 {v1.8b}, [x6] /* load upper ctr */
prfm pldl1strm, [x1]
add x8, x8, #1
rev x9, x8
cmp w4, #12 /* which key size? */
sub w7, w4, #2 /* get modified # of rounds */
ins v1.d[1], x9 /* no carry in lower ctr */
- ld1 {v3.2d}, [x3] /* load first round key */
+ ld1 {v3.16b}, [x3] /* load first round key */
add x10, x3, #16
bmi 1f
bne 4f
mov v5.16b, v3.16b
b 3f
1: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x10], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x10], #16 /* load 2nd round key */
2: /* inner loop: 3 rounds, 2x interleaved */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-3: ld1 {v3.2d}, [x10], #16 /* load next round key */
+3: ld1 {v3.16b}, [x10], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-4: ld1 {v4.2d}, [x10], #16 /* load next round key */
+4: ld1 {v4.16b}, [x10], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
aese v1.16b, v3.16b
aesmc v1.16b, v1.16b
- ld1 {v5.2d}, [x10], #16 /* load next round key */
+ ld1 {v5.16b}, [x10], #16 /* load next round key */
bpl 2b
aese v0.16b, v4.16b
aese v1.16b, v4.16b
@@ -177,14 +178,14 @@ ENDPROC(ce_aes_ccm_final)
eor v0.16b, v0.16b, v2.16b /* xor mac with pt ^ rk[last] */
st1 {v1.16b}, [x0], #16 /* write output block */
bne 0b
- rev x8, x8
- st1 {v0.2d}, [x5] /* store mac */
+CPU_LE( rev x8, x8 )
+ st1 {v0.16b}, [x5] /* store mac */
str x8, [x6, #8] /* store lsb end of ctr (BE) */
5: ret
6: eor v0.16b, v0.16b, v5.16b /* final round mac */
eor v1.16b, v1.16b, v5.16b /* final round enc */
- st1 {v0.2d}, [x5] /* store mac */
+ st1 {v0.16b}, [x5] /* store mac */
add w2, w2, #16 /* process partial tail block */
7: ldrb w9, [x1], #1 /* get 1 byte of input */
umov w6, v1.b[0] /* get top crypted ctr byte */
--
2.7.4
^ permalink raw reply related
* [PATCH 4/6] crypto: arm64/sha2-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA256 digest is an array of 8 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x32 vector
ones where appropriate.
Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha2-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index 5df9d9d470ad..01cfee066837 100644
--- a/arch/arm64/crypto/sha2-ce-core.S
+++ b/arch/arm64/crypto/sha2-ce-core.S
@@ -85,7 +85,7 @@ ENTRY(sha2_ce_transform)
ld1 {v12.4s-v15.4s}, [x8]
/* load state */
- ldp dga, dgb, [x0]
+ ld1 {dgav.4s, dgbv.4s}, [x0]
/* load sha256_ce_state::finalize */
ldr w4, [x0, #:lo12:sha256_ce_offsetof_finalize]
@@ -148,6 +148,6 @@ CPU_LE( rev32 v19.16b, v19.16b )
b 1b
/* store new state */
-3: stp dga, dgb, [x0]
+3: st1 {dgav.4s, dgbv.4s}, [x0]
ret
ENDPROC(sha2_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH 3/6] crypto: arm64/sha1-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA1 digest is an array of 5 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x4 vector
ones where appropriate.
Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha1-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
index 033aae6d732a..c98e7e849f06 100644
--- a/arch/arm64/crypto/sha1-ce-core.S
+++ b/arch/arm64/crypto/sha1-ce-core.S
@@ -78,7 +78,7 @@ ENTRY(sha1_ce_transform)
ld1r {k3.4s}, [x6]
/* load state */
- ldr dga, [x0]
+ ld1 {dgav.4s}, [x0]
ldr dgb, [x0, #16]
/* load sha1_ce_state::finalize */
@@ -144,7 +144,7 @@ CPU_LE( rev32 v11.16b, v11.16b )
b 1b
/* store new state */
-3: str dga, [x0]
+3: st1 {dgav.4s}, [x0]
str dgb, [x0, #16]
ret
ENDPROC(sha1_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH 2/6] crypto: arm64/ghash-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The GHASH key and digest are both pairs of 64-bit quantities, but the
GHASH code does not always refer to them as such, causing failures when
built for big endian. So replace the 16x1 loads and stores with 2x8 ones.
Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/ghash-ce-core.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index dc457015884e..f0bb9f0b524f 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -29,8 +29,8 @@
* struct ghash_key const *k, const char *head)
*/
ENTRY(pmull_ghash_update)
- ld1 {SHASH.16b}, [x3]
- ld1 {XL.16b}, [x1]
+ ld1 {SHASH.2d}, [x3]
+ ld1 {XL.2d}, [x1]
movi MASK.16b, #0xe1
ext SHASH2.16b, SHASH.16b, SHASH.16b, #8
shl MASK.2d, MASK.2d, #57
@@ -74,6 +74,6 @@ CPU_LE( rev64 T1.16b, T1.16b )
cbnz w0, 0b
- st1 {XL.16b}, [x1]
+ st1 {XL.2d}, [x1]
ret
ENDPROC(pmull_ghash_update)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/6] crypto: arm64/aes-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The core AES cipher implementation that uses ARMv8 Crypto Extensions
instructions erroneously loads the round keys as 64-bit quantities,
which causes the algorithm to fail when built for big endian. In
addition, the key schedule generation routine fails to take endianness
into account as well, when loading the combining the input key with
the round constants. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-cipher.c | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-cipher.c b/arch/arm64/crypto/aes-ce-cipher.c
index f7bd9bf0bbb3..50d9fe11d0c8 100644
--- a/arch/arm64/crypto/aes-ce-cipher.c
+++ b/arch/arm64/crypto/aes-ce-cipher.c
@@ -47,24 +47,24 @@ static void aes_cipher_encrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aese v0.16b, v2.16b ;"
" aesmc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aese v0.16b, v3.16b ;"
" aesmc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aese v0.16b, v1.16b ;"
" aesmc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aese v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -92,24 +92,24 @@ static void aes_cipher_decrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aesd v0.16b, v2.16b ;"
" aesimc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aesd v0.16b, v3.16b ;"
" aesimc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aesd v0.16b, v1.16b ;"
" aesimc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aesd v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -173,7 +173,12 @@ int ce_aes_expandkey(struct crypto_aes_ctx *ctx, const u8 *in_key,
u32 *rki = ctx->key_enc + (i * kwords);
u32 *rko = rki + kwords;
+#ifndef CONFIG_CPU_BIG_ENDIAN
rko[0] = ror32(aes_sub(rki[kwords - 1]), 8) ^ rcon[i] ^ rki[0];
+#else
+ rko[0] = rol32(aes_sub(rki[kwords - 1]), 8) ^ (rcon[i] << 24) ^
+ rki[0];
+#endif
rko[1] = rko[0] ^ rki[1];
rko[2] = rko[1] ^ rki[2];
rko[3] = rko[2] ^ rki[3];
--
2.7.4
^ permalink raw reply related
* [PATCH 0/6] crypto: arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
currently work, or have ever worked correctly when built for big endian. So this
series fixes all of them.
Each of these patches carries a fixes tag, and could be backported to stable.
However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
fix is compatible with, not the patch that introduced the algorithm. This is due
to the fact that the key schedules are incompatible between generic AES and the
arm64 Crypto Extensions implementation (but only when building for big endian)
This is not a problem in practice, but it does mean that the AES-CCM and AES in
EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
one that is compatible with the generic AES key schedule generation code (which
it currently no longer uses)
In any case, please apply with cc to stable.
Ard Biesheuvel (6):
crypto: arm64/aes-ce - fix for big endian
crypto: arm64/ghash-ce - fix for big endian
crypto: arm64/sha1-ce - fix for big endian
crypto: arm64/sha2-ce - fix for big endian
crypto: arm64/aes-ccm-ce: fix for big endian
crypto: arm64/aes-neon - fix for big endian
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
arch/arm64/crypto/aes-neon.S | 25 +++++----
arch/arm64/crypto/ghash-ce-core.S | 6 +--
arch/arm64/crypto/sha1-ce-core.S | 4 +-
arch/arm64/crypto/sha2-ce-core.S | 4 +-
6 files changed, 64 insertions(+), 53 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Krzysztof Kozlowski @ 2016-10-09 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgSr6-0x47=0P_NCiGCv=FSZR9dNT89JpY=9R_32U8HywQ@mail.gmail.com>
On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
> Hi Krzysztof,
>
> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> >> as to avoid them being build when not used. This also allows us to use the
> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
> >>
> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >> ---
> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> >> 1 file changed, 6 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> >> index 42e5b66..1899900 100644
> >> --- a/drivers/usb/host/ehci-exynos.c
> >> +++ b/drivers/usb/host/ehci-exynos.c
> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> >> return 0;
> >> }
> >>
> >> -#ifdef CONFIG_PM
> >> +#ifdef CONFIG_PM_SLEEP
> >
> > Does not look like an equivalent change. How will it behave in a config
> > with !SUSPEND && !HIBERNATE && PM?
> >
>
> [snip]
>
> I just wanted to update suspend and resume callback to use
> SET_SYSTEM_SLEEP_PM_OPS
> as they are define under CONFIG_PM_SLEEP so I update above to avoid
> compilation warning/error.
First of all you did not answer to my question, so let me rephrase into
two:
1. Is the code equivalent?
2. What will be the output with !SUSPEND && !HIBERNATE && PM?
You didn't mention compilation warning/error in message commit so I do
not know what you are thinking about...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009163446.GA9672@kozik-lap>
Hi Krzysztof,
On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> as to avoid them being build when not used. This also allows us to use the
>> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>>
>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> ---
>> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> index 42e5b66..1899900 100644
>> --- a/drivers/usb/host/ehci-exynos.c
>> +++ b/drivers/usb/host/ehci-exynos.c
>> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_PM_SLEEP
>
> Does not look like an equivalent change. How will it behave in a config
> with !SUSPEND && !HIBERNATE && PM?
>
[snip]
I just wanted to update suspend and resume callback to use
SET_SYSTEM_SLEEP_PM_OPS
as they are define under CONFIG_PM_SLEEP so I update above to avoid
compilation warning/error.
http://lxr.free-electrons.com/source/include/linux/pm.h#L321
-Best Regards
Anand Moon
^ permalink raw reply
* [PATCH v3 00/17] pinctrl: exynos/samsung: Add header with values used for configuration
From: Krzysztof Kozlowski @ 2016-10-09 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22Eotn=dLyA8KYT_6Fnwvp1sTSxzP8DepAFB2P8EUMME6Q@mail.gmail.com>
On Sun, Oct 09, 2016 at 04:04:11PM +0900, Tomasz Figa wrote:
> Hi Krzysztof,
>
> 2016-09-04 20:04 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> >
> > Hi,
> >
> > Changes since v2
> > ================
> > 1. Combine separate patchsets into one. Previously I sent separately the fixes
> > and changes for S3C platforms.
> > 2. Fix issues pointed during review.
> > 3. Add review tags.
> >
> > Changes since v1
> > ================
> > 1. Follow Arnd's suggestion about moving the macros to common place.
> > 2. Subjects: replace "GPIO" with "pinctrl".
> > 3. There were some major changes here so I did not add Javier's
> > reviewed-by and tested-by tags.
> >
> > Merging
> > =======
> > Patches #1 and #2 should probably go through pinctrl tree. In that case I would
> > appreciate a stable branch/tag so DTS could base on top of it.
> >
> > Goal
> > ====
> > Increase readability:
> > uart0_data: uart0-data {
> > samsung,pins = "gpa0-0", "gpa0-1";
> > - samsung,pin-function = <2>;
> > - samsung,pin-pud = <0>;
> > - samsung,pin-drv = <0>;
> > + samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
> > + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> > + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
>
> I like the idea, thanks for cleaning this up. However I'd like to
> bikeshed the prefix a bit. Since the properties are already prefixed
> by "samsung,", I think it would make much more sense to also prefix
> the generic values with "SAMSUNG_". Of course for soc/family-specific
> values, the soc/family name prefix sounds right.
I am lost. Sorry, I don't get what kind of final prefixes you would like
to have.
SAMSUNG_EXYNOS4_PIN_DRV_LV1
SAMSUNG_EXYNOS5260_PIN_DRV_LV1
?
> Similarly for rest of the value names, such as SAMSUNG_PIN_PUD instead
> of SAMSUNG_PIN_PULL, which obviously sounds more like correct English,
> however hurts the consistency and could confuse the people writing new
> dts files.
SAMSUNG_S3C64XX_PIN_PUD_NONE
SAMSUNG_EXYNOS_PIN_PUD_NONE
?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Krzysztof Kozlowski @ 2016-10-09 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476023655-3232-1-git-send-email-linux.amoon@gmail.com>
On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> as to avoid them being build when not used. This also allows us to use the
> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 42e5b66..1899900 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
Does not look like an equivalent change. How will it behave in a config
with !SUSPEND && !HIBERNATE && PM?
Best regards,
Krzysztof
> static int exynos_ehci_suspend(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> @@ -292,15 +292,13 @@ static int exynos_ehci_resume(struct device *dev)
> ehci_resume(hcd, false);
> return 0;
> }
> -#else
> -#define exynos_ehci_suspend NULL
> -#define exynos_ehci_resume NULL
> -#endif
>
> static const struct dev_pm_ops exynos_ehci_pm_ops = {
> - .suspend = exynos_ehci_suspend,
> - .resume = exynos_ehci_resume,
> + SET_SYSTEM_SLEEP_PM_OPS(exynos_ehci_suspend, exynos_ehci_resume)
> };
> +#endif /* CONFIG_PM_SLEEP */
> +
> +#define DEV_PM_OPS IS_ENABLED(CONFIG_PM_SLEEP) ? &exynos_ehci_pm_ops : NULL
>
> #ifdef CONFIG_OF
> static const struct of_device_id exynos_ehci_match[] = {
> @@ -317,7 +315,7 @@ static struct platform_driver exynos_ehci_driver = {
> .shutdown = usb_hcd_platform_shutdown,
> .driver = {
> .name = "exynos-ehci",
> - .pm = &exynos_ehci_pm_ops,
> + .pm = DEV_PM_OPS,
> .of_match_table = of_match_ptr(exynos_ehci_match),
> }
> };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/2] host: ohci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476023655-3232-1-git-send-email-linux.amoon@gmail.com>
Move the ohci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
as to avoid them being build when not used. This also allows us to use the
SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
drivers/usb/host/ohci-exynos.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 2cd105b..1764baa 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -219,7 +219,7 @@ static void exynos_ohci_shutdown(struct platform_device *pdev)
hcd->driver->shutdown(hcd);
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int exynos_ohci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
@@ -256,18 +256,16 @@ static int exynos_ohci_resume(struct device *dev)
return 0;
}
-#else
-#define exynos_ohci_suspend NULL
-#define exynos_ohci_resume NULL
-#endif
-static const struct ohci_driver_overrides exynos_overrides __initconst = {
- .extra_priv_size = sizeof(struct exynos_ohci_hcd),
+static const struct dev_pm_ops exynos_ohci_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(exynos_ohci_suspend, exynos_ohci_resume)
};
+#endif /* CONFIG_PM_SLEEP */
-static const struct dev_pm_ops exynos_ohci_pm_ops = {
- .suspend = exynos_ohci_suspend,
- .resume = exynos_ohci_resume,
+#define DEV_PM_OPS IS_ENABLED(CONFIG_PM_SLEEP) ? &exynos_ohci_pm_ops : NULL
+
+static const struct ohci_driver_overrides exynos_overrides __initconst = {
+ .extra_priv_size = sizeof(struct exynos_ohci_hcd),
};
#ifdef CONFIG_OF
@@ -285,7 +283,7 @@ static struct platform_driver exynos_ohci_driver = {
.shutdown = exynos_ohci_shutdown,
.driver = {
.name = "exynos-ohci",
- .pm = &exynos_ohci_pm_ops,
+ .pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(exynos_ohci_match),
}
};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 14:34 UTC (permalink / raw)
To: linux-arm-kernel
Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
as to avoid them being build when not used. This also allows us to use the
SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
drivers/usb/host/ehci-exynos.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 42e5b66..1899900 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
return 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
static int exynos_ehci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
@@ -292,15 +292,13 @@ static int exynos_ehci_resume(struct device *dev)
ehci_resume(hcd, false);
return 0;
}
-#else
-#define exynos_ehci_suspend NULL
-#define exynos_ehci_resume NULL
-#endif
static const struct dev_pm_ops exynos_ehci_pm_ops = {
- .suspend = exynos_ehci_suspend,
- .resume = exynos_ehci_resume,
+ SET_SYSTEM_SLEEP_PM_OPS(exynos_ehci_suspend, exynos_ehci_resume)
};
+#endif /* CONFIG_PM_SLEEP */
+
+#define DEV_PM_OPS IS_ENABLED(CONFIG_PM_SLEEP) ? &exynos_ehci_pm_ops : NULL
#ifdef CONFIG_OF
static const struct of_device_id exynos_ehci_match[] = {
@@ -317,7 +315,7 @@ static struct platform_driver exynos_ehci_driver = {
.shutdown = usb_hcd_platform_shutdown,
.driver = {
.name = "exynos-ehci",
- .pm = &exynos_ehci_pm_ops,
+ .pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(exynos_ehci_match),
}
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: rockchip: Add rk3066 MK808 board
From: Shawn Lin @ 2016-10-09 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <876234f84363b4a83c566137866cd823528ed07a.1475957884.git.paweljarosz3691@gmail.com>
? 2016/10/9 4:22, Pawe? Jarosz ??:
> MK808 is a tv stick which has rockchip rk3066 CPU inside, two usb ports
> - host and otg, micro sd card slot and onboard wifi RK901.
>
> Signed-off-by: Pawe? Jarosz <paweljarosz3691@gmail.com>
It looks okay to me, so feel free to add
Reviewed-by: Shawn Lin <shawn.lin@rock-chip.com>
> ---
>
> Changes in v2:
> - included Heiko sugestion.
>
> Changes in v3:
> - added regulators for mmc0 and mmc1
> - added proper pincontrol for mmc1
> - removed regulator-always-on flag from vcc_io
>
> Documentation/devicetree/bindings/arm/rockchip.txt | 4 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/rk3066a-mk808.dts | 196 +++++++++++++++++++++
> 3 files changed, 201 insertions(+)
> create mode 100644 arch/arm/boot/dts/rk3066a-mk808.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
> index 55f388f..c09595b 100644
> --- a/Documentation/devicetree/bindings/arm/rockchip.txt
> +++ b/Documentation/devicetree/bindings/arm/rockchip.txt
> @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
> Required root node properties:
> - compatible = "chipspark,rayeager-px2", "rockchip,rk3066a";
>
> +- Rikomagic MK808 v1 board:
> + Required root node properties:
> + - compatible = "rikomagic,mk808", "rockchip,rk3066a";
> +
> - Radxa Rock board:
> Required root node properties:
> - compatible = "radxa,rock", "rockchip,rk3188";
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..f19cc1d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -639,6 +639,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
> rk3036-kylin.dtb \
> rk3066a-bqcurie2.dtb \
> rk3066a-marsboard.dtb \
> + rk3066a-mk808.dtb \
> rk3066a-rayeager.dtb \
> rk3188-radxarock.dtb \
> rk3228-evb.dtb \
> diff --git a/arch/arm/boot/dts/rk3066a-mk808.dts b/arch/arm/boot/dts/rk3066a-mk808.dts
> new file mode 100644
> index 0000000..0123fa4
> --- /dev/null
> +++ b/arch/arm/boot/dts/rk3066a-mk808.dts
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright (c) 2016 Pawe? Jarosz <paweljarosz3691@gmail.com>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "rk3066a.dtsi"
> +
> +/ {
> + model = "Rikomagic MK808";
> + compatible = "rikomagic,mk808", "rockchip,rk3066a";
> +
> + chosen {
> + stdout-path = "serial2:115200n8";
> + };
> +
> + memory at 60000000 {
> + device_type = "memory";
> + reg = <0x60000000 0x40000000>;
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + blue {
> + label = "mk808:blue:power";
> + gpios = <&gpio0 3 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "default-on";
> + };
> + };
> +
> + vcc_io: vcc-io {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_io";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + vcc_host: usb-host-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 6 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&host_drv>;
> + pinctrl-names = "default";
> + regulator-always-on;
> + regulator-name = "host-pwr";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + startup-delay-us = <100000>;
> + vin-supply = <&vcc_io>;
> + };
> +
> + vcc_otg: usb-otg-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 5 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&otg_drv>;
> + pinctrl-names = "default";
> + regulator-always-on;
> + regulator-name = "vcc_otg";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + startup-delay-us = <100000>;
> + vin-supply = <&vcc_io>;
> + };
> +
> + vcc_sd: sdmmc-regulator {
> + compatible = "regulator-fixed";
> + gpio = <&gpio3 7 GPIO_ACTIVE_LOW>;
> + pinctrl-0 = <&sdmmc_pwr>;
> + pinctrl-names = "default";
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + startup-delay-us = <100000>;
> + vin-supply = <&vcc_io>;
> + };
> +
> + vcc_wifi: sdio-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio3 24 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&wifi_pwr>;
> + pinctrl-names = "default";
> + regulator-name = "vcc_wifi";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + startup-delay-us = <100000>;
> + vin-supply = <&vcc_io>;
> + };
> +};
> +
> +&mmc0 {
> + bus-width = <4>;
> + cap-mmc-highspeed;
> + cap-sd-highspeed;
> + num-slots = <1>;
> + status = "okay";
> + vmmc-supply = <&vcc_sd>;
> +};
> +
> +&mmc1 {
> + bus-width = <4>;
> + disable-wp;
> + non-removable;
> + num-slots = <1>;
> + pinctrl-0 = <&sd1_clk &sd1_cmd &sd1_bus4>;
> + pinctrl-names = "default";
> + status = "okay";
> + vmmc-supply = <&vcc_wifi>;
> +};
> +
> +&pinctrl {
> + usb-host {
> + host_drv: host-drv {
> + rockchip,pins = <RK_GPIO0 6 RK_FUNC_GPIO &pcfg_pull_default>;
> + };
> + };
> +
> + usb-otg {
> + otg_drv: otg-drv {
> + rockchip,pins = <RK_GPIO0 5 RK_FUNC_GPIO &pcfg_pull_default>;
> + };
> + };
> +
> + sdmmc {
> + sdmmc_pwr: sdmmc-pwr {
> + rockchip,pins = <RK_GPIO3 7 RK_FUNC_GPIO &pcfg_pull_default>;
> + };
> + };
> +
> + sdio {
> + wifi_pwr: wifi-pwr {
> + rockchip,pins = <RK_GPIO3 24 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&usb_host {
> + status = "okay";
> +};
> +
> +&usb_otg {
> + status = "okay";
> +};
> +
> +&usbphy {
> + status = "okay";
> +};
> +
> +&wdt {
> + status = "okay";
> +};
> +
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Shawn Lin @ 2016-10-09 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ac786510-74b2-f14c-b2a7-9c65fb07e40f@marvell.com>
? 2016/10/8 17:28, Ziji Hu ??:
> Hi Shawn,
>
> On 2016/10/8 10:44, Shawn Lin wrote:
>> ? 2016/10/7 23:22, Gregory CLEMENT ??:
>>> From: Ziji Hu <huziji@marvell.com>
>>>
>>> Marvell Xenon eMMC/SD/SDIO Host Controller contains PHY.
>>> Three types of PHYs are supported.
>>>
>>> Add support to multiple types of PHYs init and configuration.
>>> Add register definitions of PHYs.
>>>
>>> Signed-off-by: Hu Ziji <huziji@marvell.com>
>>> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>>> ---
>>> MAINTAINERS | 1 +-
>>> drivers/mmc/host/Makefile | 2 +-
>>> drivers/mmc/host/sdhci-xenon-phy.c | 1141 +++++++++++++++++++++++++++++-
>>> drivers/mmc/host/sdhci-xenon-phy.h | 157 ++++-
>>> drivers/mmc/host/sdhci-xenon.c | 4 +-
>>> drivers/mmc/host/sdhci-xenon.h | 17 +-
>>> 6 files changed, 1321 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
>>> create mode 100644 drivers/mmc/host/sdhci-xenon-phy.h
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 859420e5dfd3..b5673c2ee5f2 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -7583,6 +7583,7 @@ M: Ziji Hu <huziji@marvell.com>
>>> L: linux-mmc at vger.kernel.org
>>> S: Supported
>>> F: drivers/mmc/host/sdhci-xenon.*
>>> +F: drivers/mmc/host/sdhci-xenon-phy.*
>>
>> drivers/mmc/host/sdhci-xenon* shoube enough
>>
>>> F: Documentation/devicetree/bindings/mmc/marvell,sdhci-xenon.txt
>>>
>>> MATROX FRAMEBUFFER DRIVER
>>> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
>>> index 75eaf743486c..4f2854556ff7 100644
>>> --- a/drivers/mmc/host/Makefile
>>> +++ b/drivers/mmc/host/Makefile
>>> @@ -82,4 +82,4 @@ ifeq ($(CONFIG_CB710_DEBUG),y)
>>> endif
>>>
>>> obj-$(CONFIG_MMC_SDHCI_XENON) += sdhci-xenon-driver.o
>>> -sdhci-xenon-driver-y += sdhci-xenon.o
>>> +sdhci-xenon-driver-y += sdhci-xenon.o sdhci-xenon-phy.o
>>> diff --git a/drivers/mmc/host/sdhci-xenon-phy.c b/drivers/mmc/host/sdhci-xenon-phy.c
>>> new file mode 100644
>>> index 000000000000..4eb8fea1bec9
>>> --- /dev/null
>>> +++ b/drivers/mmc/host/sdhci-xenon-phy.c
>>
>> Well, it's legit to use phy API and move your phy
>> operations to PHY subsystem. :)
>>
>
> Actually we tried to put the PHY code into Linux PHY framework.
> But it cannot fit in Linux common PHY framework.
>
Indeed, it seems you need much intercation between the phy and host,
but the phy APIs are not so rich. :)
> Our Xenon SDHC PHY register is a part of Xenon SDHC register set.
> Besides, during MMC initialization, MMC sequence has to call several PHY functions to complete timing setting.
> In those PHY setting functions, they have to access SDHC register and know current MMC setting, such as bus width, clock frequency and speed mode.
> As a result, we have to implement PHY under MMC directory.
>
> Thank you.
>
> Best regards,
> Hu Ziji
>
>>> @@ -0,0 +1,1141 @@
>>> +/*
>>> + * PHY support for Xenon SDHC
>>> + *
>>> + * Copyright (C) 2016 Marvell, All Rights Reserved.
>>> + *
>>> + * Author: Hu Ziji <huziji@marvell.com>
>>> + * Date: 2016-8-24
>>> + *
>>> + * 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.
>>> + */
>>> +
>>> +#include <linux/slab.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/mmc/host.h>
>>> +#include <linux/mmc/mmc.h>
>>> +#include <linux/mmc/card.h>
>>> +#include <linux/mmc/sdio.h>
>>> +
>>> +#include "sdhci.h"
>>> +#include "sdhci-pltfm.h"
>>> +#include "sdhci-xenon.h"
>>> +
>>> +static const char * const phy_types[] = {
>>> + "sdh phy",
>>> + "emmc 5.0 phy",
>>> + "emmc 5.1 phy"
>>> +};
>>> +
>>> +enum phy_type_enum {
>>> + SDH_PHY,
>>> + EMMC_5_0_PHY,
>>> + EMMC_5_1_PHY,
>>> + NR_PHY_TYPES
>>> +};
>>> +
>>> +struct soc_pad_ctrl_table {
>>> + const char *soc;
>>> + void (*set_soc_pad)(struct sdhci_host *host,
>>> + unsigned char signal_voltage);
>>> +};
>>> +
>>> +struct soc_pad_ctrl {
>>> + /* Register address of SOC PHY PAD ctrl */
>>> + void __iomem *reg;
>>> + /* SOC PHY PAD ctrl type */
>>> + enum soc_pad_ctrl_type pad_type;
>>> + /* SOC specific operation to set SOC PHY PAD */
>>> + void (*set_soc_pad)(struct sdhci_host *host,
>>> + unsigned char signal_voltage);
>>> +};
>>> +
>>> +static struct xenon_emmc_phy_regs xenon_emmc_5_0_phy_regs = {
>>> + .timing_adj = EMMC_5_0_PHY_TIMING_ADJUST,
>>> + .func_ctrl = EMMC_5_0_PHY_FUNC_CONTROL,
>>> + .pad_ctrl = EMMC_5_0_PHY_PAD_CONTROL,
>>> + .pad_ctrl2 = EMMC_5_0_PHY_PAD_CONTROL2,
>>> + .dll_ctrl = EMMC_5_0_PHY_DLL_CONTROL,
>>> + .logic_timing_adj = EMMC_5_0_PHY_LOGIC_TIMING_ADJUST,
>>> + .delay_mask = EMMC_5_0_PHY_FIXED_DELAY_MASK,
>>> + .dll_update = DLL_UPDATE_STROBE_5_0,
>>> +};
>>> +
>>> +static struct xenon_emmc_phy_regs xenon_emmc_5_1_phy_regs = {
>>> + .timing_adj = EMMC_PHY_TIMING_ADJUST,
>>> + .func_ctrl = EMMC_PHY_FUNC_CONTROL,
>>> + .pad_ctrl = EMMC_PHY_PAD_CONTROL,
>>> + .pad_ctrl2 = EMMC_PHY_PAD_CONTROL2,
>>> + .dll_ctrl = EMMC_PHY_DLL_CONTROL,
>>> + .logic_timing_adj = EMMC_PHY_LOGIC_TIMING_ADJUST,
>>> + .delay_mask = EMMC_PHY_FIXED_DELAY_MASK,
>>> + .dll_update = DLL_UPDATE,
>>> +};
>>> +
>>> +static int xenon_delay_adj_test(struct mmc_card *card);
>>> +
>>> +/*
>>> + * eMMC PHY configuration and operations
>>> + */
>>> +struct emmc_phy_params {
>>> + bool slow_mode;
>>> +
>>> + u8 znr;
>>> + u8 zpr;
>>> +
>>> + /* Nr of consecutive Sampling Points of a Valid Sampling Window */
>>> + u8 nr_tun_times;
>>> + /* Divider for calculating Tuning Step */
>>> + u8 tun_step_divider;
>>> +
>>> + struct soc_pad_ctrl pad_ctrl;
>>> +};
>>> +
>>> +static void xenon_emmc_phy_strobe_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card);
>>> +static int xenon_emmc_phy_fix_sampl_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card);
>>> +static void xenon_emmc_phy_set(struct sdhci_host *host,
>>> + unsigned char timing);
>>> +static void xenon_emmc_set_soc_pad(struct sdhci_host *host,
>>> + unsigned char signal_voltage);
>>> +
>>> +static const struct xenon_phy_ops emmc_phy_ops = {
>>> + .strobe_delay_adj = xenon_emmc_phy_strobe_delay_adj,
>>> + .fix_sampl_delay_adj = xenon_emmc_phy_fix_sampl_delay_adj,
>>> + .phy_set = xenon_emmc_phy_set,
>>> + .set_soc_pad = xenon_emmc_set_soc_pad,
>>> +};
>>> +
>>> +static int alloc_emmc_phy(struct sdhci_xenon_priv *priv)
>>> +{
>>> + struct emmc_phy_params *params;
>>> +
>>> + params = kzalloc(sizeof(*params), GFP_KERNEL);
>>> + if (!params)
>>> + return -ENOMEM;
>>> +
>>> + priv->phy_params = params;
>>> + priv->phy_ops = &emmc_phy_ops;
>>> + if (priv->phy_type == EMMC_5_0_PHY)
>>> + priv->emmc_phy_regs = &xenon_emmc_5_0_phy_regs;
>>> + else
>>> + priv->emmc_phy_regs = &xenon_emmc_5_1_phy_regs;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int xenon_emmc_phy_init(struct sdhci_host *host)
>>> +{
>>> + u32 reg;
>>> + u32 wait, clock;
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct xenon_emmc_phy_regs *phy_regs = priv->emmc_phy_regs;
>>> +
>>> + reg = sdhci_readl(host, phy_regs->timing_adj);
>>> + reg |= PHY_INITIALIZAION;
>>> + sdhci_writel(host, reg, phy_regs->timing_adj);
>>> +
>>> + /* Add duration of FC_SYNC_RST */
>>> + wait = ((reg >> FC_SYNC_RST_DURATION_SHIFT) &
>>> + FC_SYNC_RST_DURATION_MASK);
>>> + /* Add interval between FC_SYNC_EN and FC_SYNC_RST */
>>> + wait += ((reg >> FC_SYNC_RST_EN_DURATION_SHIFT) &
>>> + FC_SYNC_RST_EN_DURATION_MASK);
>>> + /* Add duration of asserting FC_SYNC_EN */
>>> + wait += ((reg >> FC_SYNC_EN_DURATION_SHIFT) &
>>> + FC_SYNC_EN_DURATION_MASK);
>>> + /* Add duration of waiting for PHY */
>>> + wait += ((reg >> WAIT_CYCLE_BEFORE_USING_SHIFT) &
>>> + WAIT_CYCLE_BEFORE_USING_MASK);
>>> + /* 4 addtional bus clock and 4 AXI bus clock are required */
>>> + wait += 8;
>>> + wait <<= 20;
>>> +
>>> + clock = host->clock;
>>> + if (!clock)
>>> + /* Use the possibly slowest bus frequency value */
>>> + clock = LOWEST_SDCLK_FREQ;
>>> + /* get the wait time */
>>> + wait /= clock;
>>> + wait++;
>>> + /* wait for host eMMC PHY init completes */
>>> + udelay(wait);
>>> +
>>> + reg = sdhci_readl(host, phy_regs->timing_adj);
>>> + reg &= PHY_INITIALIZAION;
>>> + if (reg) {
>>> + dev_err(mmc_dev(host->mmc), "eMMC PHY init cannot complete after %d us\n",
>>> + wait);
>>> + return -ETIMEDOUT;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +#define ARMADA_3700_SOC_PAD_1_8V 0x1
>>> +#define ARMADA_3700_SOC_PAD_3_3V 0x0
>>> +
>>> +static void armada_3700_soc_pad_voltage_set(struct sdhci_host *host,
>>> + unsigned char signal_voltage)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct emmc_phy_params *params = priv->phy_params;
>>> +
>>> + if (params->pad_ctrl.pad_type == SOC_PAD_FIXED_1_8V) {
>>> + writel(ARMADA_3700_SOC_PAD_1_8V, params->pad_ctrl.reg);
>>> + } else if (params->pad_ctrl.pad_type == SOC_PAD_SD) {
>>> + if (signal_voltage == MMC_SIGNAL_VOLTAGE_180)
>>> + writel(ARMADA_3700_SOC_PAD_1_8V, params->pad_ctrl.reg);
>>> + else if (signal_voltage == MMC_SIGNAL_VOLTAGE_330)
>>> + writel(ARMADA_3700_SOC_PAD_3_3V, params->pad_ctrl.reg);
>>> + }
>>> +}
>>> +
>>> +static void xenon_emmc_set_soc_pad(struct sdhci_host *host,
>>> + unsigned char signal_voltage)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct emmc_phy_params *params = priv->phy_params;
>>> +
>>> + if (!params->pad_ctrl.reg)
>>> + return;
>>> +
>>> + if (params->pad_ctrl.set_soc_pad)
>>> + params->pad_ctrl.set_soc_pad(host, signal_voltage);
>>> +}
>>> +
>>> +static int emmc_phy_set_fix_sampl_delay(struct sdhci_host *host,
>>> + unsigned int delay,
>>> + bool invert,
>>> + bool delay_90_degree)
>>> +{
>>> + u32 reg;
>>> + unsigned long flags;
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct xenon_emmc_phy_regs *phy_regs = priv->emmc_phy_regs;
>>> + int ret = 0;
>>> +
>>> + spin_lock_irqsave(&host->lock, flags);
>>> +
>>> + /* Setup Sampling fix delay */
>>> + reg = sdhci_readl(host, SDHC_SLOT_OP_STATUS_CTRL);
>>> + reg &= ~phy_regs->delay_mask;
>>> + reg |= delay & phy_regs->delay_mask;
>>> + sdhci_writel(host, reg, SDHC_SLOT_OP_STATUS_CTRL);
>>> +
>>> + if (priv->phy_type == EMMC_5_0_PHY) {
>>> + /* set 90 degree phase if necessary */
>>> + reg &= ~DELAY_90_DEGREE_MASK_EMMC5;
>>> + reg |= (delay_90_degree << DELAY_90_DEGREE_SHIFT_EMMC5);
>>> + sdhci_writel(host, reg, SDHC_SLOT_OP_STATUS_CTRL);
>>> + }
>>> +
>>> + /* Disable SDCLK */
>>> + reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
>>> + reg &= ~(SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN);
>>> + sdhci_writel(host, reg, SDHCI_CLOCK_CONTROL);
>>> +
>>> + udelay(200);
>>> +
>>> + if (priv->phy_type == EMMC_5_1_PHY) {
>>> + /* set 90 degree phase if necessary */
>>> + reg = sdhci_readl(host, EMMC_PHY_FUNC_CONTROL);
>>> + reg &= ~ASYNC_DDRMODE_MASK;
>>> + reg |= (delay_90_degree << ASYNC_DDRMODE_SHIFT);
>>> + sdhci_writel(host, reg, EMMC_PHY_FUNC_CONTROL);
>>> + }
>>> +
>>> + /* Setup Inversion of Sampling edge */
>>> + reg = sdhci_readl(host, phy_regs->timing_adj);
>>> + reg &= ~SAMPL_INV_QSP_PHASE_SELECT;
>>> + reg |= (invert << SAMPL_INV_QSP_PHASE_SELECT_SHIFT);
>>> + sdhci_writel(host, reg, phy_regs->timing_adj);
>>> +
>>> + /* Enable SD internal clock */
>>> + ret = enable_xenon_internal_clk(host);
>>> + if (ret)
>>> + goto out;
>>> +
>>> + /* Enable SDCLK */
>>> + reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
>>> + reg |= SDHCI_CLOCK_CARD_EN;
>>> + sdhci_writel(host, reg, SDHCI_CLOCK_CONTROL);
>>> +
>>> + udelay(200);
>>> +
>>> + /*
>>> + * Has to re-initialize eMMC PHY here to active PHY
>>> + * because later get status cmd will be issued.
>>> + */
>>> + ret = xenon_emmc_phy_init(host);
>>> +
>>> +out:
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> + return ret;
>>> +}
>>> +
>>> +static int emmc_phy_do_fix_sampl_delay(struct sdhci_host *host,
>>> + struct mmc_card *card,
>>> + unsigned int delay,
>>> + bool invert, bool quarter)
>>> +{
>>> + int ret;
>>> +
>>> + emmc_phy_set_fix_sampl_delay(host, delay, invert, quarter);
>>> +
>>> + ret = xenon_delay_adj_test(card);
>>> + if (ret) {
>>> + dev_dbg(mmc_dev(host->mmc),
>>> + "fail when sampling fix delay = %d, phase = %d degree\n",
>>> + delay, invert * 180 + quarter * 90);
>>> + return -1;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static int xenon_emmc_phy_fix_sampl_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card)
>>> +{
>>> + enum sampl_fix_delay_phase phase;
>>> + int idx, nr_pair;
>>> + int ret;
>>> + unsigned int delay;
>>> + unsigned int min_delay, max_delay;
>>> + bool invert, quarter;
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct xenon_emmc_phy_regs *phy_regs = priv->emmc_phy_regs;
>>> + u32 coarse_step, fine_step;
>>> + const enum sampl_fix_delay_phase delay_edge[] = {
>>> + PHASE_0_DEGREE,
>>> + PHASE_180_DEGREE,
>>> + PHASE_90_DEGREE,
>>> + PHASE_270_DEGREE
>>> + };
>>> +
>>> + coarse_step = phy_regs->delay_mask >> 1;
>>> + fine_step = coarse_step >> 2;
>>> +
>>> + nr_pair = ARRAY_SIZE(delay_edge);
>>> +
>>> + for (idx = 0; idx < nr_pair; idx++) {
>>> + phase = delay_edge[idx];
>>> + invert = (phase & 0x2) ? true : false;
>>> + quarter = (phase & 0x1) ? true : false;
>>> +
>>> + /* increase delay value to get fix delay */
>>> + for (min_delay = 0;
>>> + min_delay <= phy_regs->delay_mask;
>>> + min_delay += coarse_step) {
>>> + ret = emmc_phy_do_fix_sampl_delay(host, card, min_delay,
>>> + invert, quarter);
>>> + if (!ret)
>>> + break;
>>> + }
>>> +
>>> + if (ret) {
>>> + dev_dbg(mmc_dev(host->mmc),
>>> + "Fail to set Sampling Fixed Delay with phase = %d degree\n",
>>> + phase * 90);
>>> + continue;
>>> + }
>>> +
>>> + for (max_delay = min_delay + fine_step;
>>> + max_delay < phy_regs->delay_mask;
>>> + max_delay += fine_step) {
>>> + ret = emmc_phy_do_fix_sampl_delay(host, card, max_delay,
>>> + invert, quarter);
>>> + if (ret) {
>>> + max_delay -= fine_step;
>>> + break;
>>> + }
>>> + }
>>> +
>>> + if (!ret) {
>>> + ret = emmc_phy_do_fix_sampl_delay(host, card,
>>> + phy_regs->delay_mask,
>>> + invert, quarter);
>>> + if (!ret)
>>> + max_delay = phy_regs->delay_mask;
>>> + }
>>> +
>>> + /*
>>> + * Sampling Fixed Delay line window should be large enough,
>>> + * thus the sampling point (the middle of the window)
>>> + * can work when environment varies.
>>> + * However, there is no clear conclusion how large the window
>>> + * should be.
>>> + */
>>> + if ((max_delay - min_delay) <=
>>> + EMMC_PHY_FIXED_DELAY_WINDOW_MIN) {
>>> + dev_info(mmc_dev(host->mmc),
>>> + "The window size %d with phase = %d degree is too small\n",
>>> + max_delay - min_delay, phase * 90);
>>> + continue;
>>> + }
>>> +
>>> + delay = (min_delay + max_delay) / 2;
>>> + emmc_phy_set_fix_sampl_delay(host, delay, invert, quarter);
>>> + dev_dbg(mmc_dev(host->mmc),
>>> + "sampling fix delay = %d with phase = %d degree\n",
>>> + delay, phase * 90);
>>> + return 0;
>>> + }
>>> +
>>> + return -EIO;
>>> +}
>>> +
>>> +static int xenon_emmc_phy_enable_dll(struct sdhci_host *host)
>>> +{
>>> + u32 reg;
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct xenon_emmc_phy_regs *phy_regs = priv->emmc_phy_regs;
>>> + u8 timeout;
>>> +
>>> + if (WARN_ON(host->clock <= MMC_HIGH_52_MAX_DTR))
>>> + return -EINVAL;
>>> +
>>> + reg = sdhci_readl(host, phy_regs->dll_ctrl);
>>> + if (reg & DLL_ENABLE)
>>> + return 0;
>>> +
>>> + /* Enable DLL */
>>> + reg = sdhci_readl(host, phy_regs->dll_ctrl);
>>> + reg |= (DLL_ENABLE | DLL_FAST_LOCK);
>>> +
>>> + /*
>>> + * Set Phase as 90 degree, which is most common value.
>>> + * Might set another value if necessary.
>>> + * The granularity is 1 degree.
>>> + */
>>> + reg &= ~((DLL_PHASE_MASK << DLL_PHSEL0_SHIFT) |
>>> + (DLL_PHASE_MASK << DLL_PHSEL1_SHIFT));
>>> + reg |= ((DLL_PHASE_90_DEGREE << DLL_PHSEL0_SHIFT) |
>>> + (DLL_PHASE_90_DEGREE << DLL_PHSEL1_SHIFT));
>>> +
>>> + reg &= ~DLL_BYPASS_EN;
>>> + reg |= phy_regs->dll_update;
>>> + if (priv->phy_type == EMMC_5_1_PHY)
>>> + reg &= ~DLL_REFCLK_SEL;
>>> + sdhci_writel(host, reg, phy_regs->dll_ctrl);
>>> +
>>> + /* Wait max 32 ms */
>>> + timeout = 32;
>>> + while (!(sdhci_readw(host, SDHC_SLOT_EXT_PRESENT_STATE) & LOCK_STATE)) {
>>> + if (!timeout) {
>>> + dev_err(mmc_dev(host->mmc), "Wait for DLL Lock time-out\n");
>>> + return -ETIMEDOUT;
>>> + }
>>> + timeout--;
>>> + mdelay(1);
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static int __emmc_phy_config_tuning(struct sdhci_host *host)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct emmc_phy_params *params = priv->phy_params;
>>> + u32 reg, tuning_step;
>>> + int ret;
>>> + unsigned long flags;
>>> +
>>> + if (WARN_ON(host->clock <= MMC_HIGH_52_MAX_DTR))
>>> + return -EINVAL;
>>> +
>>> + spin_lock_irqsave(&host->lock, flags);
>>> +
>>> + ret = xenon_emmc_phy_enable_dll(host);
>>> + if (ret) {
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> + return ret;
>>> + }
>>> +
>>> + reg = sdhci_readl(host, SDHC_SLOT_DLL_CUR_DLY_VAL);
>>> + tuning_step = reg / params->tun_step_divider;
>>> + if (unlikely(tuning_step > TUNING_STEP_MASK)) {
>>> + dev_warn(mmc_dev(host->mmc),
>>> + "HS200 TUNING_STEP %d is larger than MAX value\n",
>>> + tuning_step);
>>> + tuning_step = TUNING_STEP_MASK;
>>> + }
>>> +
>>> + reg = sdhci_readl(host, SDHC_SLOT_OP_STATUS_CTRL);
>>> + reg &= ~(TUN_CONSECUTIVE_TIMES_MASK << TUN_CONSECUTIVE_TIMES_SHIFT);
>>> + reg |= (params->nr_tun_times << TUN_CONSECUTIVE_TIMES_SHIFT);
>>> + reg &= ~(TUNING_STEP_MASK << TUNING_STEP_SHIFT);
>>> + reg |= (tuning_step << TUNING_STEP_SHIFT);
>>> + sdhci_writel(host, reg, SDHC_SLOT_OP_STATUS_CTRL);
>>> +
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> + return 0;
>>> +}
>>> +
>>> +static int xenon_emmc_phy_config_tuning(struct sdhci_host *host)
>>> +{
>>> + return __emmc_phy_config_tuning(host);
>>> +}
>>> +
>>> +static void xenon_emmc_phy_strobe_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card)
>>> +{
>>> + u32 reg;
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + unsigned long flags;
>>> +
>>> + if (host->clock <= MMC_HIGH_52_MAX_DTR)
>>> + return;
>>> +
>>> + dev_dbg(mmc_dev(host->mmc), "starts HS400 strobe delay adjustment\n");
>>> +
>>> + spin_lock_irqsave(&host->lock, flags);
>>> +
>>> + xenon_emmc_phy_enable_dll(host);
>>> +
>>> + /* Enable SDHC Data Strobe */
>>> + reg = sdhci_readl(host, SDHC_SLOT_EMMC_CTRL);
>>> + reg |= ENABLE_DATA_STROBE;
>>> + sdhci_writel(host, reg, SDHC_SLOT_EMMC_CTRL);
>>> +
>>> + /* Set Data Strobe Pull down */
>>> + if (priv->phy_type == EMMC_5_0_PHY) {
>>> + reg = sdhci_readl(host, EMMC_5_0_PHY_PAD_CONTROL);
>>> + reg |= EMMC5_FC_QSP_PD;
>>> + reg &= ~EMMC5_FC_QSP_PU;
>>> + sdhci_writel(host, reg, EMMC_5_0_PHY_PAD_CONTROL);
>>> + } else {
>>> + reg = sdhci_readl(host, EMMC_PHY_PAD_CONTROL1);
>>> + reg |= EMMC5_1_FC_QSP_PD;
>>> + reg &= ~EMMC5_1_FC_QSP_PU;
>>> + sdhci_writel(host, reg, EMMC_PHY_PAD_CONTROL1);
>>> + }
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> +}
>>> +
>>> +#define LOGIC_TIMING_VALUE 0x00AA8977
>>> +
>>> +static void xenon_emmc_phy_set(struct sdhci_host *host,
>>> + unsigned char timing)
>>> +{
>>> + u32 reg;
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + struct emmc_phy_params *params = priv->phy_params;
>>> + struct xenon_emmc_phy_regs *phy_regs = priv->emmc_phy_regs;
>>> + struct mmc_card *card = priv->card_candidate;
>>> + unsigned long flags;
>>> +
>>> + dev_dbg(mmc_dev(host->mmc), "eMMC PHY setting starts\n");
>>> +
>>> + spin_lock_irqsave(&host->lock, flags);
>>> +
>>> + /* Setup pad, set bit[28] and bits[26:24] */
>>> + reg = sdhci_readl(host, phy_regs->pad_ctrl);
>>> + reg |= (FC_DQ_RECEN | FC_CMD_RECEN | FC_QSP_RECEN | OEN_QSN);
>>> + /*
>>> + * All FC_XX_RECEIVCE should be set as CMOS Type
>>> + */
>>> + reg |= FC_ALL_CMOS_RECEIVER;
>>> + sdhci_writel(host, reg, phy_regs->pad_ctrl);
>>> +
>>> + /* Set CMD and DQ Pull Up */
>>> + if (priv->phy_type == EMMC_5_0_PHY) {
>>> + reg = sdhci_readl(host, EMMC_5_0_PHY_PAD_CONTROL);
>>> + reg |= (EMMC5_FC_CMD_PU | EMMC5_FC_DQ_PU);
>>> + reg &= ~(EMMC5_FC_CMD_PD | EMMC5_FC_DQ_PD);
>>> + sdhci_writel(host, reg, EMMC_5_0_PHY_PAD_CONTROL);
>>> + } else {
>>> + reg = sdhci_readl(host, EMMC_PHY_PAD_CONTROL1);
>>> + reg |= (EMMC5_1_FC_CMD_PU | EMMC5_1_FC_DQ_PU);
>>> + reg &= ~(EMMC5_1_FC_CMD_PD | EMMC5_1_FC_DQ_PD);
>>> + sdhci_writel(host, reg, EMMC_PHY_PAD_CONTROL1);
>>> + }
>>> +
>>> + if ((timing == MMC_TIMING_LEGACY) || !card)
>>> + goto phy_init;
>>> +
>>> + /*
>>> + * FIXME: should depends on the specific board timing.
>>> + */
>>> + if ((timing == MMC_TIMING_MMC_HS400) ||
>>> + (timing == MMC_TIMING_MMC_HS200) ||
>>> + (timing == MMC_TIMING_UHS_SDR50) ||
>>> + (timing == MMC_TIMING_UHS_SDR104) ||
>>> + (timing == MMC_TIMING_UHS_DDR50) ||
>>> + (timing == MMC_TIMING_UHS_SDR25) ||
>>> + (timing == MMC_TIMING_MMC_DDR52)) {
>>> + reg = sdhci_readl(host, phy_regs->timing_adj);
>>> + reg &= ~OUTPUT_QSN_PHASE_SELECT;
>>> + sdhci_writel(host, reg, phy_regs->timing_adj);
>>> + }
>>> +
>>> + /*
>>> + * If SDIO card, set SDIO Mode
>>> + * Otherwise, clear SDIO Mode and Slow Mode
>>> + */
>>> + if (mmc_card_sdio(card)) {
>>> + reg = sdhci_readl(host, phy_regs->timing_adj);
>>> + reg |= TIMING_ADJUST_SDIO_MODE;
>>> +
>>> + if ((timing == MMC_TIMING_UHS_SDR25) ||
>>> + (timing == MMC_TIMING_UHS_SDR12) ||
>>> + (timing == MMC_TIMING_SD_HS) ||
>>> + (timing == MMC_TIMING_LEGACY))
>>> + reg |= TIMING_ADJUST_SLOW_MODE;
>>> +
>>> + sdhci_writel(host, reg, phy_regs->timing_adj);
>>> + } else {
>>> + reg = sdhci_readl(host, phy_regs->timing_adj);
>>> + reg &= ~(TIMING_ADJUST_SDIO_MODE | TIMING_ADJUST_SLOW_MODE);
>>> + sdhci_writel(host, reg, phy_regs->timing_adj);
>>> + }
>>> +
>>> + if (((timing == MMC_TIMING_UHS_SDR50) ||
>>> + (timing == MMC_TIMING_UHS_SDR25) ||
>>> + (timing == MMC_TIMING_UHS_SDR12) ||
>>> + (timing == MMC_TIMING_SD_HS) ||
>>> + (timing == MMC_TIMING_MMC_HS) ||
>>> + (timing == MMC_TIMING_LEGACY)) && params->slow_mode) {
>>> + reg = sdhci_readl(host, phy_regs->timing_adj);
>>> + reg |= TIMING_ADJUST_SLOW_MODE;
>>> + sdhci_writel(host, reg, phy_regs->timing_adj);
>>> + }
>>> +
>>> + /*
>>> + * Set preferred ZNR and ZPR value
>>> + * The ZNR and ZPR value vary between different boards.
>>> + * Define them both in sdhci-xenon-emmc-phy.h.
>>> + */
>>> + reg = sdhci_readl(host, phy_regs->pad_ctrl2);
>>> + reg &= ~((ZNR_MASK << ZNR_SHIFT) | ZPR_MASK);
>>> + reg |= ((params->znr << ZNR_SHIFT) | params->zpr);
>>> + sdhci_writel(host, reg, phy_regs->pad_ctrl2);
>>> +
>>> + /*
>>> + * When setting EMMC_PHY_FUNC_CONTROL register,
>>> + * SD clock should be disabled
>>> + */
>>> + reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
>>> + reg &= ~SDHCI_CLOCK_CARD_EN;
>>> + sdhci_writew(host, reg, SDHCI_CLOCK_CONTROL);
>>> +
>>> + if ((timing == MMC_TIMING_UHS_DDR50) ||
>>> + (timing == MMC_TIMING_MMC_HS400) ||
>>> + (timing == MMC_TIMING_MMC_DDR52)) {
>>> + reg = sdhci_readl(host, phy_regs->func_ctrl);
>>> + reg |= (DQ_DDR_MODE_MASK << DQ_DDR_MODE_SHIFT) | CMD_DDR_MODE;
>>> + sdhci_writel(host, reg, phy_regs->func_ctrl);
>>> + }
>>> +
>>> + if (timing == MMC_TIMING_MMC_HS400) {
>>> + reg = sdhci_readl(host, phy_regs->func_ctrl);
>>> + reg &= ~DQ_ASYNC_MODE;
>>> + sdhci_writel(host, reg, phy_regs->func_ctrl);
>>> + }
>>> +
>>> + /* Enable bus clock */
>>> + reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
>>> + reg |= SDHCI_CLOCK_CARD_EN;
>>> + sdhci_writew(host, reg, SDHCI_CLOCK_CONTROL);
>>> +
>>> + if (timing == MMC_TIMING_MMC_HS400)
>>> + /* Hardware team recommend a value for HS400 */
>>> + sdhci_writel(host, LOGIC_TIMING_VALUE,
>>> + phy_regs->logic_timing_adj);
>>> +
>>> +phy_init:
>>> + xenon_emmc_phy_init(host);
>>> +
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> +
>>> + dev_dbg(mmc_dev(host->mmc), "eMMC PHY setting completes\n");
>>> +}
>>> +
>>> +static int get_dt_pad_ctrl_data(struct sdhci_host *host,
>>> + struct device_node *np,
>>> + struct emmc_phy_params *params)
>>> +{
>>> + int ret = 0;
>>> + const char *name;
>>> + struct resource iomem;
>>> +
>>> + if (of_device_is_compatible(np, "marvell,armada-3700-sdhci"))
>>> + params->pad_ctrl.set_soc_pad = armada_3700_soc_pad_voltage_set;
>>> + else
>>> + return 0;
>>> +
>>> + if (of_address_to_resource(np, 1, &iomem)) {
>>> + dev_err(mmc_dev(host->mmc), "Unable to find SOC PAD ctrl register address for %s\n",
>>> + np->name);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + params->pad_ctrl.reg = devm_ioremap_resource(mmc_dev(host->mmc),
>>> + &iomem);
>>> + if (IS_ERR(params->pad_ctrl.reg)) {
>>> + dev_err(mmc_dev(host->mmc), "Unable to get SOC PHY PAD ctrl regiser for %s\n",
>>> + np->name);
>>> + return PTR_ERR(params->pad_ctrl.reg);
>>> + }
>>> +
>>> + ret = of_property_read_string(np, "xenon,pad-type", &name);
>>> + if (ret) {
>>> + dev_err(mmc_dev(host->mmc), "Unable to determine SOC PHY PAD ctrl type\n");
>>> + return ret;
>>> + }
>>> + if (!strcmp(name, "sd")) {
>>> + params->pad_ctrl.pad_type = SOC_PAD_SD;
>>> + } else if (!strcmp(name, "fixed-1-8v")) {
>>> + params->pad_ctrl.pad_type = SOC_PAD_FIXED_1_8V;
>>> + } else {
>>> + dev_err(mmc_dev(host->mmc), "Unsupported SOC PHY PAD ctrl type %s\n",
>>> + name);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int emmc_phy_parse_param_dt(struct sdhci_host *host,
>>> + struct device_node *np,
>>> + struct emmc_phy_params *params)
>>> +{
>>> + u32 value;
>>> +
>>> + if (of_property_read_bool(np, "xenon,phy-slow-mode"))
>>> + params->slow_mode = true;
>>> + else
>>> + params->slow_mode = false;
>>> +
>>> + if (!of_property_read_u32(np, "xenon,phy-znr", &value))
>>> + params->znr = value & ZNR_MASK;
>>> + else
>>> + params->znr = ZNR_DEF_VALUE;
>>> +
>>> + if (!of_property_read_u32(np, "xenon,phy-zpr", &value))
>>> + params->zpr = value & ZPR_MASK;
>>> + else
>>> + params->zpr = ZPR_DEF_VALUE;
>>> +
>>> + if (!of_property_read_u32(np, "xenon,phy-nr-tun-times", &value))
>>> + params->nr_tun_times = value & TUN_CONSECUTIVE_TIMES_MASK;
>>> + else
>>> + params->nr_tun_times = TUN_CONSECUTIVE_TIMES;
>>> +
>>> + if (!of_property_read_u32(np, "xenon,phy-tun-step-divider", &value))
>>> + params->tun_step_divider = value & 0xFF;
>>> + else
>>> + params->tun_step_divider = TUNING_STEP_DIVIDER;
>>> +
>>> + return get_dt_pad_ctrl_data(host, np, params);
>>> +}
>>> +
>>> +/*
>>> + * SDH PHY configuration and operations
>>> + */
>>> +static int xenon_sdh_phy_set_fix_sampl_delay(struct sdhci_host *host,
>>> + unsigned int delay, bool invert)
>>> +{
>>> + u32 reg;
>>> + unsigned long flags;
>>> + int ret;
>>> +
>>> + if (invert)
>>> + invert = 0x1;
>>> + else
>>> + invert = 0x0;
>>> +
>>> + spin_lock_irqsave(&host->lock, flags);
>>> +
>>> + /* Disable SDCLK */
>>> + reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
>>> + reg &= ~(SDHCI_CLOCK_CARD_EN | SDHCI_CLOCK_INT_EN);
>>> + sdhci_writel(host, reg, SDHCI_CLOCK_CONTROL);
>>> +
>>> + udelay(200);
>>> +
>>> + /* Setup Sampling fix delay */
>>> + reg = sdhci_readl(host, SDHC_SLOT_OP_STATUS_CTRL);
>>> + reg &= ~(SDH_PHY_FIXED_DELAY_MASK |
>>> + (0x1 << FORCE_SEL_INVERSE_CLK_SHIFT));
>>> + reg |= ((delay & SDH_PHY_FIXED_DELAY_MASK) |
>>> + (invert << FORCE_SEL_INVERSE_CLK_SHIFT));
>>> + sdhci_writel(host, reg, SDHC_SLOT_OP_STATUS_CTRL);
>>> +
>>> + /* Enable SD internal clock */
>>> + ret = enable_xenon_internal_clk(host);
>>> +
>>> + /* Enable SDCLK */
>>> + reg = sdhci_readl(host, SDHCI_CLOCK_CONTROL);
>>> + reg |= SDHCI_CLOCK_CARD_EN;
>>> + sdhci_writel(host, reg, SDHCI_CLOCK_CONTROL);
>>> +
>>> + udelay(200);
>>> +
>>> + spin_unlock_irqrestore(&host->lock, flags);
>>> + return ret;
>>> +}
>>> +
>>> +static int sdh_phy_do_fix_sampl_delay(struct sdhci_host *host,
>>> + struct mmc_card *card,
>>> + unsigned int delay, bool invert)
>>> +{
>>> + int ret;
>>> +
>>> + xenon_sdh_phy_set_fix_sampl_delay(host, delay, invert);
>>> +
>>> + ret = xenon_delay_adj_test(card);
>>> + if (ret) {
>>> + dev_dbg(mmc_dev(host->mmc),
>>> + "fail when sampling fix delay = %d, phase = %d degree\n",
>>> + delay, invert * 180);
>>> + return -1;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +#define SDH_PHY_COARSE_FIX_DELAY (SDH_PHY_FIXED_DELAY_MASK / 2)
>>> +#define SDH_PHY_FINE_FIX_DELAY (SDH_PHY_COARSE_FIX_DELAY / 4)
>>> +
>>> +static int xenon_sdh_phy_fix_sampl_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card)
>>> +{
>>> + u32 reg;
>>> + bool dll_enable = false;
>>> + unsigned int min_delay, max_delay, delay;
>>> + const bool sampl_edge[] = {
>>> + false,
>>> + true,
>>> + };
>>> + int i, nr;
>>> + int ret;
>>> +
>>> + if (host->clock > HIGH_SPEED_MAX_DTR) {
>>> + /* Enable DLL when SDCLK is higher than 50MHz */
>>> + reg = sdhci_readl(host, SDH_PHY_SLOT_DLL_CTRL);
>>> + if (!(reg & SDH_PHY_ENABLE_DLL)) {
>>> + reg |= (SDH_PHY_ENABLE_DLL | SDH_PHY_FAST_LOCK_EN);
>>> + sdhci_writel(host, reg, SDH_PHY_SLOT_DLL_CTRL);
>>> + mdelay(1);
>>> +
>>> + reg = sdhci_readl(host, SDH_PHY_SLOT_DLL_PHASE_SEL);
>>> + reg |= SDH_PHY_DLL_UPDATE_TUNING;
>>> + sdhci_writel(host, reg, SDH_PHY_SLOT_DLL_PHASE_SEL);
>>> + }
>>> + dll_enable = true;
>>> + }
>>> +
>>> + nr = dll_enable ? ARRAY_SIZE(sampl_edge) : 1;
>>> + for (i = 0; i < nr; i++) {
>>> + for (min_delay = 0; min_delay <= SDH_PHY_FIXED_DELAY_MASK;
>>> + min_delay += SDH_PHY_COARSE_FIX_DELAY) {
>>> + ret = sdh_phy_do_fix_sampl_delay(host, card, min_delay,
>>> + sampl_edge[i]);
>>> + if (!ret)
>>> + break;
>>> + }
>>> +
>>> + if (ret) {
>>> + dev_dbg(mmc_dev(host->mmc),
>>> + "Fail to set Fixed Sampling Delay with %s edge\n",
>>> + sampl_edge[i] ? "negative" : "positive");
>>> + continue;
>>> + }
>>> +
>>> + for (max_delay = min_delay + SDH_PHY_FINE_FIX_DELAY;
>>> + max_delay < SDH_PHY_FIXED_DELAY_MASK;
>>> + max_delay += SDH_PHY_FINE_FIX_DELAY) {
>>> + ret = sdh_phy_do_fix_sampl_delay(host, card, max_delay,
>>> + sampl_edge[i]);
>>> + if (ret) {
>>> + max_delay -= SDH_PHY_FINE_FIX_DELAY;
>>> + break;
>>> + }
>>> + }
>>> +
>>> + if (!ret) {
>>> + delay = SDH_PHY_FIXED_DELAY_MASK;
>>> + ret = sdh_phy_do_fix_sampl_delay(host, card, delay,
>>> + sampl_edge[i]);
>>> + if (!ret)
>>> + max_delay = SDH_PHY_FIXED_DELAY_MASK;
>>> + }
>>> +
>>> + if ((max_delay - min_delay) <= SDH_PHY_FIXED_DELAY_WINDOW_MIN) {
>>> + dev_info(mmc_dev(host->mmc),
>>> + "The window size %d with %s edge is too small\n",
>>> + max_delay - min_delay,
>>> + sampl_edge[i] ? "negative" : "positive");
>>> + continue;
>>> + }
>>> +
>>> + delay = (min_delay + max_delay) / 2;
>>> + xenon_sdh_phy_set_fix_sampl_delay(host, delay, sampl_edge[i]);
>>> + dev_dbg(mmc_dev(host->mmc), "sampling fix delay = %d with %s edge\n",
>>> + delay, sampl_edge[i] ? "negative" : "positive");
>>> + return 0;
>>> + }
>>> + return -EIO;
>>> +}
>>> +
>>> +static const struct xenon_phy_ops sdh_phy_ops = {
>>> + .fix_sampl_delay_adj = xenon_sdh_phy_fix_sampl_delay_adj,
>>> +};
>>> +
>>> +static int alloc_sdh_phy(struct sdhci_xenon_priv *priv)
>>> +{
>>> + priv->phy_params = NULL;
>>> + priv->phy_ops = &sdh_phy_ops;
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Common functions for all PHYs
>>> + */
>>> +void xenon_soc_pad_ctrl(struct sdhci_host *host,
>>> + unsigned char signal_voltage)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> +
>>> + if (priv->phy_ops->set_soc_pad)
>>> + priv->phy_ops->set_soc_pad(host, signal_voltage);
>>> +}
>>> +
>>> +static int __xenon_emmc_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + int err;
>>> + u8 *ext_csd = NULL;
>>> +
>>> + err = mmc_get_ext_csd(card, &ext_csd);
>>> + kfree(ext_csd);
>>> +
>>> + return err;
>>> +}
>>> +
>>> +static int __xenon_sdio_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + struct mmc_command cmd = {0};
>>> + int err;
>>> +
>>> + cmd.opcode = SD_IO_RW_DIRECT;
>>> + cmd.flags = MMC_RSP_R5 | MMC_CMD_AC;
>>> +
>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>> + if (err)
>>> + return err;
>>> +
>>> + if (cmd.resp[0] & R5_ERROR)
>>> + return -EIO;
>>> + if (cmd.resp[0] & R5_FUNCTION_NUMBER)
>>> + return -EINVAL;
>>> + if (cmd.resp[0] & R5_OUT_OF_RANGE)
>>> + return -ERANGE;
>>> + return 0;
>>> +}
>>> +
>>> +static int __xenon_sd_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + struct mmc_command cmd = {0};
>>> + int err;
>>> +
>>> + cmd.opcode = MMC_SEND_STATUS;
>>> + cmd.arg = card->rca << 16;
>>> + cmd.flags = MMC_RSP_R1 | MMC_CMD_AC;
>>> +
>>> + err = mmc_wait_for_cmd(card->host, &cmd, 0);
>>> + return err;
>>> +}
>>> +
>>> +static int xenon_delay_adj_test(struct mmc_card *card)
>>> +{
>>> + WARN_ON(!card);
>>> + WARN_ON(!card->host);
>>> +
>>> + if (mmc_card_mmc(card))
>>> + return __xenon_emmc_delay_adj_test(card);
>>> + else if (mmc_card_sd(card))
>>> + return __xenon_sd_delay_adj_test(card);
>>> + else if (mmc_card_sdio(card))
>>> + return __xenon_sdio_delay_adj_test(card);
>>> + else
>>> + return -EINVAL;
>>> +}
>>> +
>>> +static void xenon_phy_set(struct sdhci_host *host, unsigned char timing)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> +
>>> + if (priv->phy_ops->phy_set)
>>> + priv->phy_ops->phy_set(host, timing);
>>> +}
>>> +
>>> +static void xenon_hs400_strobe_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> +
>>> + if (WARN_ON(!mmc_card_hs400(card)))
>>> + return;
>>> +
>>> + /* Enable the DLL to automatically adjust HS400 strobe delay.
>>> + */
>>> + if (priv->phy_ops->strobe_delay_adj)
>>> + priv->phy_ops->strobe_delay_adj(host, card);
>>> +}
>>> +
>>> +static int xenon_fix_sampl_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> +
>>> + if (priv->phy_ops->fix_sampl_delay_adj)
>>> + return priv->phy_ops->fix_sampl_delay_adj(host, card);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * xenon_delay_adj should not be called inside IRQ context,
>>> + * either Hard IRQ or Softirq.
>>> + */
>>> +static int xenon_hs_delay_adj(struct sdhci_host *host,
>>> + struct mmc_card *card)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + int ret = 0;
>>> +
>>> + if (WARN_ON(host->clock <= DEFAULT_SDCLK_FREQ))
>>> + return -EINVAL;
>>> +
>>> + if (mmc_card_hs400(card)) {
>>> + xenon_hs400_strobe_delay_adj(host, card);
>>> + return 0;
>>> + }
>>> +
>>> + if (((priv->phy_type == EMMC_5_1_PHY) ||
>>> + (priv->phy_type == EMMC_5_0_PHY)) &&
>>> + (mmc_card_hs200(card) ||
>>> + (host->timing == MMC_TIMING_UHS_SDR104))) {
>>> + ret = xenon_emmc_phy_config_tuning(host);
>>> + if (!ret)
>>> + return 0;
>>> + }
>>> +
>>> + ret = xenon_fix_sampl_delay_adj(host, card);
>>> + if (ret)
>>> + dev_err(mmc_dev(host->mmc), "fails sampling fixed delay adjustment\n");
>>> + return ret;
>>> +}
>>> +
>>> +int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios)
>>> +{
>>> + struct mmc_host *mmc = host->mmc;
>>> + struct mmc_card *card;
>>> + int ret = 0;
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> +
>>> + if (!host->clock) {
>>> + priv->clock = 0;
>>> + return 0;
>>> + }
>>> +
>>> + /*
>>> + * The timing, frequency or bus width is changed,
>>> + * better to set eMMC PHY based on current setting
>>> + * and adjust Xenon SDHC delay.
>>> + */
>>> + if ((host->clock == priv->clock) &&
>>> + (ios->bus_width == priv->bus_width) &&
>>> + (ios->timing == priv->timing))
>>> + return 0;
>>> +
>>> + xenon_phy_set(host, ios->timing);
>>> +
>>> + /* Update the record */
>>> + priv->bus_width = ios->bus_width;
>>> + /* Temp stage from HS200 to HS400 */
>>> + if (((priv->timing == MMC_TIMING_MMC_HS200) &&
>>> + (ios->timing == MMC_TIMING_MMC_HS)) ||
>>> + ((ios->timing == MMC_TIMING_MMC_HS) &&
>>> + (priv->clock > host->clock))) {
>>> + priv->timing = ios->timing;
>>> + priv->clock = host->clock;
>>> + return 0;
>>> + }
>>> + priv->timing = ios->timing;
>>> + priv->clock = host->clock;
>>> +
>>> + /* Legacy mode is a special case */
>>> + if (ios->timing == MMC_TIMING_LEGACY)
>>> + return 0;
>>> +
>>> + card = priv->card_candidate;
>>> + if (unlikely(!card)) {
>>> + dev_warn(mmc_dev(mmc), "card is not present\n");
>>> + return -EINVAL;
>>> + }
>>> +
>>> + if (host->clock > DEFAULT_SDCLK_FREQ)
>>> + ret = xenon_hs_delay_adj(host, card);
>>> + return ret;
>>> +}
>>> +
>>> +static int add_xenon_phy(struct device_node *np, struct sdhci_host *host,
>>> + const char *phy_name)
>>> +{
>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>> + int i, ret;
>>> +
>>> + for (i = 0; i < NR_PHY_TYPES; i++) {
>>> + if (!strcmp(phy_name, phy_types[i])) {
>>> + priv->phy_type = i;
>>> + break;
>>> + }
>>> + }
>>> + if (i == NR_PHY_TYPES) {
>>> + dev_err(mmc_dev(host->mmc),
>>> + "Unable to determine PHY name %s. Use default eMMC 5.1 PHY\n",
>>> + phy_name);
>>> + priv->phy_type = EMMC_5_1_PHY;
>>> + }
>>> +
>>> + if (priv->phy_type == SDH_PHY) {
>>> + return alloc_sdh_phy(priv);
>>> + } else if ((priv->phy_type == EMMC_5_0_PHY) ||
>>> + (priv->phy_type == EMMC_5_1_PHY)) {
>>> + ret = alloc_emmc_phy(priv);
>>> + if (ret)
>>> + return ret;
>>> + return emmc_phy_parse_param_dt(host, np, priv->phy_params);
>>> + }
>>> +
>>> + return -EINVAL;
>>> +}
>>> +
>>> +int xenon_phy_parse_dt(struct device_node *np, struct sdhci_host *host)
>>> +{
>>> + const char *phy_type = NULL;
>>> +
>>> + if (!of_property_read_string(np, "xenon,phy-type", &phy_type))
>>> + return add_xenon_phy(np, host, phy_type);
>>> +
>>> + dev_err(mmc_dev(host->mmc), "Fail to get Xenon PHY type. Use default eMMC 5.1 PHY\n");
>>> + return add_xenon_phy(np, host, "emmc 5.1 phy");
>>> +}
>>> diff --git a/drivers/mmc/host/sdhci-xenon-phy.h b/drivers/mmc/host/sdhci-xenon-phy.h
>>> new file mode 100644
>>> index 000000000000..4373c71d3b7b
>>> --- /dev/null
>>> +++ b/drivers/mmc/host/sdhci-xenon-phy.h
>>> @@ -0,0 +1,157 @@
>>> +/* linux/drivers/mmc/host/sdhci-xenon-phy.h
>>> + *
>>> + * Author: Hu Ziji <huziji@marvell.com>
>>> + * Date: 2016-8-24
>>> + *
>>> + * Copyright (C) 2016 Marvell, All Rights Reserved.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or (at
>>> + * your option) any later version.
>>> + */
>>> +#ifndef SDHCI_XENON_PHY_H_
>>> +#define SDHCI_XENON_PHY_H_
>>> +
>>> +#include <linux/types.h>
>>> +#include "sdhci.h"
>>> +
>>> +/* Register base for eMMC PHY 5.0 Version */
>>> +#define EMMC_5_0_PHY_REG_BASE 0x0160
>>> +/* Register base for eMMC PHY 5.1 Version */
>>> +#define EMMC_PHY_REG_BASE 0x0170
>>> +
>>> +#define EMMC_PHY_TIMING_ADJUST EMMC_PHY_REG_BASE
>>> +#define EMMC_5_0_PHY_TIMING_ADJUST EMMC_5_0_PHY_REG_BASE
>>> +#define TIMING_ADJUST_SLOW_MODE BIT(29)
>>> +#define TIMING_ADJUST_SDIO_MODE BIT(28)
>>> +#define OUTPUT_QSN_PHASE_SELECT BIT(17)
>>> +#define SAMPL_INV_QSP_PHASE_SELECT BIT(18)
>>> +#define SAMPL_INV_QSP_PHASE_SELECT_SHIFT 18
>>> +#define PHY_INITIALIZAION BIT(31)
>>> +#define WAIT_CYCLE_BEFORE_USING_MASK 0xF
>>> +#define WAIT_CYCLE_BEFORE_USING_SHIFT 12
>>> +#define FC_SYNC_EN_DURATION_MASK 0xF
>>> +#define FC_SYNC_EN_DURATION_SHIFT 8
>>> +#define FC_SYNC_RST_EN_DURATION_MASK 0xF
>>> +#define FC_SYNC_RST_EN_DURATION_SHIFT 4
>>> +#define FC_SYNC_RST_DURATION_MASK 0xF
>>> +#define FC_SYNC_RST_DURATION_SHIFT 0
>>> +
>>> +#define EMMC_PHY_FUNC_CONTROL (EMMC_PHY_REG_BASE + 0x4)
>>> +#define EMMC_5_0_PHY_FUNC_CONTROL (EMMC_5_0_PHY_REG_BASE + 0x4)
>>> +#define ASYNC_DDRMODE_MASK BIT(23)
>>> +#define ASYNC_DDRMODE_SHIFT 23
>>> +#define CMD_DDR_MODE BIT(16)
>>> +#define DQ_DDR_MODE_SHIFT 8
>>> +#define DQ_DDR_MODE_MASK 0xFF
>>> +#define DQ_ASYNC_MODE BIT(4)
>>> +
>>> +#define EMMC_PHY_PAD_CONTROL (EMMC_PHY_REG_BASE + 0x8)
>>> +#define EMMC_5_0_PHY_PAD_CONTROL (EMMC_5_0_PHY_REG_BASE + 0x8)
>>> +#define REC_EN_SHIFT 24
>>> +#define REC_EN_MASK 0xF
>>> +#define FC_DQ_RECEN BIT(24)
>>> +#define FC_CMD_RECEN BIT(25)
>>> +#define FC_QSP_RECEN BIT(26)
>>> +#define FC_QSN_RECEN BIT(27)
>>> +#define OEN_QSN BIT(28)
>>> +#define AUTO_RECEN_CTRL BIT(30)
>>> +#define FC_ALL_CMOS_RECEIVER 0xF000
>>> +
>>> +#define EMMC5_FC_QSP_PD BIT(18)
>>> +#define EMMC5_FC_QSP_PU BIT(22)
>>> +#define EMMC5_FC_CMD_PD BIT(17)
>>> +#define EMMC5_FC_CMD_PU BIT(21)
>>> +#define EMMC5_FC_DQ_PD BIT(16)
>>> +#define EMMC5_FC_DQ_PU BIT(20)
>>> +
>>> +#define EMMC_PHY_PAD_CONTROL1 (EMMC_PHY_REG_BASE + 0xC)
>>> +#define EMMC5_1_FC_QSP_PD BIT(9)
>>> +#define EMMC5_1_FC_QSP_PU BIT(25)
>>> +#define EMMC5_1_FC_CMD_PD BIT(8)
>>> +#define EMMC5_1_FC_CMD_PU BIT(24)
>>> +#define EMMC5_1_FC_DQ_PD 0xFF
>>> +#define EMMC5_1_FC_DQ_PU (0xFF << 16)
>>> +
>>> +#define EMMC_PHY_PAD_CONTROL2 (EMMC_PHY_REG_BASE + 0x10)
>>> +#define EMMC_5_0_PHY_PAD_CONTROL2 (EMMC_5_0_PHY_REG_BASE + 0xC)
>>> +#define ZNR_MASK 0x1F
>>> +#define ZNR_SHIFT 8
>>> +#define ZPR_MASK 0x1F
>>> +/* Perferred ZNR and ZPR value vary between different boards.
>>> + * The specific ZNR and ZPR value should be defined here
>>> + * according to board actual timing.
>>> + */
>>> +#define ZNR_DEF_VALUE 0xF
>>> +#define ZPR_DEF_VALUE 0xF
>>> +
>>> +#define EMMC_PHY_DLL_CONTROL (EMMC_PHY_REG_BASE + 0x14)
>>> +#define EMMC_5_0_PHY_DLL_CONTROL (EMMC_5_0_PHY_REG_BASE + 0x10)
>>> +#define DLL_ENABLE BIT(31)
>>> +#define DLL_UPDATE_STROBE_5_0 BIT(30)
>>> +#define DLL_REFCLK_SEL BIT(30)
>>> +#define DLL_UPDATE BIT(23)
>>> +#define DLL_PHSEL1_SHIFT 24
>>> +#define DLL_PHSEL0_SHIFT 16
>>> +#define DLL_PHASE_MASK 0x3F
>>> +#define DLL_PHASE_90_DEGREE 0x1F
>>> +#define DLL_FAST_LOCK BIT(5)
>>> +#define DLL_GAIN2X BIT(3)
>>> +#define DLL_BYPASS_EN BIT(0)
>>> +
>>> +#define EMMC_5_0_PHY_LOGIC_TIMING_ADJUST (EMMC_5_0_PHY_REG_BASE + 0x14)
>>> +#define EMMC_PHY_LOGIC_TIMING_ADJUST (EMMC_PHY_REG_BASE + 0x18)
>>> +
>>> +enum sampl_fix_delay_phase {
>>> + PHASE_0_DEGREE = 0x0,
>>> + PHASE_90_DEGREE = 0x1,
>>> + PHASE_180_DEGREE = 0x2,
>>> + PHASE_270_DEGREE = 0x3,
>>> +};
>>> +
>>> +#define SDH_PHY_SLOT_DLL_CTRL (0x0138)
>>> +#define SDH_PHY_ENABLE_DLL BIT(1)
>>> +#define SDH_PHY_FAST_LOCK_EN BIT(5)
>>> +
>>> +#define SDH_PHY_SLOT_DLL_PHASE_SEL (0x013C)
>>> +#define SDH_PHY_DLL_UPDATE_TUNING BIT(15)
>>> +
>>> +enum soc_pad_ctrl_type {
>>> + SOC_PAD_SD,
>>> + SOC_PAD_FIXED_1_8V,
>>> +};
>>> +
>>> +/*
>>> + * List offset of PHY registers and some special register values
>>> + * in eMMC PHY 5.0 or eMMC PHY 5.1
>>> + */
>>> +struct xenon_emmc_phy_regs {
>>> + /* Offset of Timing Adjust register */
>>> + u16 timing_adj;
>>> + /* Offset of Func Control register */
>>> + u16 func_ctrl;
>>> + /* Offset of Pad Control register */
>>> + u16 pad_ctrl;
>>> + /* Offset of Pad Control register */
>>> + u16 pad_ctrl2;
>>> + /* Offset of DLL Control register */
>>> + u16 dll_ctrl;
>>> + /* Offset of Logic Timing Adjust register */
>>> + u16 logic_timing_adj;
>>> + /* Max value of eMMC Fixed Sampling Delay */
>>> + u32 delay_mask;
>>> + /* DLL Update Enable bit */
>>> + u32 dll_update;
>>> +};
>>> +
>>> +struct xenon_phy_ops {
>>> + void (*strobe_delay_adj)(struct sdhci_host *host,
>>> + struct mmc_card *card);
>>> + int (*fix_sampl_delay_adj)(struct sdhci_host *host,
>>> + struct mmc_card *card);
>>> + void (*phy_set)(struct sdhci_host *host, unsigned char timing);
>>> + void (*set_soc_pad)(struct sdhci_host *host,
>>> + unsigned char signal_voltage);
>>> +};
>>> +#endif
>>> diff --git a/drivers/mmc/host/sdhci-xenon.c b/drivers/mmc/host/sdhci-xenon.c
>>> index 03ba183494d3..4d7d871544fc 100644
>>> --- a/drivers/mmc/host/sdhci-xenon.c
>>> +++ b/drivers/mmc/host/sdhci-xenon.c
>>> @@ -224,6 +224,7 @@ static void xenon_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>> spin_unlock_irqrestore(&host->lock, flags);
>>>
>>> sdhci_set_ios(mmc, ios);
>>> + xenon_phy_adj(host, ios);
>>>
>>> if (host->clock > DEFAULT_SDCLK_FREQ) {
>>> spin_lock_irqsave(&host->lock, flags);
>>> @@ -309,6 +310,8 @@ static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>> */
>>> enable_xenon_internal_clk(host);
>>>
>>> + xenon_soc_pad_ctrl(host, ios->signal_voltage);
>>> +
>>> if (priv->card_candidate) {
>>> if (mmc_card_mmc(priv->card_candidate))
>>> return xenon_emmc_signal_voltage_switch(mmc, ios);
>>> @@ -453,6 +456,7 @@ static int xenon_probe_dt(struct platform_device *pdev)
>>> sdhci_writel(host, reg, SDHC_SYS_EXT_OP_CTRL);
>>> }
>>>
>>> + err = xenon_phy_parse_dt(np, host);
>>> return err;
>>> }
>>>
>>> diff --git a/drivers/mmc/host/sdhci-xenon.h b/drivers/mmc/host/sdhci-xenon.h
>>> index c2370493fbe8..06e5261a563c 100644
>>> --- a/drivers/mmc/host/sdhci-xenon.h
>>> +++ b/drivers/mmc/host/sdhci-xenon.h
>>> @@ -15,6 +15,7 @@
>>> #include <linux/mmc/card.h>
>>> #include <linux/of.h>
>>> #include "sdhci.h"
>>> +#include "sdhci-xenon-phy.h"
>>>
>>> /* Register Offset of SD Host Controller SOCP self-defined register */
>>> #define SDHC_SYS_CFG_INFO 0x0104
>>> @@ -76,6 +77,7 @@
>>> #define MMC_TIMING_FAKE 0xFF
>>>
>>> #define DEFAULT_SDCLK_FREQ (400000)
>>> +#define LOWEST_SDCLK_FREQ (100000)
>>>
>>> /* Xenon specific Mode Select value */
>>> #define XENON_SDHCI_CTRL_HS200 0x5
>>> @@ -97,6 +99,15 @@ struct sdhci_xenon_priv {
>>> /* Slot idx */
>>> u8 slot_idx;
>>>
>>> + int phy_type;
>>> + /*
>>> + * Contains board-specific PHY parameters
>>> + * passed from device tree.
>>> + */
>>> + void *phy_params;
>>> + const struct xenon_phy_ops *phy_ops;
>>> + struct xenon_emmc_phy_regs *emmc_phy_regs;
>>> +
>>> /*
>>> * When initializing card, Xenon has to determine card type and
>>> * adjust Sampling Fixed delay.
>>> @@ -131,4 +142,10 @@ static inline int enable_xenon_internal_clk(struct sdhci_host *host)
>>>
>>> return 0;
>>> }
>>> +
>>> +int xenon_phy_adj(struct sdhci_host *host, struct mmc_ios *ios);
>>> +int xenon_phy_parse_dt(struct device_node *np,
>>> + struct sdhci_host *host);
>>> +void xenon_soc_pad_ctrl(struct sdhci_host *host,
>>> + unsigned char signal_voltage);
>>> #endif
>>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Chris Wilson @ 2016-10-09 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=GYpYKL9=uY=Fks2xO6oK3bJ772yo4EiJ1tJkVU9PheSD+Cw@mail.gmail.com>
On Sat, Oct 08, 2016 at 08:43:51PM -0700, Joel Fernandes wrote:
> On Thu, Sep 29, 2016 at 1:18 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> > On Thu, Sep 29, 2016 at 03:34:11PM +0800, Jisheng Zhang wrote:
> >> On Marvell berlin arm64 platforms, I see the preemptoff tracer report
> >> a max 26543 us latency at __purge_vmap_area_lazy, this latency is an
> >> awfully bad for STB. And the ftrace log also shows __free_vmap_area
> >> contributes most latency now. I noticed that Joel mentioned the same
> >> issue[1] on x86 platform and gave two solutions, but it seems no patch
> >> is sent out for this purpose.
> >>
> >> This patch adopts Joel's first solution, but I use 16MB per core
> >> rather than 8MB per core for the number of lazy_max_pages. After this
> >> patch, the preemptoff tracer reports a max 6455us latency, reduced to
> >> 1/4 of original result.
> >
> > My understanding is that
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 91f44e78c516..3f7c6d6969ac 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
> > static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > int sync, int force_flush)
> > {
> > - static DEFINE_SPINLOCK(purge_lock);
> > struct llist_node *valist;
> > struct vmap_area *va;
> > struct vmap_area *n_va;
> > @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > * should not expect such behaviour. This just simplifies locking for
> > * the case that isn't actually used at the moment anyway.
> > */
> > - if (!sync && !force_flush) {
> > - if (!spin_trylock(&purge_lock))
> > - return;
> > - } else
> > - spin_lock(&purge_lock);
> > -
> > if (sync)
> > purge_fragmented_blocks_allcpus();
> >
> > @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
> > __free_vmap_area(va);
> > spin_unlock(&vmap_area_lock);
> > }
> > - spin_unlock(&purge_lock);
> > }
> >
> [..]
> > should now be safe. That should significantly reduce the preempt-disabled
> > section, I think.
>
> I believe that the purge_lock is supposed to prevent concurrent purges
> from happening.
>
> For the case where if you have another concurrent overflow happen in
> alloc_vmap_area() between the spin_unlock and purge :
>
> spin_unlock(&vmap_area_lock);
> if (!purged)
> purge_vmap_area_lazy();
>
> Then the 2 purges would happen at the same time and could subtract
> vmap_lazy_nr twice.
That itself is not the problem, as each instance of
__purge_vmap_area_lazy() operates on its own freelist, and so there will
be no double accounting.
However, removing the lock removes the serialisation which does mean
that alloc_vmap_area() will not block on another thread conducting the
purge, and so it will try to reallocate before that is complete and the
free area made available. It also means that we are doing the
atomic_sub(vmap_lazy_nr) too early.
That supports making the outer lock a mutex as you suggested. But I think
cond_resched_lock() is better for the vmap_area_lock (just because it
turns out to be an expensive loop and we may want the reschedule).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox