* Re: [PATCH v9 2/3] fdt: add support for rng-seed
From: Theodore Y. Ts'o @ 2019-08-29 15:45 UTC (permalink / raw)
To: Hsin-Yi Wang
Cc: Kate Stewart, Peter Zijlstra, Catalin Marinas, Mukesh Ojha,
Grzegorz Halat, H . Peter Anvin, Guenter Roeck, Will Deacon,
Marek Szyprowski, Rob Herring, Daniel Thompson, Anders Roxell,
Yury Norov, Marc Zyngier, Russell King, Aaro Koskinen,
Ingo Molnar, Viresh Kumar, Waiman Long, Paul E . McKenney, Wei Li,
Alexey Dobriyan, Julien Thierry, Len Brown, Kees Cook,
Arnd Bergmann, Rik van Riel, Stephen Boyd, Shaokun Zhang,
Mike Rapoport, Borislav Petkov, Josh Poimboeuf, Thomas Gleixner,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Greg Kroah-Hartman, Marcelo Tosatti, lkml, Armijn Hemel,
Jiri Kosina, Mathieu Desnoyers, Andrew Morton, Tim Chen,
David S . Miller
In-Reply-To: <CAJMQK-iDoPxbFUH3JUeJ7SehCptZOnjKZiUoFd1PqLjDdGHujA@mail.gmail.com>
On Thu, Aug 29, 2019 at 06:03:57PM +0800, Hsin-Yi Wang wrote:
> On Thu, Aug 29, 2019 at 1:36 AM Kees Cook <keescook@chromium.org> wrote:
> >
> > Can this please be a boot param (with the default controlled by the
> > CONFIG)? See how CONFIG_RANDOM_TRUST_CPU is wired up...
> >
>
> Currently rng-seed read and added in setup_arch() -->
> setup_machine_fdt().. -> early_init_dt_scan_chosen(), which is earlier
> than parse_early_param() that initializes early_param.
>
> If we want to set it as a boot param, add_bootloader_randomness() can
> only be called after parse_early_param(). The seed can't be directly
> added to pool after it's read in. We need to store into global
> variable and load it later.
> If this seems okay then I'll add a patch for this. Thanks
I thought about asking for this, but we really want to do this as
early as possible, so that it can be used by KASLR and other services
that are run super early. Also, whether or not we can trust the
bootloader is going to be a system-level thing. This should probably
be defaulted to off, and only enabled by the system integrator if they
are 100%, positively sure, that the entire system is one where we can
trust the source of randomness which the bootloader is using --- or
for that matter, that the bootloader is trustworthy!
Is it really going to be that useful for a random system administrator
to be able to flip this on or off from the command line? Hopefully
there will be an easy way to configure the firmware or the bootloader
to simply not supply entropy, if for some reason it's not trustworthy.
- Ted
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] Documentation: add link to stm32mp157 docs
From: Jonathan Corbet @ 2019-08-29 15:44 UTC (permalink / raw)
To: Alexandre Torgue
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
mcoquelin.stm32@gmail.com, Gerald BAEZA,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5257eff7-418b-8e94-1ced-30718dd3f5dc@st.com>
On Tue, 27 Aug 2019 17:23:30 +0200
Alexandre Torgue <alexandre.torgue@st.com> wrote:
> >> +Datasheet and reference manual are publicly available on ST website:
> >> +.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
> >> +
> >
> > Adding the URL is a fine idea. But you don't need the extra syntax to
> > create a link if you're not going to actually make a link out of it. So
> > I'd take the ".. _STM32MP157:" part out and life will be good.
> >
>
> We also did it for older stm32 product. Idea was to not have the "full"
> address but just a shortcut of the link when html file is read. It maybe
> makes no sens ? (if yes we will have to update older stm32 overview :))
Did you actually run it through Sphinx to see what you get? If I
understand the effect you're after, you want something like this:
The datasheet and reference manual are publicly available on
STM32MP157_.
.. _STM32MP157: https://www.st.com/en/microcontrollers-microprocessors/stm32mp157.html
IOW you have to actually *use* the label you are setting up. That's a fine
way to do it, I guess, though I'm not really convinced it's better than
just putting the URL in directly.
Thanks,
jon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: remove default fallbacks in dma_map_ops v3
From: Christoph Hellwig @ 2019-08-29 15:38 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, Vladimir Murzin, linux-parisc,
linux-sh, Takashi Iwai, Robin Murphy, Helge Deller, x86,
linux-kernel, linux-m68k, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190808160005.10325-1-hch@lst.de>
I've applied this to the dma-mapping for-next tree now.
If there are any issues with the parisc patch I'll happily take
incremental patches.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 05/11] kselftest: arm64: mangle_pstate_ssbs_regs
From: Cristian Marussi @ 2019-08-29 15:35 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-arm-kernel, linux-kselftest
In-Reply-To: <20190813162509.GC10425@arm.com>
Hi
On 13/08/2019 17:25, Dave Martin wrote:
> On Fri, Aug 02, 2019 at 06:02:54PM +0100, Cristian Marussi wrote:
>> Added a simple mangle testcase which messes with the ucontext_t
>
> Add
>
>> from within the sig_handler, trying to toggle PSTATE SSBS bit.
>
> signal handler
>
Ok.
>> Expect SIGILL if SSBS feature unsupported or that the value set in
>> PSTATE.SSBS is preserved on test PASS.
>
> The test doesn't set PSTATE.SSBS directly.
>
> Maybe something like: "Expect SIGILL if the SSBS feature is unsupported.
> Otherwise, expect sigreturn to set PSTATE.SSBS from the corresponding
> bit in pstate in the signal frame."
>
Ok
>> This commit also introduces a new common utility function:
>> get_current_context() which can be used to grab a ucontext without
>> the help of libc, and detect if such ucontext has been actively used
>> to jump back into it.
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> .../selftests/arm64/signal/test_signals.h | 4 +
>> .../arm64/signal/test_signals_utils.c | 93 +++++++++++++++++++
>> .../arm64/signal/test_signals_utils.h | 2 +
>> .../arm64/signal/testcases/.gitignore | 1 +
>> .../testcases/mangle_pstate_ssbs_regs.c | 56 +++++++++++
>> 5 files changed, 156 insertions(+)
>> create mode 100644 tools/testing/selftests/arm64/signal/testcases/mangle_pstate_ssbs_regs.c
>>
>> diff --git a/tools/testing/selftests/arm64/signal/test_signals.h b/tools/testing/selftests/arm64/signal/test_signals.h
>> index 85db3ac44b32..37bed0590226 100644
>> --- a/tools/testing/selftests/arm64/signal/test_signals.h
>> +++ b/tools/testing/selftests/arm64/signal/test_signals.h
>> @@ -116,6 +116,10 @@ struct tdescr {
>> /* optional sa_flags for the installed handler */
>> int sa_flags;
>> ucontext_t saved_uc;
>> + /* used by get_current_ctx() */
>> + size_t live_sz;
>> + ucontext_t *live_uc;
>> + volatile bool live_uc_valid;
>>
>> /* a setup function to be called before test starts */
>> int (*setup)(struct tdescr *td);
>> diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.c b/tools/testing/selftests/arm64/signal/test_signals_utils.c
>> index ac0055f6340b..faf55ba99d58 100644
>> --- a/tools/testing/selftests/arm64/signal/test_signals_utils.c
>> +++ b/tools/testing/selftests/arm64/signal/test_signals_utils.c
>> @@ -11,12 +11,16 @@
>> #include <linux/auxvec.h>
>> #include <ucontext.h>
>>
>> +#include <asm/unistd.h>
>> +
>> #include "test_signals.h"
>> #include "test_signals_utils.h"
>> #include "testcases/testcases.h"
>>
>> extern struct tdescr *current;
>>
>> +static int sig_copyctx = SIGUSR2;
>> +
>> static char *feats_store[FMAX_END] = {
>> "SSBS",
>> "PAN",
>> @@ -37,6 +41,85 @@ static inline char *feats_to_string(unsigned long feats)
>> return feats_string;
>> }
>>
>> +/*
>> + * Obtaining a valid and full-blown ucontext_t from userspace is tricky:
>> + * libc getcontext does() not save all the regs and messes with some of
>> + * them (pstate value in particular is not reliable).
>> + * Here we use a service signal to grab the ucontext_t from inside a
>> + * dedicated signal handler, since there, it is populated by Kernel
>> + * itself in setup_sigframe(). The grabbed context is then stored and
>> + * made available in td->live_uc.
>> + *
>> + * Anyway this function really serves a dual purpose:
>> + *
>> + * 1. grab a valid sigcontext into td->live_uc for result analysis: in
>> + * such case it returns 1.
>> + *
>> + * 2. detect if somehow a previously grabbed live_uc context has been
>> + * used actively with a sigreturn: in such a case the execution would have
>> + * magically resumed in the middle of the function itself (seen_already==1):
>> + * in such a case return 0, since in fact we have not just simply grabbed
>> + * the context.
>> + *
>> + * This latter case is useful to detect when a fake_sigreturn test-case has
>> + * unexpectedly survived without hittig a SEGV.
>> + */
>> +bool get_current_context(struct tdescr *td, ucontext_t *dest_uc)
>> +{
>> + static volatile sig_atomic_t seen_already;
>> +
>> + if (!td || !dest_uc) {
>> + fprintf(stdout, "Signal-based Context dumping NOT available\n");
>
> Should this ever happen inless there is a test bug?
>
> Maybe this should just be an assert.
Yes definitely better.
>
>> + return 0;
>> + }
>> +
>> + /* it's a genuine invokation..reinit */
>> + seen_already = 0;
>> + td->live_uc_valid = 0;
>> + td->live_sz = sizeof(*dest_uc);
>> + memset(dest_uc, 0x00, td->live_sz);
>
> Eventually we will need to examine the signal frame to determine its
> size, but for now this is fine.
>
> It will start to matter for SVE.
Yes this function has been reworked in the SVE signal frame patches to
dynamically detect runtime signal frame and be able to optionally grab
a sigframe containing SVE material (avoiding the kill() syscall to trigger
a signal in favour of a brk instruction to cause a SIGTRAP without passing
via the syscall machinery which would zero the SVE sigframe stuff)
Such patch, which depends on this series, is still not published.
>
>> + td->live_uc = dest_uc;
>> + /*
>> + * Grab ucontext_t triggering a signal...
>> + * ASM equivalent of raise(sig_copyctx);
>> + *
>> + * Note that:
>> + * - live_uc_valid is declared volatile in struct tdescr
>> + * since it will be changed inside the sig_copyctx handler.
>> + * - the kill() syscall invocation returns only after any possible
>> + * registered sig_handler for the invoked signal has returned,
>
> sig_handler looks like the name of some function of variable, but I
> can't find it. Did I miss something?
No I'll replace the comment with "signal handler"
>
>> + * so that live_uc_valid flag is surely up to date when this
>> + * function return it.
>> + * - the additional 'memory' clobber is there to avoid possible
>> + * compiler's assumption on the content pointed by dest_uc, which
>> + * is changed inside the handler, but not referenced here anyway.
>> + */
>> + asm volatile ("mov x8, %0\n\t"
>> + "svc #0\n\t"
>> + "mov x1, %1\n\t"
>> + "mov x8, %2\n\t"
>> + "svc #0"
>> + :
>> + : "i" (__NR_getpid),
>> + "r" (sig_copyctx),
>> + "i" (__NR_kill)
>> + : "x1","x8","x0","memory");
>> + /*
>> + * If we get here with seen_already==1 it implies the td->live_uc
>> + * context has been used to get back here....this probably means
>> + * a test has failed to cause a SEGV...anyway the live_uc has not
>> + * just been acquired...so return 0
>> + */
>> + if (seen_already) {
>> + fprintf(stdout,
>> + "Successful sigreturn detected: live_uc is stale !\n");
>> + return 0;
>> + }
>> + seen_already = 1;
>> +
>> + return td->live_uc_valid;
>> +}
>> +
>> static void unblock_signal(int signum)
>> {
>> sigset_t sset;
>> @@ -112,6 +195,12 @@ static void default_handler(int signum, siginfo_t *si, void *uc)
>> * to terminate immediately exiting straight away
>> */
>> default_result(current, 1);
>> + } else if (signum == sig_copyctx && current->live_uc) {
>> + memcpy(current->live_uc, uc, current->live_sz);
>> + ASSERT_GOOD_CONTEXT(current->live_uc);
>> + current->live_uc_valid = 1;
>> + fprintf(stderr,
>> + "GOOD CONTEXT grabbed from sig_copyctx handler\n");
>> } else {
>> if (signum == current->sig_unsupp && !are_feats_ok(current)) {
>> fprintf(stderr, "-- RX SIG_UNSUPP on unsupported feature...OK\n");
>> @@ -214,6 +303,10 @@ static int test_init(struct tdescr *td)
>> !feats_ok ? "NOT " : "");
>> }
>>
>> + if (td->sig_trig == sig_copyctx)
>> + sig_copyctx = SIGUSR1;
>
> What's this for? What if we have the same signal for sig_trig and
> sig_copyctx?
>
To avoid that a user defined sig_trig equal to sig_copyctx can fool this function.
In SVE signal frame patch (not in this series), I'll anyway switch to use a distinct
SIGTRAP sig_trig.
>> + unblock_signal(sig_copyctx);
>> +
>> td->initialized = 1;
>> return 1;
>> }
>> diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.h b/tools/testing/selftests/arm64/signal/test_signals_utils.h
>> index 8658d1a7d4b9..ce35be8ebc8e 100644
>> --- a/tools/testing/selftests/arm64/signal/test_signals_utils.h
>> +++ b/tools/testing/selftests/arm64/signal/test_signals_utils.h
>> @@ -10,4 +10,6 @@ int test_setup(struct tdescr *td);
>> void test_cleanup(struct tdescr *td);
>> int test_run(struct tdescr *td);
>> void test_result(struct tdescr *td);
>> +
>> +bool get_current_context(struct tdescr *td, ucontext_t *dest_uc);
>> #endif
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/.gitignore b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> index 226bb179b673..a48a118b1a1a 100644
>> --- a/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> +++ b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> @@ -3,3 +3,4 @@ mangle_pstate_invalid_daif_bits
>> mangle_pstate_invalid_mode_el1
>> mangle_pstate_invalid_mode_el2
>> mangle_pstate_invalid_mode_el3
>> +mangle_pstate_ssbs_regs
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/mangle_pstate_ssbs_regs.c b/tools/testing/selftests/arm64/signal/testcases/mangle_pstate_ssbs_regs.c
>> new file mode 100644
>> index 000000000000..a399d9aa40d5
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/signal/testcases/mangle_pstate_ssbs_regs.c
>> @@ -0,0 +1,56 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (C) 2019 ARM Limited */
>> +
>> +#include <stdio.h>
>> +#include <ucontext.h>
>> +
>> +#include "test_signals_utils.h"
>> +#include "testcases.h"
>> +
>> +static int mangle_invalid_pstate_ssbs_run(struct tdescr *td,
>> + siginfo_t *si, ucontext_t *uc)
>> +{
>> + ASSERT_GOOD_CONTEXT(uc);
>> +
>> + /* set bit value */
>
> Should we clear SSBS in the test setup (using MSR), to make sure that
> sigreturn really succeeds in _changing_ the bit to 1?
>
Yes. I introduced a set_regval() asm helper and added a new .init signal-test
framework entry in tdescr to be able to call per-test specific initialization.
I took the chance also to remove the remaining volatile qualifiers from signal
handling code to please checkpatch, and add a dsb barrier to ensure the writes
by the signal handler.
>> + uc->uc_mcontext.pstate |= PSR_SSBS_BIT;
>> + fprintf(stderr, "SSBS set to 1 -- PSTATE: 0x%016lX\n",
>> + uc->uc_mcontext.pstate);
>> + /* Save after mangling...it should be preserved */
>> + td->saved_uc = *uc;
>> +
>> + return 1;
>> +}
>
> [...]
>
> Cheers
> ---Dave
>
Cheers
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Allwinner Fixes for 5.3
From: Arnd Bergmann @ 2019-08-29 15:30 UTC (permalink / raw)
To: Maxime Ripard; +Cc: SoC Team, arm-soc, Chen-Yu Tsai, Linux ARM
In-Reply-To: <8c04a96b-4a75-4e1f-b3ac-05fe091f251e.lettre@localhost>
On Thu, Aug 22, 2019 at 11:27 AM Maxime Ripard <mripard@kernel.org> wrote:
> for you to fetch changes up to e32db73c5aca895a43061cf6621076aa798530e3:
>
> MAINTAINERS: Update my email address (2019-07-23 11:24:12 +0200)
Pulled into arm/fixes, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: cleanup the dma_pgprot handling v2
From: Christoph Hellwig @ 2019-08-29 15:28 UTC (permalink / raw)
To: iommu
Cc: Shawn Anastasio, Will Deacon, linuxppc-dev, linux-kernel,
linux-m68k, Geert Uytterhoeven, Paul Burton, Catalin Marinas,
James Hogan, Russell King, linux-mips, Guan Xuetao,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190826132553.4116-1-hch@lst.de>
I've pulled this into the dma-mapping for-next tree now.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Hisilicon fixes for v5.3
From: Arnd Bergmann @ 2019-08-29 15:25 UTC (permalink / raw)
To: Wei Xu
Cc: Tangkunshan, linux-pci, Linuxarm, # 3.4.x, xuwei (O), Sasha Levin,
arm@kernel.org, huangdaode, Zhangyi ac, jinying, John Garry,
SoC Team, Jonathan Cameron, Bjorn Helgaas,
linux-arm-kernel@lists.infradead.org, Salil Mehta,
Rafael J. Wysocki, Linux Kernel Mailing List,
Shameerali Kolothum Thodi, Olof Johansson, Liguozhu (Kenneth),
Shiju Jose
In-Reply-To: <5D562335.7000902@hisilicon.com>
On Fri, Aug 16, 2019 at 5:30 AM Wei Xu <xuwei5@hisilicon.com> wrote:
>
> Hi ARM-SoC team,
>
> Please consider to pull the following fixes.
> Thanks!
>
Pulled into arm/fixes, thanks!
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/7] lib: vdso: Remove VDSO_HAS_32BIT_FALLBACK
From: Andy Lutomirski @ 2019-08-29 15:25 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, Catalin Marinas, Dmitry Safonov, LKML, linux-mips,
Paul Burton, Andrew Lutomirski, Thomas Gleixner, Mark Salyzyn,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190829111843.41003-5-vincenzo.frascino@arm.com>
On Thu, Aug 29, 2019 at 4:19 AM Vincenzo Frascino
<vincenzo.frascino@arm.com> wrote:
>
> VDSO_HAS_32BIT_FALLBACK was introduced to address a regression which
> caused seccomp to deny access to the applications to clock_gettime64()
> and clock_getres64() because they are not enabled in the existing
> filters.
>
> The purpose of VDSO_HAS_32BIT_FALLBACK was to simplify the conditional
> implementation of __cvdso_clock_get*time32() variants.
>
> Now that all the architectures that support the generic vDSO library
> have been converted to support the 32 bit fallbacks the conditional
> can be removed.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> CC: Andy Lutomirski <luto@kernel.org>
> References: c60a32ea4f45 ("lib/vdso/32: Provide legacy syscall fallbacks")
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> ---
> lib/vdso/gettimeofday.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c
> index a86e89e6dedc..2c4b311c226d 100644
> --- a/lib/vdso/gettimeofday.c
> +++ b/lib/vdso/gettimeofday.c
> @@ -126,13 +126,8 @@ __cvdso_clock_gettime32(clockid_t clock, struct old_timespec32 *res)
>
> ret = __cvdso_clock_gettime_common(clock, &ts);
>
> -#ifdef VDSO_HAS_32BIT_FALLBACK
> if (unlikely(ret))
> return clock_gettime32_fallback(clock, res);
> -#else
> - if (unlikely(ret))
> - ret = clock_gettime_fallback(clock, &ts);
> -#endif
>
> if (likely(!ret)) {
> res->tv_sec = ts.tv_sec;
I think you could have a little follow-up patch to remove the if
statement -- by the time you get here, it's guaranteed that ret == 0.
--Andy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/10] KVM: arm64: Document PV-time interface
From: Steven Price @ 2019-08-29 15:21 UTC (permalink / raw)
To: Christoffer Dall
Cc: kvm, linux-doc, Marc Zyngier, Russell King, linux-kernel,
Catalin Marinas, Paolo Bonzini, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <20190828134900.GA2113@lvm>
On 28/08/2019 14:49, Christoffer Dall wrote:
> On Tue, Aug 27, 2019 at 10:57:06AM +0200, Christoffer Dall wrote:
>> On Wed, Aug 21, 2019 at 04:36:47PM +0100, Steven Price wrote:
>>> Introduce a paravirtualization interface for KVM/arm64 based on the
>>> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
>>>
>>> This only adds the details about "Stolen Time" as the details of "Live
>>> Physical Time" have not been fully agreed.
>>>
>>> User space can specify a reserved area of memory for the guest and
>>> inform KVM to populate the memory with information on time that the host
>>> kernel has stolen from the guest.
>>>
>>> A hypercall interface is provided for the guest to interrogate the
>>> hypervisor's support for this interface and the location of the shared
>>> memory structures.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> Documentation/virt/kvm/arm/pvtime.txt | 100 ++++++++++++++++++++++++++
>>> 1 file changed, 100 insertions(+)
>>> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
>>>
>>> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
>>> new file mode 100644
>>> index 000000000000..1ceb118694e7
>>> --- /dev/null
>>> +++ b/Documentation/virt/kvm/arm/pvtime.txt
>>> @@ -0,0 +1,100 @@
>>> +Paravirtualized time support for arm64
>>> +======================================
>>> +
>>> +Arm specification DEN0057/A defined a standard for paravirtualised time
>>> +support for AArch64 guests:
>>> +
>>> +https://developer.arm.com/docs/den0057/a
>>> +
>>> +KVM/arm64 implements the stolen time part of this specification by providing
>>> +some hypervisor service calls to support a paravirtualized guest obtaining a
>>> +view of the amount of time stolen from its execution.
>>> +
>>> +Two new SMCCC compatible hypercalls are defined:
>>> +
>>> +PV_FEATURES 0xC5000020
>>> +PV_TIME_ST 0xC5000022
>>> +
>>> +These are only available in the SMC64/HVC64 calling convention as
>>> +paravirtualized time is not available to 32 bit Arm guests. The existence of
>>> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
>>> +mechanism before calling it.
>>> +
>>> +PV_FEATURES
>>> + Function ID: (uint32) : 0xC5000020
>>> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
>>> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
>>> + PV-time feature is supported by the hypervisor.
>>> +
>>> +PV_TIME_ST
>>> + Function ID: (uint32) : 0xC5000022
>>> + Return value: (int64) : IPA of the stolen time data structure for this
>>> + (V)CPU. On failure:
>>> + NOT_SUPPORTED (-1)
>>> +
>>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
>>> +with inner and outer write back caching attributes, in the inner shareable
>>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
>>> +meaningfully filled by the hypervisor (see structure below).
>>> +
>>> +PV_TIME_ST returns the structure for the calling VCPU.
>>> +
>>> +Stolen Time
>>> +-----------
>>> +
>>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
>>> +
>>> + Field | Byte Length | Byte Offset | Description
>>> + ----------- | ----------- | ----------- | --------------------------
>>> + Revision | 4 | 0 | Must be 0 for version 0.1
>>> + Attributes | 4 | 4 | Must be 0
>>> + Stolen time | 8 | 8 | Stolen time in unsigned
>>> + | | | nanoseconds indicating how
>>> + | | | much time this VCPU thread
>>> + | | | was involuntarily not
>>> + | | | running on a physical CPU.
>>> +
>>> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
>>> +will be present within a reserved region of the normal memory given to the
>>> +guest. The guest should not attempt to write into this memory. There is a
>>> +structure per VCPU of the guest.
>>> +
>>> +User space interface
>>> +====================
>>> +
>>> +User space can request that KVM provide the paravirtualized time interface to
>>> +a guest by creating a KVM_DEV_TYPE_ARM_PV_TIME device, for example:
>>> +
>>> + struct kvm_create_device pvtime_device = {
>>> + .type = KVM_DEV_TYPE_ARM_PV_TIME,
>>> + .attr = 0,
>>> + .flags = 0,
>>> + };
>>> +
>>> + pvtime_fd = ioctl(vm_fd, KVM_CREATE_DEVICE, &pvtime_device);
>>> +
>>> +Creation of the device should be done after creating the vCPUs of the virtual
>>> +machine.
>>> +
>>> +The IPA of the structures must be given to KVM. This is the base address
>>> +of an array of stolen time structures (one for each VCPU). The base address
>>> +must be page aligned. The size must be at least 64 * number of VCPUs and be a
>>> +multiple of PAGE_SIZE.
>>> +
>>> +The memory for these structures should be added to the guest in the usual
>>> +manner (e.g. using KVM_SET_USER_MEMORY_REGION).
>>> +
>>> +For example:
>>> +
>>> + struct kvm_dev_arm_st_region region = {
>>> + .gpa = <IPA of guest base address>,
>>> + .size = <size in bytes>
>>> + };
>>
>> This feel fragile; how are you handling userspace creating VCPUs after
>> setting this up, the GPA overlapping guest memory, etc. Is the
>> philosophy here that the VMM can mess up the VM if it wants, but that
>> this should never lead attacks on the host (we better hope not) and so
>> we don't care?
>>
>> It seems to me setting the IPA per vcpu throught the VCPU device would
>> avoid a lot of these issues. See
>> Documentation/virt/kvm/devices/vcpu.txt.
>>
>>
> I discussed this with Marc the other day, and we realized that if we
> make the configuration of the IPA per-PE, then a VMM can construct a VM
> where these data structures are distributed within the IPA space of a
> VM, which could lead to a lower TLB pressure for some
> configurations/workloads.
Ok, I'm dubious it will make much difference in terms of TLB pressure,
but I've done the refactoring and I think it actually simplifies the
code. So I'll post a new version where the base address is set via the
VCPU device.
Thanks for the review,
Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/7] lib: vdso: Build 32 bit specific functions in the right context
From: Andy Lutomirski @ 2019-08-29 15:23 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, Catalin Marinas, Dmitry Safonov, LKML, linux-mips,
Paul Burton, Andrew Lutomirski, Thomas Gleixner, Mark Salyzyn,
Will Deacon, linux-arm-kernel
In-Reply-To: <20190829111843.41003-3-vincenzo.frascino@arm.com>
On Thu, Aug 29, 2019 at 4:19 AM Vincenzo Frascino
<vincenzo.frascino@arm.com> wrote:
>
> clock_gettime32 and clock_getres_time32 should be compiled only with a
> 32 bit vdso library.
>
> Exclude these symbols when BUILD_VDSO32 is not defined.
Reviewed-by: Andy Lutomirski <luto@kernel.org>
BTW, this is a great patch: it's either correct or it won't build. I
like patches like that.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3 2/6] dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
From: Vidya Sagar @ 2019-08-29 15:18 UTC (permalink / raw)
To: Thierry Reding
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, kishon, linux-tegra, robh+dt,
linux-pci, bhelgaas, andrew.murray, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190829120329.GC13187@ulmo>
On 8/29/2019 5:33 PM, Thierry Reding wrote:
> On Wed, Aug 28, 2019 at 10:58:46PM +0530, Vidya Sagar wrote:
>> Add optional bindings "vpcie3v3-supply" and "vpcie12v-supply" to describe
>> regulators of a PCIe slot's supplies 3.3V and 12V provided the platform
>> is designed to have regulator controlled slot supplies.
>>
>> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
>> ---
>> V3:
>> * None
>>
>> V2:
>> * None
>>
>> .../devicetree/bindings/pci/nvidia,tegra194-pcie.txt | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
>> index 0ac1b867ac24..b739f92da58e 100644
>> --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
>> @@ -104,6 +104,12 @@ Optional properties:
>> specified in microseconds
>> - nvidia,aspm-l0s-entrance-latency-us: ASPM L0s entrance latency to be
>> specified in microseconds
>> +- vpcie3v3-supply: A phandle to the regulator node that supplies 3.3V to the slot
>> + if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
>> + in p2972-0000 platform).
>> +- vpcie12v-supply: A phandle to the regulator node that supplies 12V to the slot
>> + if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
>> + in p2972-0000 platform).
>
> There's an ongoing discussion regarding the use of optional power
> supplies and I'm wondering if we're not abusing this here. Why exactly
> are these regulators optional?
I made them optional because, the number and type of supplies typically depend on the
kind of slot the controller is owning. If it is a CEM slot, then, it needs 3.3V & 12V
supplies and if it is an M.2 Key-E/M slot, it needs only 3.3V supply. Also, if there are
on-board PCIe endpoint devices, supplies may vary again from vendor to vendor.
Considering all these, I made them optional instead of mandatory.
Also, I agree that regulator framework supplies a dummy regulator if we make them mandatory
but doesn't supply one, but it does so with a warning print in the log which I feel is
an unwanted alert and to avoid that one has to supply dummy/fixed regulators which again
seems an overkill when all of this can be addressed by making slot regulators optional.
>
> The distinction is somewhat subtle, but the other way to look at
> modelling this in DT is that the supplies are in fact required, but may
> be connected to an always-on regulator with a fixed voltage. Or in some
> cases they may also be shorted to ground. In both cases the PCI
> controller, or rather the slot that the controller connects to, actually
> "requires" the supplies, it's just that we can get away without
> describing them because they can't be controlled anyway.
>
> Looking at the PCI connector pinout for PCI Express, I do see a bunch of
> +3.3 V and +12 V pins. To me that indicates that the 3.3 V and 12 V
> supplies are indeed required for PCI slots. I'm not sure about devices
> that are directly connected to the PCI controller, though. I'll need to
> go look at some schematics to get a better understanding of these.
>
> Bottom line: I'm wondering if we shouldn't really make these supplies
> mandatory and in case where we don't care either just leave them away
> (the regulator framework will supply a dummy regulator in that case) or
> hook them up to a fixed regulator if that matches the hardware design.
>
> Any thoughts?
>
> Thierry
>
>>
>> Examples:
>> =========
>> @@ -156,6 +162,8 @@ Tegra194:
>> 0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory (16GB) */
>>
>> vddio-pex-ctl-supply = <&vdd_1v8ao>;
>> + vpcie3v3-supply = <&vdd_3v3_pcie>;
>> + vpcie12v-supply = <&vdd_12v_pcie>;
>>
>> phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>,
>> <&p2u_hsio_5>;
>> --
>> 2.17.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5, 32/32] drm/mediatek: add support for mediatek SOC MT8183
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add support for mediatek SOC MT8183
1.ovl_2l share driver with ovl
2.rdma1 share drive with rdma0, but fifo size is different
3.add mt8183 mutex private data, and mmsys private data
4.add mt8183 main and external path module for crtc create
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +++++++++
drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 27 ++++++++++++-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 69 ++++++++++++++++++++++++++++++++
drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 ++++++++++++++++++++++
5 files changed, 161 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 53f3883..94c80c2 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -373,11 +373,29 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
.fmt_rgb565_is_0 = true,
};
+static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 4,
+ .fmt_rgb565_is_0 = true,
+};
+
+static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
+ .addr = DISP_REG_OVL_ADDR_MT8173,
+ .gmc_bits = 10,
+ .layer_nr = 2,
+ .fmt_rgb565_is_0 = true,
+};
+
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-ovl",
.data = &mt2701_ovl_driver_data},
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = &mt8173_ovl_driver_data},
+ { .compatible = "mediatek,mt8183-disp-ovl",
+ .data = &mt8183_ovl_driver_data},
+ { .compatible = "mediatek,mt8183-disp-ovl-2l",
+ .data = &mt8183_ovl_2l_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
index 9a6f0a2..24945fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
@@ -62,6 +62,7 @@ struct mtk_disp_rdma {
struct mtk_ddp_comp ddp_comp;
struct drm_crtc *crtc;
const struct mtk_disp_rdma_data *data;
+ u32 fifo_size;
};
static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
@@ -130,10 +131,16 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
unsigned int threshold;
unsigned int reg;
struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
+ u32 rdma_fifo_size;
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xfffff, height);
+ if (rdma->fifo_size)
+ rdma_fifo_size = rdma->fifo_size;
+ else
+ rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
+
/*
* Enable FIFO underflow since DSI and DPI can't be blocked.
* Keep the FIFO pseudo size reset default of 8 KiB. Set the
@@ -142,7 +149,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
*/
threshold = width * height * vrefresh * 4 * 7 / 1000000;
reg = RDMA_FIFO_UNDERFLOW_EN |
- RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
+ RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
}
@@ -284,6 +291,18 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
return comp_id;
}
+ if (of_find_property(dev->of_node, "mediatek,rdma_fifo_size", &ret)) {
+ ret = of_property_read_u32(dev->of_node,
+ "mediatek,rdma_fifo_size",
+ &priv->fifo_size);
+ if (ret) {
+ dev_err(dev, "Failed to get rdma fifo size\n");
+ return ret;
+ }
+
+ priv->fifo_size *= SZ_1K;
+ }
+
ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
&mtk_disp_rdma_funcs);
if (ret) {
@@ -328,11 +347,17 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
.fifo_size = SZ_8K,
};
+static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
+ .fifo_size = 5 * SZ_1K,
+};
+
static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = &mt2701_rdma_driver_data},
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = &mt8173_rdma_driver_data},
+ { .compatible = "mediatek,mt8183-disp-rdma",
+ .data = &mt8183_rdma_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 6a7cb15..9be6eae 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -33,19 +33,31 @@
#define DISP_REG_CONFIG_DSI_SEL 0x050
#define DISP_REG_CONFIG_DPI_SEL 0x064
+#define MT8183_DISP_OVL0_MOUT_EN 0xf00
#define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
#define MT8183_DISP_OVL1_2L_MOUT_EN 0xf08
#define MT8183_DISP_DITHER0_MOUT_EN 0xf0c
#define MT8183_DISP_PATH0_SEL_IN 0xf24
+#define MT8183_DISP_DSI0_SEL_IN 0xf2c
+#define MT8183_DISP_DPI0_SEL_IN 0xf30
+#define MT8183_DISP_RDMA0_SOUT_SEL_IN 0xf50
+#define MT8183_DISP_RDMA1_SOUT_SEL_IN 0xf54
#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
#define DITHER0_MOUT_IN_DSI0 BIT(0)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
#define DSI0_SEL_IN_RDMA0 0x1
+#define MT8183_DSI0_SEL_IN_RDMA1 0x3
+#define MT8183_DPI0_SEL_IN_RDMA0 0x1
+#define MT8183_DPI0_SEL_IN_RDMA1 0x2
+#define MT8183_RDMA0_SOUT_COLOR0 0x1
+#define MT8183_RDMA1_SOUT_DSI0 0x1
#define MT2701_DISP_MUTEX0_MOD0 0x2c
#define MT2701_DISP_MUTEX0_SOF0 0x30
+#define MT8183_DISP_MUTEX0_MOD0 0x30
+#define MT8183_DISP_MUTEX0_SOF0 0x2c
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
@@ -56,6 +68,18 @@
#define INT_MUTEX BIT(1)
+#define MT8183_MUTEX_MOD_DISP_RDMA0 0
+#define MT8183_MUTEX_MOD_DISP_RDMA1 1
+#define MT8183_MUTEX_MOD_DISP_OVL0 9
+#define MT8183_MUTEX_MOD_DISP_OVL0_2L 10
+#define MT8183_MUTEX_MOD_DISP_OVL1_2L 11
+#define MT8183_MUTEX_MOD_DISP_WDMA0 12
+#define MT8183_MUTEX_MOD_DISP_COLOR0 13
+#define MT8183_MUTEX_MOD_DISP_CCORR0 14
+#define MT8183_MUTEX_MOD_DISP_AAL0 15
+#define MT8183_MUTEX_MOD_DISP_GAMMA0 16
+#define MT8183_MUTEX_MOD_DISP_DITHER0 17
+
#define MT8173_MUTEX_MOD_DISP_OVL0 11
#define MT8173_MUTEX_MOD_DISP_OVL1 12
#define MT8173_MUTEX_MOD_DISP_RDMA0 13
@@ -105,6 +129,10 @@
#define MUTEX_SOF_DSI2 5
#define MUTEX_SOF_DSI3 6
+#define MT8183_MUTEX_SOF_DPI0 2
+#define MT8183_MUTEX_EOF_DSI0 (MUTEX_SOF_DSI0 << 6)
+#define MT8183_MUTEX_EOF_DPI0 (MT8183_MUTEX_SOF_DPI0 << 6)
+
#define OVL0_MOUT_EN_COLOR0 0x1
#define OD_MOUT_EN_RDMA0 0x1
#define OD1_MOUT_EN_RDMA1 BIT(16)
@@ -240,6 +268,20 @@ struct mtk_mmsys_reg_data {
[DDP_COMPONENT_WDMA1] = MT8173_MUTEX_MOD_DISP_WDMA1,
};
+static const unsigned int mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8183_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_CCORR] = MT8183_MUTEX_MOD_DISP_CCORR0,
+ [DDP_COMPONENT_COLOR0] = MT8183_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_DITHER] = MT8183_MUTEX_MOD_DISP_DITHER0,
+ [DDP_COMPONENT_GAMMA] = MT8183_MUTEX_MOD_DISP_GAMMA0,
+ [DDP_COMPONENT_OVL0] = MT8183_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL_2L0] = MT8183_MUTEX_MOD_DISP_OVL0_2L,
+ [DDP_COMPONENT_OVL_2L1] = MT8183_MUTEX_MOD_DISP_OVL1_2L,
+ [DDP_COMPONENT_RDMA0] = MT8183_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA1] = MT8183_MUTEX_MOD_DISP_RDMA1,
+ [DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
+};
+
static const unsigned int mt2712_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
[DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
[DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
@@ -250,6 +292,12 @@ struct mtk_mmsys_reg_data {
[DDP_MUTEX_SOF_DSI3] = MUTEX_SOF_DSI3,
};
+static const unsigned int mt8183_mutex_sof[DDP_MUTEX_SOF_DSI3 + 1] = {
+ [DDP_MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
+ [DDP_MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0 | MT8183_MUTEX_EOF_DSI0,
+ [DDP_MUTEX_SOF_DPI0] = MT8183_MUTEX_SOF_DPI0 | MT8183_MUTEX_EOF_DPI0,
+};
+
static const struct mtk_ddp_data mt2701_ddp_driver_data = {
.mutex_mod = mt2701_mutex_mod,
.mutex_sof = mt2712_mutex_sof,
@@ -271,6 +319,13 @@ struct mtk_mmsys_reg_data {
.mutex_sof_reg = MT2701_DISP_MUTEX0_SOF0,
};
+static const struct mtk_ddp_data mt8183_ddp_driver_data = {
+ .mutex_mod = mt8183_mutex_mod,
+ .mutex_sof = mt8183_mutex_sof,
+ .mutex_mod_reg = MT8183_DISP_MUTEX0_MOD0,
+ .mutex_sof_reg = MT8183_DISP_MUTEX0_SOF0,
+};
+
const struct mtk_mmsys_reg_data mt2701_mmsys_reg_data = {
.ovl0_mout_en = DISP_REG_CONFIG_DISP_OVL_MOUT_EN,
.dsi0_sel_in = DISP_REG_CONFIG_DSI_SEL,
@@ -287,6 +342,18 @@ struct mtk_mmsys_reg_data {
.dsi0_sel_in_rdma1 = DSI0_SEL_IN_RDMA1,
};
+const struct mtk_mmsys_reg_data mt8183_mmsys_reg_data = {
+ .ovl0_mout_en = MT8183_DISP_OVL0_MOUT_EN,
+ .rdma0_sout_sel_in = MT8183_DISP_RDMA0_SOUT_SEL_IN,
+ .rdma0_sout_color0 = MT8183_RDMA0_SOUT_COLOR0,
+ .rdma1_sout_sel_in = MT8183_DISP_RDMA1_SOUT_SEL_IN,
+ .rdma1_sout_dsi0 = MT8183_RDMA1_SOUT_DSI0,
+ .dpi0_sel_in = MT8183_DISP_DPI0_SEL_IN,
+ .dpi0_sel_in_rdma1 = MT8183_DPI0_SEL_IN_RDMA1,
+ .dsi0_sel_in = MT8183_DISP_DSI0_SEL_IN,
+ .dsi0_sel_in_rdma1 = MT8183_DSI0_SEL_IN_RDMA1,
+};
+
static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next,
@@ -734,6 +801,8 @@ static int mtk_ddp_remove(struct platform_device *pdev)
.data = &mt2712_ddp_driver_data},
{ .compatible = "mediatek,mt8173-disp-mutex",
.data = &mt8173_ddp_driver_data},
+ { .compatible = "mediatek,mt8183-disp-mutex",
+ .data = &mt8183_ddp_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, ddp_driver_dt_match);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
index c55cc63..b74d8b9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
@@ -15,6 +15,7 @@
extern const struct mtk_mmsys_reg_data mt2701_mmsys_reg_data;
extern const struct mtk_mmsys_reg_data mt8173_mmsys_reg_data;
+extern const struct mtk_mmsys_reg_data mt8183_mmsys_reg_data;
void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
const struct mtk_mmsys_reg_data *reg_data,
enum mtk_ddp_comp_id cur,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 2471ce9..a4346fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -184,6 +184,24 @@ static int mtk_atomic_commit(struct drm_device *drm,
DDP_COMPONENT_DPI0,
};
+static const enum mtk_ddp_comp_id mt8183_mtk_ddp_main[] = {
+ DDP_COMPONENT_OVL0,
+ DDP_COMPONENT_OVL_2L0,
+ DDP_COMPONENT_RDMA0,
+ DDP_COMPONENT_COLOR0,
+ DDP_COMPONENT_CCORR,
+ DDP_COMPONENT_AAL0,
+ DDP_COMPONENT_GAMMA,
+ DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DSI0,
+};
+
+static const enum mtk_ddp_comp_id mt8183_mtk_ddp_ext[] = {
+ DDP_COMPONENT_OVL_2L1,
+ DDP_COMPONENT_RDMA1,
+ DDP_COMPONENT_DPI0,
+};
+
static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.main_path = mt2701_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -211,6 +229,14 @@ static int mtk_atomic_commit(struct drm_device *drm,
.reg_data = &mt8173_mmsys_reg_data,
};
+static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
+ .main_path = mt8183_mtk_ddp_main,
+ .main_len = ARRAY_SIZE(mt8183_mtk_ddp_main),
+ .ext_path = mt8183_mtk_ddp_ext,
+ .ext_len = ARRAY_SIZE(mt8183_mtk_ddp_ext),
+ .reg_data = &mt8183_mmsys_reg_data,
+};
+
static int mtk_drm_kms_init(struct drm_device *drm)
{
struct mtk_drm_private *private = drm->dev_private;
@@ -409,12 +435,22 @@ static void mtk_drm_unbind(struct device *dev)
.data = (void *)MTK_DISP_OVL },
{ .compatible = "mediatek,mt8173-disp-ovl",
.data = (void *)MTK_DISP_OVL },
+ { .compatible = "mediatek,mt8183-disp-ovl",
+ .data = (void *)MTK_DISP_OVL },
+ { .compatible = "mediatek,mt8183-disp-ovl-2l",
+ .data = (void *)MTK_DISP_OVL_2L },
{ .compatible = "mediatek,mt2701-disp-rdma",
.data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8173-disp-rdma",
.data = (void *)MTK_DISP_RDMA },
+ { .compatible = "mediatek,mt8183-disp-rdma",
+ .data = (void *)MTK_DISP_RDMA },
+ { .compatible = "mediatek,mt8183-disp-rdma1",
+ .data = (void *)MTK_DISP_RDMA },
{ .compatible = "mediatek,mt8173-disp-wdma",
.data = (void *)MTK_DISP_WDMA },
+ { .compatible = "mediatek,mt8183-disp-ccorr",
+ .data = (void *)MTK_DISP_CCORR },
{ .compatible = "mediatek,mt2701-disp-color",
.data = (void *)MTK_DISP_COLOR },
{ .compatible = "mediatek,mt8173-disp-color",
@@ -423,22 +459,30 @@ static void mtk_drm_unbind(struct device *dev)
.data = (void *)MTK_DISP_AAL},
{ .compatible = "mediatek,mt8173-disp-gamma",
.data = (void *)MTK_DISP_GAMMA, },
+ { .compatible = "mediatek,mt8183-disp-dither",
+ .data = (void *)MTK_DISP_DITHER },
{ .compatible = "mediatek,mt8173-disp-ufoe",
.data = (void *)MTK_DISP_UFOE },
{ .compatible = "mediatek,mt2701-dsi",
.data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dsi",
.data = (void *)MTK_DSI },
+ { .compatible = "mediatek,mt8183-dsi",
+ .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt2701-dpi",
.data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8173-dpi",
.data = (void *)MTK_DPI },
+ { .compatible = "mediatek,mt8183-dpi",
+ .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt2701-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2712-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex",
.data = (void *)MTK_DISP_MUTEX },
+ { .compatible = "mediatek,mt8183-disp-mutex",
+ .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt2701-disp-pwm",
.data = (void *)MTK_DISP_BLS },
{ .compatible = "mediatek,mt8173-disp-pwm",
@@ -514,6 +558,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
*/
if (comp_type == MTK_DISP_COLOR ||
comp_type == MTK_DISP_OVL ||
+ comp_type == MTK_DISP_OVL_2L ||
comp_type == MTK_DISP_RDMA ||
comp_type == MTK_DSI ||
comp_type == MTK_DPI) {
@@ -613,6 +658,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
.data = &mt2712_mmsys_driver_data},
{ .compatible = "mediatek,mt8173-mmsys",
.data = &mt8173_mmsys_driver_data},
+ { .compatible = "mediatek,mt8183-display",
+ .data = &mt8183_mmsys_driver_data},
{ }
};
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 29/32] drm/mediatek: add connection from OVL_2L1 to RDMA1
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add connection from OVL_2L1 to RDMA1
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 943e114..237824f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -34,9 +34,11 @@
#define DISP_REG_CONFIG_DPI_SEL 0x064
#define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
+#define MT8183_DISP_OVL1_2L_MOUT_EN 0xf08
#define MT8183_DISP_PATH0_SEL_IN 0xf24
#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
#define MT2701_DISP_MUTEX0_MOD0 0x2c
@@ -317,6 +319,10 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
next == DDP_COMPONENT_RDMA0) {
*addr = MT8183_DISP_OVL0_2L_MOUT_EN;
value = OVL0_2L_MOUT_EN_DISP_PATH0;
+ } else if (cur == DDP_COMPONENT_OVL_2L1 &&
+ next == DDP_COMPONENT_RDMA1) {
+ *addr = MT8183_DISP_OVL1_2L_MOUT_EN;
+ value = OVL1_2L_MOUT_EN_RDMA1;
} else {
value = 0;
}
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 30/32] drm/mediatek: add connection from DITHER0 to DSI0
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add connection from DITHER0 to DSI0
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 237824f..fd38658 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -35,10 +35,12 @@
#define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
#define MT8183_DISP_OVL1_2L_MOUT_EN 0xf08
+#define MT8183_DISP_DITHER0_MOUT_EN 0xf0c
#define MT8183_DISP_PATH0_SEL_IN 0xf24
#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
+#define DITHER0_MOUT_IN_DSI0 BIT(0)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
#define MT2701_DISP_MUTEX0_MOD0 0x2c
@@ -323,6 +325,9 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
next == DDP_COMPONENT_RDMA1) {
*addr = MT8183_DISP_OVL1_2L_MOUT_EN;
value = OVL1_2L_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_DITHER && next == DDP_COMPONENT_DSI0) {
+ *addr = MT8183_DISP_DITHER0_MOUT_EN;
+ value = DITHER0_MOUT_IN_DSI0;
} else {
value = 0;
}
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 31/32] drm/mediatek: add connection from RDMA0 to DSI0
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add connection from RDMA0 to DSI0
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index fd38658..6a7cb15 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -42,6 +42,7 @@
#define OVL1_2L_MOUT_EN_RDMA1 BIT(4)
#define DITHER0_MOUT_IN_DSI0 BIT(0)
#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
+#define DSI0_SEL_IN_RDMA0 0x1
#define MT2701_DISP_MUTEX0_MOD0 0x2c
#define MT2701_DISP_MUTEX0_SOF0 0x30
@@ -391,6 +392,9 @@ static unsigned int mtk_ddp_sel_in(const struct mtk_mmsys_reg_data *data,
next == DDP_COMPONENT_RDMA0) {
*addr = MT8183_DISP_PATH0_SEL_IN;
value = DISP_PATH0_SEL_IN_OVL0_2L;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_DSI0) {
+ *addr = data->dsi0_sel_in;
+ value = DSI0_SEL_IN_RDMA0;
} else {
value = 0;
}
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 26/32] drm/mediatek: add connection from RDMA0 to COLOR0
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add connection from RDMA0 to COLOR0
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 42a130a..03a46ec 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -171,6 +171,8 @@ struct mtk_ddp {
struct mtk_mmsys_reg_data {
u32 ovl0_mout_en;
+ u32 rdma0_sout_sel_in;
+ u32 rdma0_sout_color0;
u32 rdma1_sout_sel_in;
u32 rdma1_sout_dpi0;
u32 dpi0_sel_in;
@@ -428,6 +430,9 @@ static unsigned int mtk_ddp_sout_sel(const struct mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DSI3) {
*addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
value = RDMA2_SOUT_DSI3;
+ } else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
+ *addr = data->rdma0_sout_sel_in;
+ value = data->rdma0_sout_color0;
} else {
value = 0;
}
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 28/32] drm/mediatek: add connection from OVL_2L0 to RDMA0
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
this patch add add connection from OVL_2L0 to RDMA0
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index aa6173b..943e114 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -33,6 +33,12 @@
#define DISP_REG_CONFIG_DSI_SEL 0x050
#define DISP_REG_CONFIG_DPI_SEL 0x064
+#define MT8183_DISP_OVL0_2L_MOUT_EN 0xf04
+#define MT8183_DISP_PATH0_SEL_IN 0xf24
+
+#define OVL0_2L_MOUT_EN_DISP_PATH0 BIT(0)
+#define DISP_PATH0_SEL_IN_OVL0_2L 0x1
+
#define MT2701_DISP_MUTEX0_MOD0 0x2c
#define MT2701_DISP_MUTEX0_SOF0 0x30
@@ -307,6 +313,10 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
*addr = data->ovl0_mout_en;
value = OVL0_MOUT_EN_OVL0_2L;
+ } else if (cur == DDP_COMPONENT_OVL_2L0 &&
+ next == DDP_COMPONENT_RDMA0) {
+ *addr = MT8183_DISP_OVL0_2L_MOUT_EN;
+ value = OVL0_2L_MOUT_EN_DISP_PATH0;
} else {
value = 0;
}
@@ -366,6 +376,10 @@ static unsigned int mtk_ddp_sel_in(const struct mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
*addr = DISP_REG_CONFIG_DSI_SEL;
value = DSI_SEL_IN_BLS;
+ } else if (cur == DDP_COMPONENT_OVL_2L0 &&
+ next == DDP_COMPONENT_RDMA0) {
+ *addr = MT8183_DISP_PATH0_SEL_IN;
+ value = DISP_PATH0_SEL_IN_OVL0_2L;
} else {
value = 0;
}
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 27/32] drm/mediatek: add connection from RDMA1 to DSI0
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add connection from RDMA1 to DSI0
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 03a46ec..aa6173b 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -175,6 +175,7 @@ struct mtk_mmsys_reg_data {
u32 rdma0_sout_color0;
u32 rdma1_sout_sel_in;
u32 rdma1_sout_dpi0;
+ u32 rdma1_sout_dsi0;
u32 dpi0_sel_in;
u32 dpi0_sel_in_rdma1;
u32 dsi0_sel_in;
@@ -433,6 +434,9 @@ static unsigned int mtk_ddp_sout_sel(const struct mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_RDMA0 && next == DDP_COMPONENT_COLOR0) {
*addr = data->rdma0_sout_sel_in;
value = data->rdma0_sout_color0;
+ } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
+ *addr = data->rdma1_sout_sel_in;
+ value = data->rdma1_sout_dsi0;
} else {
value = 0;
}
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 22/32] drm/mediatek: add ovl0/ovl_2l0 usecase
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add ovl0/ovl_2l0 usecase
in ovl->ovl_2l0 direct link usecase:
1. the crtc support layer number will 4+2
2. ovl_2l0 background color input select ovl0 when crtc init
and disable it when crtc finish
3. config ovl_2l0 layer, if crtc config layer number is
bigger than ovl0 support layers(max is 4)
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 38 +++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index c63ff2b..b55970a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -270,6 +270,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
+ enum mtk_ddp_comp_id prev;
+
+ if (i > 0)
+ prev = mtk_crtc->ddp_comp[i - 1]->id;
+ else
+ prev = DDP_COMPONENT_ID_MAX;
+
+ if (prev == DDP_COMPONENT_OVL0)
+ mtk_ddp_comp_bgclr_in_on(comp);
mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
mtk_ddp_comp_start(comp);
@@ -279,9 +288,18 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
for (i = 0; i < mtk_crtc->layer_nr; i++) {
struct drm_plane *plane = &mtk_crtc->planes[i];
struct mtk_plane_state *plane_state;
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
+ unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
+ unsigned int local_layer;
plane_state = to_mtk_plane_state(plane->state);
- mtk_ddp_comp_layer_config(mtk_crtc->ddp_comp[0], i,
+
+ if (i >= comp_layer_nr) {
+ comp = mtk_crtc->ddp_comp[1];
+ local_layer = i - comp_layer_nr;
+ } else
+ local_layer = i;
+ mtk_ddp_comp_layer_config(comp, local_layer,
plane_state);
}
@@ -307,6 +325,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
mtk_crtc->ddp_comp[i]->id);
mtk_disp_mutex_disable(mtk_crtc->mutex);
for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
+ mtk_ddp_comp_bgclr_in_off(mtk_crtc->ddp_comp[i]);
mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
mtk_crtc->mmsys_reg_data,
mtk_crtc->ddp_comp[i]->id,
@@ -327,6 +346,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
unsigned int i;
+ unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
+ unsigned int local_layer;
/*
* TODO: instead of updating the registers here, we should prepare
@@ -349,7 +370,14 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
plane_state = to_mtk_plane_state(plane->state);
if (plane_state->pending.config) {
- mtk_ddp_comp_layer_config(comp, i, plane_state);
+ if (i >= comp_layer_nr) {
+ comp = mtk_crtc->ddp_comp[1];
+ local_layer = i - comp_layer_nr;
+ } else
+ local_layer = i;
+
+ mtk_ddp_comp_layer_config(comp, local_layer,
+ plane_state);
plane_state->pending.config = false;
}
}
@@ -572,6 +600,12 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
}
mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
+ if (mtk_crtc->ddp_comp_nr > 1) {
+ struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[1];
+
+ if (comp->funcs->bgclr_in_on)
+ mtk_crtc->layer_nr += mtk_ddp_comp_layer_nr(comp);
+ }
mtk_crtc->planes = devm_kcalloc(dev, mtk_crtc->layer_nr,
sizeof(struct drm_plane),
GFP_KERNEL);
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 19/32] drm/medaitek: add layer_nr for ovl private data
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add layer_nr for ovl private data
ovl_2l almost same with with ovl hardware, except the
layer number for ovl_2l is 2 and ovl is 4.
this patch is a preparation for ovl-2l and
ovl share the same driver.
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 82eaefd..baef066 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -52,6 +52,7 @@
struct mtk_disp_ovl_data {
unsigned int addr;
unsigned int gmc_bits;
+ unsigned int layer_nr;
bool fmt_rgb565_is_0;
};
@@ -129,7 +130,9 @@ static void mtk_ovl_config(struct mtk_ddp_comp *comp, unsigned int w,
static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
{
- return 4;
+ struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
+
+ return ovl->data->layer_nr;
}
static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
@@ -334,12 +337,14 @@ static int mtk_disp_ovl_remove(struct platform_device *pdev)
static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT2701,
.gmc_bits = 8,
+ .layer_nr = 4,
.fmt_rgb565_is_0 = false,
};
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
.addr = DISP_REG_OVL_ADDR_MT8173,
.gmc_bits = 8,
+ .layer_nr = 4,
.fmt_rgb565_is_0 = true,
};
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 25/32] drm/mediatek: add connection from OVL0 to OVL_2L0
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add connection from OVL0 to OVL_2L0
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index effc24a..42a130a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -137,6 +137,8 @@
#define DPI_SEL_IN_BLS 0x0
#define DSI_SEL_IN_RDMA 0x1
+#define OVL0_MOUT_EN_OVL0_2L BIT(4)
+
struct mtk_disp_mutex {
int id;
bool claimed;
@@ -299,6 +301,9 @@ static unsigned int mtk_ddp_mout_en(const struct mtk_mmsys_reg_data *data,
} else if (cur == DDP_COMPONENT_OD1 && next == DDP_COMPONENT_RDMA1) {
*addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
value = OD1_MOUT_EN_RDMA1;
+ } else if (cur == DDP_COMPONENT_OVL0 && next == DDP_COMPONENT_OVL_2L0) {
+ *addr = data->ovl0_mout_en;
+ value = OVL0_MOUT_EN_OVL0_2L;
} else {
value = 0;
}
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 23/32] drm/mediatek: distinguish ovl and ovl_2l by layer_nr
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
distinguish ovl and ovl_2l by layer_nr when get comp
id
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index eb3bf85..53f3883 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -318,7 +318,12 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
if (irq < 0)
return irq;
- comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_OVL);
+ priv->data = of_device_get_match_data(dev);
+
+ comp_id = mtk_ddp_comp_get_id(dev->of_node,
+ priv->data->layer_nr == 4 ?
+ MTK_DISP_OVL :
+ MTK_DISP_OVL_2L);
if (comp_id < 0) {
dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
return comp_id;
@@ -331,8 +336,6 @@ static int mtk_disp_ovl_probe(struct platform_device *pdev)
return ret;
}
- priv->data = of_device_get_match_data(dev);
-
platform_set_drvdata(pdev, priv);
ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 21/32] drm/mediatek: add background color input select function for ovl/ovl_2l
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add background color input select function for ovl/ovl_2l
ovl include 4 DRAM layer and 1 background color layer
ovl_2l include 4 DRAM layer and 1 background color layer
DRAM layer frame buffer data from render hardware, GPU for example.
backgournd color layer is embed in ovl/ovl_2l, we can only set
it color, but not support DRAM frame buffer.
for ovl0->ovl0_2l direct link usecase,
we need set ovl0_2l background color intput select from ovl0
if render send DRAM buffer layer number <=4, all these layer read
by ovl.
layer0 is at the bottom of all layers.
layer3 is at the top of all layers.
if render send DRAM buffer layer numbfer >=4 && <=6
ovl0 read layer0~3
ovl0_2l read layer4~5
layer5 is at the top ot all these layers.
the decision of how to setting ovl0/ovl0_2l read these layer data
is controlled in mtk crtc, which will be another patch
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index baef066..eb3bf85 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -19,6 +19,8 @@
#define DISP_REG_OVL_EN 0x000c
#define DISP_REG_OVL_RST 0x0014
#define DISP_REG_OVL_ROI_SIZE 0x0020
+#define DISP_REG_OVL_DATAPATH_CON 0x0024
+#define OVL_BGCLR_SEL_IN BIT(2)
#define DISP_REG_OVL_ROI_BGCLR 0x0028
#define DISP_REG_OVL_SRC_CON 0x002c
#define DISP_REG_OVL_CON(n) (0x0030 + 0x20 * (n))
@@ -237,6 +239,24 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
mtk_ovl_layer_on(comp, idx);
}
+static void mtk_ovl_bgclr_in_on(struct mtk_ddp_comp *comp)
+{
+ unsigned int reg;
+
+ reg = readl(comp->regs + DISP_REG_OVL_DATAPATH_CON);
+ reg = reg | OVL_BGCLR_SEL_IN;
+ writel(reg, comp->regs + DISP_REG_OVL_DATAPATH_CON);
+}
+
+static void mtk_ovl_bgclr_in_off(struct mtk_ddp_comp *comp)
+{
+ unsigned int reg;
+
+ reg = readl(comp->regs + DISP_REG_OVL_DATAPATH_CON);
+ reg = reg & ~OVL_BGCLR_SEL_IN;
+ writel(reg, comp->regs + DISP_REG_OVL_DATAPATH_CON);
+}
+
static const struct mtk_ddp_comp_funcs mtk_disp_ovl_funcs = {
.config = mtk_ovl_config,
.start = mtk_ovl_start,
@@ -247,6 +267,8 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp *comp, unsigned int idx,
.layer_on = mtk_ovl_layer_on,
.layer_off = mtk_ovl_layer_off,
.layer_config = mtk_ovl_layer_config,
+ .bgclr_in_on = mtk_ovl_bgclr_in_on,
+ .bgclr_in_off = mtk_ovl_bgclr_in_off,
};
static int mtk_disp_ovl_bind(struct device *dev, struct device *master,
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 24/32] drm/mediatek: add clock property check before get it
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add clock property check before get it
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index a5a6689..effc24a 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -657,10 +657,12 @@ static int mtk_ddp_probe(struct platform_device *pdev)
for (i = 0; i < 10; i++)
ddp->mutex[i].id = i;
- ddp->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(ddp->clk)) {
- dev_err(dev, "Failed to get clock\n");
- return PTR_ERR(ddp->clk);
+ if (of_find_property(dev->of_node, "clocks", &i)) {
+ ddp->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(ddp->clk)) {
+ dev_err(dev, "Failed to get clock\n");
+ return PTR_ERR(ddp->clk);
+ }
}
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5, 20/32] drm/mediatek: add function to background color input select for ovl/ovl_2l direct link
From: yongqiang.niu @ 2019-08-29 14:50 UTC (permalink / raw)
To: CK Hu, Philipp Zabel, Rob Herring, Matthias Brugger
Cc: Mark Rutland, devicetree, Yongqiang Niu, David Airlie,
linux-kernel, dri-devel, linux-mediatek, Daniel Vetter,
linux-arm-kernel
In-Reply-To: <1567090254-15566-1-git-send-email-yongqiang.niu@mediatek.com>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
This patch add function to background color input select for ovl/ovl_2l direct link
for ovl/ovl_2l direct link usecase, we need set background color
input select for these hardware.
this is preparation patch for ovl/ovl_2l usecase
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
index 85e096a..268d416 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
@@ -84,6 +84,8 @@ struct mtk_ddp_comp_funcs {
struct mtk_plane_state *state);
void (*gamma_set)(struct mtk_ddp_comp *comp,
struct drm_crtc_state *state);
+ void (*bgclr_in_on)(struct mtk_ddp_comp *comp);
+ void (*bgclr_in_off)(struct mtk_ddp_comp *comp);
};
struct mtk_ddp_comp {
@@ -164,6 +166,18 @@ static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp *comp,
comp->funcs->gamma_set(comp, state);
}
+static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp)
+{
+ if (comp->funcs && comp->funcs->bgclr_in_on)
+ comp->funcs->bgclr_in_on(comp);
+}
+
+static inline void mtk_ddp_comp_bgclr_in_off(struct mtk_ddp_comp *comp)
+{
+ if (comp->funcs && comp->funcs->bgclr_in_off)
+ comp->funcs->bgclr_in_off(comp);
+}
+
int mtk_ddp_comp_get_id(struct device_node *node,
enum mtk_ddp_comp_type comp_type);
int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,
--
1.8.1.1.dirty
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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