* [PATCH 1/2] ARM: dts: igep: Relicense the IGEP boards under GPLv2/X11
From: Tony Lindgren @ 2018-06-08 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608063222.GL5738@atomide.com>
* Tony Lindgren <tony@atomide.com> [180607 23:32]:
> Hi,
>
> * Enric Balletbo i Serra <enric.balletbo@collabora.com> [180606 08:27]:
> > The current GPLv2 only licensing on IGEP boards makes it very impractical
> > for other software components licensed under another license.
> >
> > In order to make it easier for them to reuse our device trees, relicense
> > all boards under a GPLv2/X11 dual-license. Also switch to use the SPDX
> > identifiers and remove the boiler plate license text.
>
> I don't think you have all the people in Cc who have already
> contributed patches to these files, can you please check the
> files with git log?
Oh and these still include omap3.dtsi and other GPL 2.0 licensed
files so this relicensing may not work out without lots of emails
and and acks from all the contributors.
Regards,
Tony
^ permalink raw reply
* [PATCH] pinctrl: pinctrl-single: Avoid divisions in context save/restore
From: Keerthy @ 2018-06-08 6:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608062602.GK5738@atomide.com>
On Friday 08 June 2018 11:56 AM, Tony Lindgren wrote:
> * Geert Uytterhoeven <geert+renesas@glider.be> [180607 13:40]:
>> The divisions (and multiplications) can be avoided by changing the loops
>> to use increments of mux_bytes instead of 1.
>> While at it, remove the unneeded casts when assigning void pointers.
>>
>> This saves +100 bytes of kernel size on arm32/arm64.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Compile-tested only.
>
> Makes sense to me:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
> Keerthy can you please test?
Tested on AM437x-gp-evm for Deep Sleep0.
Tested-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Thanks Geert!
>
> Regards,
>
> Tony
>
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-06-08 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLn+x0JCkjwABU7XkPsgvyVdiCRq=gZTfUBbbR4-c+1bQ@mail.gmail.com>
On 07 June 2018 16:55, Rob wrote:
>
> On Thu, Jun 7, 2018 at 1:59 AM, Michel Pollet
> <michel.pollet@bp.renesas.com> wrote:
> > On 06 June 2018 22:53, Frank wrote:
> >> On 06/06/18 14:48, Frank Rowand wrote:
> >> > On 06/05/18 23:36, Michel Pollet wrote:
> >> >> Hi Frank,
> >> >>
> >> >> On 05 June 2018 18:34, Frank wrote:
> >> >>> On 06/05/18 04:28, Michel Pollet wrote:
> >> >>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot
> >> >>>> time, it requires a special enable method to get it started.
>
> [...]
>
> >> >>>> + * The second CPU is parked in ROM at boot time. It requires
> >> >>>> +waking it after
> >> >>>> + * writing an address into the BOOTADDR register of sysctrl.
> >> >>>> + *
> >> >>>> + * So the default value of the "cpu-release-addr" corresponds
> >> >>>> +to
> >> >>> BOOTADDR...
> >> >>>> + *
> >> >>>> + * *However* the BOOTADDR register is not available when the
> >> >>>> +kernel
> >> >>>> + * starts in NONSEC mode.
> >> >>>> + *
> >> >>>> + * So for NONSEC mode, the bootloader re-parks the second CPU
> >> >>>> +into a pen
> >> >>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to
> >> >>>> +a SRAM address,
> >> >>>> + * which is not restricted.
> >> >>>
> >> >>> The binding document for cpu-release-addr does not have a
> >> >>> definition for 32 bit arm. The existing definition is only 64
> >> >>> bit arm. Please add the definition for 32 bit arm to patch 1.
> >> >>
> >> >> Hmmm I do find a definition in
> >> >> Documentation/devicetree/bindings/arm/cpus.txt -- just under where
> >> >> I added my 'enable-method' -- And it is already used as 32 bits in
> >> >> at least arch/arm/boot/dts/stih407-family.dtsi.
> >> >
> >> > If the correct answer is for cpu-release-addr to be 64 bits in
> >> > certain cases (that discussion is ongoing further downthread) then
> >> > one approach to maintain compatibility _and_ to fix the devicetree
> >> > source files is to change the source code that currently gets
> >> > cpu-release-addr as a
> >> > 32 bit object to check the size of the property and get it as
> >> > either a
> >> > 32 bit or 64 bit object, based on the actual size of the property
> >> > in the device tree and then change the value in the devicetree
> >> > source files to be two cells. BUT this does not consider the
> >> > bootloader complication. arch/arm/boot/dts/axm5516-cpus.dtsi has a
> >> > note "// Fixed by the boot loader", so the boot loader also has to
> >> > be modified to be able to handle the possibility that the property
> >> > could be either
> >> > 32 bits or 64 bits. I don't know how to maintain compatibility
> >> > with the boot loader since we can't force it to change
> >> > synchronously with changes in the kernel.
> >> >
> >> > You can consider this comment to be a drive-by observation. I
> >> > think Rob and Geert and people like that are likely to be more
> >> > helpful with what to actually do, and you can treat my comment more
> >> > as pointing out the issue than as providing the perfect solution.
> >>
> >> Darn it, hit <send> too quickly.
> >>
> >> I meant to mention that there are several devicetree source files
> >> that have a single cell value for cpu-release-addr, and thus
> >> potentially face the same situation, depending on what the final
> >> decision is on the proper size for cpu- release-addr. As of v4.17, a git grep
> shows one cell values in:
> >>
> >> arch/arm/boot/dts/axm5516-cpus.dtsi
> >> arch/arm/boot/dts/stih407-family.dtsi
> >> arch/arm/boot/dts/stih418.dtsi
> >
> > Yes, I had grepped before I used 32 bits on mine...
> >
> > Now, what is the decision here? Our bootloader is already modified to
> > set it to 32 bits, so I propose that
>
> And too late to fix the bootloader?
Well not too late, but read further on...
>
> >
> > + I change the driver to handle 32 and 64 bits properties
>
> That's fine if you can't fix the bootloader.
>
> > + I add this to the cpu.txt, as a separate patch:
> > # On other systems, the property can be either
> > 32 bits or 64 bits, it is the driver's responsibility
> > to deal with either sizes.
>
> That is definitely not what we want to say. Use of 32-bit should be
> considered out of spec. Yes, we have a few platforms in that category, but
> they already handle that themselves. Would be nice to fix them, but at least
> the STi platforms don't seem too active.
>
> IMO, we should delete whatever text we can here and at most just refer to
> the spec.
So actually I didn't use 32 bits by plain chance, I read the cpu.txt file which says
that 64 bits systems use 64 bits property, concluded that in my case I ought to
use 32 bits, then grepped around and found other systems using 32 bits, therefore
I went forward and used it..
Nothing said here that it should be 64 bits everywhere -- So the documentation
needs fixing somehow. Right now it certainly led me wrong.
>
> Rob
Michel
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin, _end
From: Jia He @ 2018-06-08 7:05 UTC (permalink / raw)
To: linux-arm-kernel
In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
[ 7.019116] BUG: sleeping function called from invalid context at
./include/crypto/algapi.h:416
[ 7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
cryptomgr_test
[ 7.035106] 1 lock held by cryptomgr_test/410:
[ 7.039549] #0: (ptrval) (&drbg->drbg_mutex){+.+.}, at:
drbg_instantiate+0x34/0x398
[ 7.048038] CPU: 9 PID: 410 Comm: cryptomgr_test Not tainted
4.17.0-rc6+ #27
[ 7.068228] dump_backtrace+0x0/0x1c0
[ 7.071890] show_stack+0x24/0x30
[ 7.075208] dump_stack+0xb0/0xec
[ 7.078523] ___might_sleep+0x160/0x238
[ 7.082360] skcipher_walk_done+0x118/0x2c8
[ 7.086545] ctr_encrypt+0x98/0x130
[ 7.090035] simd_skcipher_encrypt+0x68/0xc0
[ 7.094304] drbg_kcapi_sym_ctr+0xd4/0x1f8
[ 7.098400] drbg_ctr_update+0x98/0x330
[ 7.102236] drbg_seed+0x1b8/0x2f0
[ 7.105637] drbg_instantiate+0x2ac/0x398
[ 7.109646] drbg_kcapi_seed+0xbc/0x188
[ 7.113482] crypto_rng_reset+0x4c/0xb0
[ 7.117319] alg_test_drbg+0xec/0x330
[ 7.120981] alg_test.part.6+0x1c8/0x3c8
[ 7.124903] alg_test+0x58/0xa0
[ 7.128044] cryptomgr_test+0x50/0x58
[ 7.131708] kthread+0x134/0x138
[ 7.134936] ret_from_fork+0x10/0x1c
Seems there is a bug in Ard Biesheuvel's commit.
Fixes: 683381747270 ("crypto: arm64/aes-blk - move kernel mode neon
en/disable into loop")
[1] https://www.spinics.net/lists/linux-crypto/msg33103.html
Signed-off-by: jia.he at hxt-semitech.com
---
arch/arm64/crypto/aes-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 253188f..e3e5095 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -223,8 +223,8 @@ static int ctr_encrypt(struct skcipher_request *req)
kernel_neon_begin();
aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
(u8 *)ctx->key_enc, rounds, blocks, walk.iv);
- err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
kernel_neon_end();
+ err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
if (walk.nbytes) {
u8 __aligned(8) tail[AES_BLOCK_SIZE];
--
1.8.3.1
^ permalink raw reply related
* [PATCH] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin,_end
From: Jia He @ 2018-06-08 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528441502-26425-1-git-send-email-hejianet@gmail.com>
[+ Ard Biesheuvel]
On 6/8/2018 3:05 PM, Jia He Wrote:
> In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
> [ 7.019116] BUG: sleeping function called from invalid context at
> ./include/crypto/algapi.h:416
> [ 7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
> cryptomgr_test
> [ 7.035106] 1 lock held by cryptomgr_test/410:
> [ 7.039549] #0: (ptrval) (&drbg->drbg_mutex){+.+.}, at:
> drbg_instantiate+0x34/0x398
> [ 7.048038] CPU: 9 PID: 410 Comm: cryptomgr_test Not tainted
> 4.17.0-rc6+ #27
> [ 7.068228] dump_backtrace+0x0/0x1c0
> [ 7.071890] show_stack+0x24/0x30
> [ 7.075208] dump_stack+0xb0/0xec
> [ 7.078523] ___might_sleep+0x160/0x238
> [ 7.082360] skcipher_walk_done+0x118/0x2c8
> [ 7.086545] ctr_encrypt+0x98/0x130
> [ 7.090035] simd_skcipher_encrypt+0x68/0xc0
> [ 7.094304] drbg_kcapi_sym_ctr+0xd4/0x1f8
> [ 7.098400] drbg_ctr_update+0x98/0x330
> [ 7.102236] drbg_seed+0x1b8/0x2f0
> [ 7.105637] drbg_instantiate+0x2ac/0x398
> [ 7.109646] drbg_kcapi_seed+0xbc/0x188
> [ 7.113482] crypto_rng_reset+0x4c/0xb0
> [ 7.117319] alg_test_drbg+0xec/0x330
> [ 7.120981] alg_test.part.6+0x1c8/0x3c8
> [ 7.124903] alg_test+0x58/0xa0
> [ 7.128044] cryptomgr_test+0x50/0x58
> [ 7.131708] kthread+0x134/0x138
> [ 7.134936] ret_from_fork+0x10/0x1c
>
> Seems there is a bug in Ard Biesheuvel's commit.
> Fixes: 683381747270 ("crypto: arm64/aes-blk - move kernel mode neon
> en/disable into loop")
>
> [1] https://www.spinics.net/lists/linux-crypto/msg33103.html
>
> Signed-off-by: jia.he at hxt-semitech.com
> ---
> arch/arm64/crypto/aes-glue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
> index 253188f..e3e5095 100644
> --- a/arch/arm64/crypto/aes-glue.c
> +++ b/arch/arm64/crypto/aes-glue.c
> @@ -223,8 +223,8 @@ static int ctr_encrypt(struct skcipher_request *req)
> kernel_neon_begin();
> aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
> (u8 *)ctx->key_enc, rounds, blocks, walk.iv);
> - err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
> kernel_neon_end();
> + err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
> }
> if (walk.nbytes) {
> u8 __aligned(8) tail[AES_BLOCK_SIZE];
>
--
Cheers,
Jia
^ permalink raw reply
* [PATCH] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin, _end
From: Ard Biesheuvel @ 2018-06-08 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528441502-26425-1-git-send-email-hejianet@gmail.com>
On 8 June 2018 at 09:05, Jia He <hejianet@gmail.com> wrote:
> In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
> [ 7.019116] BUG: sleeping function called from invalid context at
> ./include/crypto/algapi.h:416
> [ 7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
> cryptomgr_test
> [ 7.035106] 1 lock held by cryptomgr_test/410:
> [ 7.039549] #0: (ptrval) (&drbg->drbg_mutex){+.+.}, at:
> drbg_instantiate+0x34/0x398
> [ 7.048038] CPU: 9 PID: 410 Comm: cryptomgr_test Not tainted
> 4.17.0-rc6+ #27
> [ 7.068228] dump_backtrace+0x0/0x1c0
> [ 7.071890] show_stack+0x24/0x30
> [ 7.075208] dump_stack+0xb0/0xec
> [ 7.078523] ___might_sleep+0x160/0x238
> [ 7.082360] skcipher_walk_done+0x118/0x2c8
> [ 7.086545] ctr_encrypt+0x98/0x130
> [ 7.090035] simd_skcipher_encrypt+0x68/0xc0
> [ 7.094304] drbg_kcapi_sym_ctr+0xd4/0x1f8
> [ 7.098400] drbg_ctr_update+0x98/0x330
> [ 7.102236] drbg_seed+0x1b8/0x2f0
> [ 7.105637] drbg_instantiate+0x2ac/0x398
> [ 7.109646] drbg_kcapi_seed+0xbc/0x188
> [ 7.113482] crypto_rng_reset+0x4c/0xb0
> [ 7.117319] alg_test_drbg+0xec/0x330
> [ 7.120981] alg_test.part.6+0x1c8/0x3c8
> [ 7.124903] alg_test+0x58/0xa0
> [ 7.128044] cryptomgr_test+0x50/0x58
> [ 7.131708] kthread+0x134/0x138
> [ 7.134936] ret_from_fork+0x10/0x1c
>
> Seems there is a bug in Ard Biesheuvel's commit.
> Fixes: 683381747270 ("crypto: arm64/aes-blk - move kernel mode neon
> en/disable into loop")
>
> [1] https://www.spinics.net/lists/linux-crypto/msg33103.html
>
> Signed-off-by: jia.he at hxt-semitech.com
Yes, that is a bug. My bad.
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Please tag for stable (v4.17)
> ---
> arch/arm64/crypto/aes-glue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
> index 253188f..e3e5095 100644
> --- a/arch/arm64/crypto/aes-glue.c
> +++ b/arch/arm64/crypto/aes-glue.c
> @@ -223,8 +223,8 @@ static int ctr_encrypt(struct skcipher_request *req)
> kernel_neon_begin();
> aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
> (u8 *)ctx->key_enc, rounds, blocks, walk.iv);
> - err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
> kernel_neon_end();
> + err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
> }
> if (walk.nbytes) {
> u8 __aligned(8) tail[AES_BLOCK_SIZE];
> --
> 1.8.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] crypto: arm64/aes-blk - fix and move skcipher_walk_done out of kernel_neon_begin, _end
From: Jia He @ 2018-06-08 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In a arm64 server(QDF2400),I met a similar might-sleep warning as [1]:
[ 7.019116] BUG: sleeping function called from invalid context at
./include/crypto/algapi.h:416
[ 7.027863] in_atomic(): 1, irqs_disabled(): 0, pid: 410, name:
cryptomgr_test
[ 7.035106] 1 lock held by cryptomgr_test/410:
[ 7.039549] #0: (ptrval) (&drbg->drbg_mutex){+.+.}, at:
drbg_instantiate+0x34/0x398
[ 7.048038] CPU: 9 PID: 410 Comm: cryptomgr_test Not tainted
4.17.0-rc6+ #27
[ 7.068228] dump_backtrace+0x0/0x1c0
[ 7.071890] show_stack+0x24/0x30
[ 7.075208] dump_stack+0xb0/0xec
[ 7.078523] ___might_sleep+0x160/0x238
[ 7.082360] skcipher_walk_done+0x118/0x2c8
[ 7.086545] ctr_encrypt+0x98/0x130
[ 7.090035] simd_skcipher_encrypt+0x68/0xc0
[ 7.094304] drbg_kcapi_sym_ctr+0xd4/0x1f8
[ 7.098400] drbg_ctr_update+0x98/0x330
[ 7.102236] drbg_seed+0x1b8/0x2f0
[ 7.105637] drbg_instantiate+0x2ac/0x398
[ 7.109646] drbg_kcapi_seed+0xbc/0x188
[ 7.113482] crypto_rng_reset+0x4c/0xb0
[ 7.117319] alg_test_drbg+0xec/0x330
[ 7.120981] alg_test.part.6+0x1c8/0x3c8
[ 7.124903] alg_test+0x58/0xa0
[ 7.128044] cryptomgr_test+0x50/0x58
[ 7.131708] kthread+0x134/0x138
[ 7.134936] ret_from_fork+0x10/0x1c
Seems there is a bug in Ard Biesheuvel's commit.
Fixes: 683381747270 ("crypto: arm64/aes-blk - move kernel mode neon
en/disable into loop")
[1] https://www.spinics.net/lists/linux-crypto/msg33103.html
Signed-off-by: jia.he at hxt-semitech.com
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: <stable@vger.kernel.org> # 4.17
---
v2: cc stable
---
arch/arm64/crypto/aes-glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index 253188f..e3e5095 100644
--- a/arch/arm64/crypto/aes-glue.c
+++ b/arch/arm64/crypto/aes-glue.c
@@ -223,8 +223,8 @@ static int ctr_encrypt(struct skcipher_request *req)
kernel_neon_begin();
aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
(u8 *)ctx->key_enc, rounds, blocks, walk.iv);
- err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
kernel_neon_end();
+ err = skcipher_walk_done(&walk, walk.nbytes % AES_BLOCK_SIZE);
}
if (walk.nbytes) {
u8 __aligned(8) tail[AES_BLOCK_SIZE];
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ARM: pxa, regulator: fix building ezx e680
From: Linus Walleij @ 2018-06-08 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530212514.346474-1-arnd@arndb.de>
On Wed, May 30, 2018 at 11:24 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The reference to camera_supply_gpiod_table was added in the wrong function,
> as observed from this randconfig build failure:
>
> arch/arm/mach-pxa/ezx.c: In function 'e680_init':
> arch/arm/mach-pxa/ezx.c:905:26: error: 'camera_supply_gpiod_table' undeclared (first use in this function)
> gpiod_add_lookup_table(&camera_supply_gpiod_table);
>
> Fixes: 6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I have folded this into my patch as we are deferring this
change to the next kernel cycle.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build
From: Simon Horman @ 2018-06-08 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528277116-14533-1-git-send-email-geert+renesas@glider.be>
On Wed, Jun 06, 2018 at 11:25:16AM +0200, Geert Uytterhoeven wrote:
> If CONFIG_SMP=n, building a kernel for R-Car Gen2 fails with:
>
> arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init':
> setup-rcar-gen2.c:(.init.text+0x30): undefined reference to `secure_cntvoff_init'
>
> Indeed, on R-Car Gen2 SoCs, secure_cntvoff_init() is not only needed for
> secondary CPUs, but also for the boot CPU. This is most visible on SoCs
> with Cortex A7 cores (e.g. R-Car E2, cfr. commit 9ce3fa6816c2fb59 ("ARM:
> shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794")),
> but Cortex A15 is affected, too.
>
> Fix this by always providing secure_cntvoff_init() when building for ARM
> V7.
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 7c607944bc657616 ("ARM: smp: Add initialization of CNTVOFF")
> Fixes: cad160ed0a94927e ("ARM: shmobile: Convert file to use cntvoff")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> v2:
> - Add Reviewed-by,
> - Add a dependency on CPU_V7.
> ---
> arch/arm/common/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
> index 1e9f7af8f70ff6ba..3157be413297e5d2 100644
> --- a/arch/arm/common/Makefile
> +++ b/arch/arm/common/Makefile
> @@ -10,7 +10,7 @@ obj-$(CONFIG_DMABOUNCE) += dmabounce.o
> obj-$(CONFIG_SHARP_LOCOMO) += locomo.o
> obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
> obj-$(CONFIG_SHARP_SCOOP) += scoop.o
> -obj-$(CONFIG_SMP) += secure_cntvoff.o
> +obj-$(CONFIG_CPU_V7) += secure_cntvoff.o
> obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
> obj-$(CONFIG_MCPM) += mcpm_head.o mcpm_entry.o mcpm_platsmp.o vlock.o
> CFLAGS_REMOVE_mcpm_entry.o = -pg
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77990: ebisu: Enable watchdog timer
From: Simon Horman @ 2018-06-08 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180606090359.zi46cq5ddftdaps7@verge.net.au>
On Wed, Jun 06, 2018 at 11:04:00AM +0200, Simon Horman wrote:
> On Tue, Jun 05, 2018 at 07:20:34PM +0200, Geert Uytterhoeven wrote:
> > From: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> >
> > Add a device node for the Watchdog Timer (WDT) controller on the
> > R8A77990 SoC, and enable the watchdog on the Ebisu board.
> >
> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> > [geert: Squashed 2 commits]
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Hi,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thanks Geert, applied
^ permalink raw reply
* [PATCH -next] pinctrl: mediatek: remove redundant return value check of platform_get_resource()
From: Linus Walleij @ 2018-06-08 8:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527766782-72315-1-git-send-email-weiyongjun1@huawei.com>
On Thu, May 31, 2018 at 1:39 PM, Wei Yongjun <weiyongjun1@huawei.com> wrote:
> Remove unneeded error handling on the result of a call
> to platform_get_resource() when the value is passed to
> devm_ioremap_resource().
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied for fixes.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ASoC: audio-graph-card: add hp and mic detect gpios same as simple-card
From: Katsuhiro Suzuki @ 2018-06-08 8:08 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds headphone and microphone jack detection gpios as same
as simple-card driver. This feature move into simple-card-utils from
simple-card to avoid the duplicating code.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
include/sound/simple_card_utils.h | 15 +++++++
sound/soc/generic/audio-graph-card.c | 20 ++++++++-
sound/soc/generic/simple-card-utils.c | 59 ++++++++++++++++++++++++
sound/soc/generic/simple-card.c | 64 ---------------------------
4 files changed, 93 insertions(+), 65 deletions(-)
diff --git a/include/sound/simple_card_utils.h b/include/sound/simple_card_utils.h
index 7e25afce6566..f82acef3b992 100644
--- a/include/sound/simple_card_utils.h
+++ b/include/sound/simple_card_utils.h
@@ -12,6 +12,11 @@
#include <sound/soc.h>
+#define asoc_simple_card_init_hp(card, sjack, prefix) \
+ asoc_simple_card_init_jack(card, sjack, 1, prefix)
+#define asoc_simple_card_init_mic(card, sjack, prefix) \
+ asoc_simple_card_init_jack(card, sjack, 0, prefix)
+
struct asoc_simple_dai {
const char *name;
unsigned int sysclk;
@@ -28,6 +33,12 @@ struct asoc_simple_card_data {
u32 convert_channels;
};
+struct asoc_simple_jack {
+ struct snd_soc_jack jack;
+ struct snd_soc_jack_pin pin;
+ struct snd_soc_jack_gpio gpio;
+};
+
int asoc_simple_card_parse_daifmt(struct device *dev,
struct device_node *node,
struct device_node *codec,
@@ -107,4 +118,8 @@ int asoc_simple_card_of_parse_routing(struct snd_soc_card *card,
int asoc_simple_card_of_parse_widgets(struct snd_soc_card *card,
char *prefix);
+int asoc_simple_card_init_jack(struct snd_soc_card *card,
+ struct asoc_simple_jack *sjack,
+ int is_hp, char *prefix);
+
#endif /* __SIMPLE_CARD_UTILS_H */
diff --git a/sound/soc/generic/audio-graph-card.c b/sound/soc/generic/audio-graph-card.c
index 1b6164249341..2baa60d3b3cc 100644
--- a/sound/soc/generic/audio-graph-card.c
+++ b/sound/soc/generic/audio-graph-card.c
@@ -21,7 +21,6 @@
#include <linux/of_graph.h>
#include <linux/platform_device.h>
#include <linux/string.h>
-#include <sound/jack.h>
#include <sound/simple_card_utils.h>
struct graph_card_data {
@@ -32,6 +31,8 @@ struct graph_card_data {
unsigned int mclk_fs;
} *dai_props;
unsigned int mclk_fs;
+ struct asoc_simple_jack hp_jack;
+ struct asoc_simple_jack mic_jack;
struct snd_soc_dai_link *dai_link;
struct gpio_desc *pa_gpio;
};
@@ -278,6 +279,22 @@ static int asoc_graph_get_dais_count(struct device *dev)
return count;
}
+static int asoc_graph_soc_card_probe(struct snd_soc_card *card)
+{
+ struct graph_card_data *priv = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = asoc_simple_card_init_hp(card, &priv->hp_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ ret = asoc_simple_card_init_mic(card, &priv->mic_jack, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
static int asoc_graph_card_probe(struct platform_device *pdev)
{
struct graph_card_data *priv;
@@ -319,6 +336,7 @@ static int asoc_graph_card_probe(struct platform_device *pdev)
card->num_links = num;
card->dapm_widgets = asoc_graph_card_dapm_widgets;
card->num_dapm_widgets = ARRAY_SIZE(asoc_graph_card_dapm_widgets);
+ card->probe = asoc_graph_soc_card_probe;
ret = asoc_graph_card_parse_of(priv);
if (ret < 0) {
diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
index 3751a07de6aa..4398c9580929 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -8,9 +8,13 @@
* published by the Free Software Foundation.
*/
#include <linux/clk.h>
+#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/of_graph.h>
+#include <sound/jack.h>
#include <sound/simple_card_utils.h>
void asoc_simple_card_convert_fixup(struct asoc_simple_card_data *data,
@@ -419,6 +423,61 @@ int asoc_simple_card_of_parse_widgets(struct snd_soc_card *card,
}
EXPORT_SYMBOL_GPL(asoc_simple_card_of_parse_widgets);
+int asoc_simple_card_init_jack(struct snd_soc_card *card,
+ struct asoc_simple_jack *sjack,
+ int is_hp, char *prefix)
+{
+ struct device *dev = card->dev;
+ enum of_gpio_flags flags;
+ char prop[128];
+ char *pin_name;
+ char *gpio_name;
+ int mask;
+ int det;
+
+ if (!prefix)
+ prefix = "";
+
+ sjack->gpio.gpio = -ENOENT;
+
+ if (is_hp) {
+ snprintf(prop, sizeof(prop), "%shp-det-gpio", prefix);
+ pin_name = "Headphones";
+ gpio_name = "Headphone detection";
+ mask = SND_JACK_HEADPHONE;
+ } else {
+ snprintf(prop, sizeof(prop), "%smic-det-gpio", prefix);
+ pin_name = "Mic Jack";
+ gpio_name = "Mic detection";
+ mask = SND_JACK_MICROPHONE;
+ }
+
+ det = of_get_named_gpio_flags(dev->of_node, prop, 0, &flags);
+ if (det == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+
+ if (gpio_is_valid(det)) {
+ sjack->pin.pin = pin_name;
+ sjack->pin.mask = mask;
+
+ sjack->gpio.name = gpio_name;
+ sjack->gpio.report = mask;
+ sjack->gpio.gpio = det;
+ sjack->gpio.invert = !!(flags & OF_GPIO_ACTIVE_LOW);
+ sjack->gpio.debounce_time = 150;
+
+ snd_soc_card_jack_new(card, pin_name, mask,
+ &sjack->jack,
+ &sjack->pin, 1);
+
+ snd_soc_jack_add_gpios(&sjack->jack, 1,
+ &sjack->gpio);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(asoc_simple_card_init_jack);
+
/* Module information */
MODULE_AUTHOR("Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>");
MODULE_DESCRIPTION("ALSA SoC Simple Card Utils");
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 4a516c428b3d..1bbd9e46bf2a 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -10,23 +10,14 @@
*/
#include <linux/clk.h>
#include <linux/device.h>
-#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_gpio.h>
#include <linux/platform_device.h>
#include <linux/string.h>
-#include <sound/jack.h>
#include <sound/simple_card.h>
#include <sound/soc-dai.h>
#include <sound/soc.h>
-struct asoc_simple_jack {
- struct snd_soc_jack jack;
- struct snd_soc_jack_pin pin;
- struct snd_soc_jack_gpio gpio;
-};
-
struct simple_card_data {
struct snd_soc_card snd_card;
struct simple_dai_props {
@@ -49,61 +40,6 @@ struct simple_card_data {
#define CELL "#sound-dai-cells"
#define PREFIX "simple-audio-card,"
-#define asoc_simple_card_init_hp(card, sjack, prefix)\
- asoc_simple_card_init_jack(card, sjack, 1, prefix)
-#define asoc_simple_card_init_mic(card, sjack, prefix)\
- asoc_simple_card_init_jack(card, sjack, 0, prefix)
-static int asoc_simple_card_init_jack(struct snd_soc_card *card,
- struct asoc_simple_jack *sjack,
- int is_hp, char *prefix)
-{
- struct device *dev = card->dev;
- enum of_gpio_flags flags;
- char prop[128];
- char *pin_name;
- char *gpio_name;
- int mask;
- int det;
-
- sjack->gpio.gpio = -ENOENT;
-
- if (is_hp) {
- snprintf(prop, sizeof(prop), "%shp-det-gpio", prefix);
- pin_name = "Headphones";
- gpio_name = "Headphone detection";
- mask = SND_JACK_HEADPHONE;
- } else {
- snprintf(prop, sizeof(prop), "%smic-det-gpio", prefix);
- pin_name = "Mic Jack";
- gpio_name = "Mic detection";
- mask = SND_JACK_MICROPHONE;
- }
-
- det = of_get_named_gpio_flags(dev->of_node, prop, 0, &flags);
- if (det == -EPROBE_DEFER)
- return -EPROBE_DEFER;
-
- if (gpio_is_valid(det)) {
- sjack->pin.pin = pin_name;
- sjack->pin.mask = mask;
-
- sjack->gpio.name = gpio_name;
- sjack->gpio.report = mask;
- sjack->gpio.gpio = det;
- sjack->gpio.invert = !!(flags & OF_GPIO_ACTIVE_LOW);
- sjack->gpio.debounce_time = 150;
-
- snd_soc_card_jack_new(card, pin_name, mask,
- &sjack->jack,
- &sjack->pin, 1);
-
- snd_soc_jack_add_gpios(&sjack->jack, 1,
- &sjack->gpio);
- }
-
- return 0;
-}
-
static int asoc_simple_card_startup(struct snd_pcm_substream *substream)
{
struct snd_soc_pcm_runtime *rtd = substream->private_data;
--
2.17.1
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: r8a7796: Add PCIe device nodes
From: Simon Horman @ 2018-06-08 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605080336.5xt64komcjbqbt7k@verge.net.au>
On Tue, Jun 05, 2018 at 10:03:37AM +0200, Simon Horman wrote:
> On Tue, Jun 05, 2018 at 02:49:08AM +0900, Yoshihiro Kaneko wrote:
> > From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
> >
> > This patch adds PCIe{0,1} device nodes for R8A7796 SoC.
> >
> > Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
> > Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
> > Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> Hi,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thanks Kaneko-san, applied.
^ permalink raw reply
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Simon Horman @ 2018-06-08 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
On Thu, Jun 07, 2018 at 11:17:03PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/
> DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
> connected to the LVDS output. These patches depend on the Thine THC63LVD1024
> driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
> DT patches in order to apply/compile...
>
> [1/5] arm64: dts: renesas: r8a77980: add FCPVD support
> [2/5] arm64: dts: renesas: r8a77980: add VSPD support
> [3/5] arm64: dts: renesas: r8a77980: add DU support
> [4/5] arm64: dts: renesas: r8a77980: add LVDS support
> [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
Sergei,
what are the changes in this series between v1 and v2?
^ permalink raw reply
* [PATCH 1/3] arm64: dts: renesas: r8a77980: add GPIO support
From: Simon Horman @ 2018-06-08 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdU4smhy0Z6YUVP2wr+YnJof=eW86Q9jN47r0yo3VEsB9A@mail.gmail.com>
On Wed, Jun 06, 2018 at 11:07:27AM +0200, Geert Uytterhoeven wrote:
> On Fri, Jun 1, 2018 at 10:44 PM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > Describe all 6 GPIO controllers in the R8A77980 device tree.
> >
> > Based on the original (and large) patch by Vladimir Barinov.
> >
> > Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks Sergei, applied.
^ permalink raw reply
* [PATCH] ASoC: rockchip: add config for rockchip dmaengine pcm register
From: Jianqun Xu @ 2018-06-08 8:31 UTC (permalink / raw)
To: linux-arm-kernel
This patch makes the rockchip i2s pcm configurable by adding
rockchip pcm config for devm_snd_dmaengine_pcm_register.
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
---
sound/soc/rockchip/Makefile | 3 ++-
sound/soc/rockchip/rockchip_i2s.c | 3 ++-
sound/soc/rockchip/rockchip_pcm.c | 45 +++++++++++++++++++++++++++++++++++++++
sound/soc/rockchip/rockchip_pcm.h | 14 ++++++++++++
4 files changed, 63 insertions(+), 2 deletions(-)
create mode 100644 sound/soc/rockchip/rockchip_pcm.c
create mode 100644 sound/soc/rockchip/rockchip_pcm.h
diff --git a/sound/soc/rockchip/Makefile b/sound/soc/rockchip/Makefile
index 05b078e..65e814d 100644
--- a/sound/soc/rockchip/Makefile
+++ b/sound/soc/rockchip/Makefile
@@ -1,10 +1,11 @@
# SPDX-License-Identifier: GPL-2.0
# ROCKCHIP Platform Support
snd-soc-rockchip-i2s-objs := rockchip_i2s.o
+snd-soc-rockchip-pcm-objs := rockchip_pcm.o
snd-soc-rockchip-pdm-objs := rockchip_pdm.o
snd-soc-rockchip-spdif-objs := rockchip_spdif.o
-obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-rockchip-i2s.o
+obj-$(CONFIG_SND_SOC_ROCKCHIP_I2S) += snd-soc-rockchip-i2s.o snd-soc-rockchip-pcm.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_PDM) += snd-soc-rockchip-pdm.o
obj-$(CONFIG_SND_SOC_ROCKCHIP_SPDIF) += snd-soc-rockchip-spdif.o
diff --git a/sound/soc/rockchip/rockchip_i2s.c b/sound/soc/rockchip/rockchip_i2s.c
index 908211e..5e60181 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -22,6 +22,7 @@
#include <sound/dmaengine_pcm.h>
#include "rockchip_i2s.h"
+#include "rockchip_pcm.h"
#define DRV_NAME "rockchip-i2s"
@@ -667,7 +668,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
goto err_suspend;
}
- ret = devm_snd_dmaengine_pcm_register(&pdev->dev, NULL, 0);
+ ret = rockchip_pcm_platform_register(&pdev->dev);
if (ret) {
dev_err(&pdev->dev, "Could not register PCM\n");
return ret;
diff --git a/sound/soc/rockchip/rockchip_pcm.c b/sound/soc/rockchip/rockchip_pcm.c
new file mode 100644
index 0000000..f775383
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_pcm.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2018 Rockchip Electronics Co. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/module.h>
+
+#include <sound/core.h>
+#include <sound/pcm.h>
+#include <sound/soc.h>
+#include <sound/dmaengine_pcm.h>
+
+#include "rockchip_pcm.h"
+
+static const struct snd_pcm_hardware snd_rockchip_hardware = {
+ .info = SNDRV_PCM_INFO_MMAP |
+ SNDRV_PCM_INFO_MMAP_VALID |
+ SNDRV_PCM_INFO_PAUSE |
+ SNDRV_PCM_INFO_RESUME,
+ .period_bytes_min = 32,
+ .period_bytes_max = 8192,
+ .periods_min = 1,
+ .periods_max = 52,
+ .buffer_bytes_max = 64 * 1024,
+ .fifo_size = 32,
+};
+
+static const struct snd_dmaengine_pcm_config rk_dmaengine_pcm_config = {
+ .pcm_hardware = &snd_rockchip_hardware,
+ .prealloc_buffer_size = 32 * 1024,
+};
+
+int rockchip_pcm_platform_register(struct device *dev)
+{
+ return devm_snd_dmaengine_pcm_register(dev, &rk_dmaengine_pcm_config,
+ SND_DMAENGINE_PCM_FLAG_COMPAT);
+}
+EXPORT_SYMBOL_GPL(rockchip_pcm_platform_register);
+
+MODULE_LICENSE("GPL v2");
diff --git a/sound/soc/rockchip/rockchip_pcm.h b/sound/soc/rockchip/rockchip_pcm.h
new file mode 100644
index 0000000..d6c3611
--- /dev/null
+++ b/sound/soc/rockchip/rockchip_pcm.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2018 Rockchip Electronics Co. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ROCKCHIP_PCM_H
+#define _ROCKCHIP_PCM_H
+
+int rockchip_pcm_platform_register(struct device *dev);
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v4 8/9] drm/mediatek: add third ddp path
From: Stu Hsieh @ 2018-06-08 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527493677.24367.10.camel@mtksdaap41>
On Mon, 2018-05-28 at 15:47 +0800, CK Hu wrote:
> Hi, Stu:
>
> One inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch create third crtc by third ddp path
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 +++++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 +++++--
> > 3 files changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 658b8dd45b83..2d6aa150a9ff 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -539,6 +539,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > int ret;
> > int i;
> >
> > + if (!path)
> > + return 0;
> > +
> > for (i = 0; i < path_len; i++) {
> > enum mtk_ddp_comp_id comp_id = path[i];
> > struct device_node *node;
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 08d5d0b47bfe..3d279a299383 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -232,6 +232,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > if (ret < 0)
> > goto err_component_unbind;
> >
> > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > + private->data->third_len);
> > + if (ret < 0)
> > + goto err_component_unbind;
> > +
> > /* Use OVL device for all DMA memory allocations */
> > np = private->comp_node[private->data->main_path[0]] ?:
> > private->comp_node[private->data->ext_path[0]];
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > index c3378c452c0a..d867e2683923 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> > @@ -17,8 +17,8 @@
> > #include <linux/io.h>
> > #include "mtk_drm_ddp_comp.h"
> >
> > -#define MAX_CRTC 2
> > -#define MAX_CONNECTOR 2
> > +#define MAX_CRTC 3
> > +#define MAX_CONNECTOR 3
>
> MAX_CONNECTOR is useless, maybe we just need to remove it in a clean up
> patch. Or you could keep its value.
ok
For this patch, I would keep its value.
Regards,
Stu
>
> Regards,
> CK
>
> >
> > struct device;
> > struct device_node;
> > @@ -33,6 +33,9 @@ struct mtk_mmsys_driver_data {
> > unsigned int main_len;
> > const enum mtk_ddp_comp_id *ext_path;
> > unsigned int ext_len;
> > + const enum mtk_ddp_comp_id *third_path;
> > + unsigned int third_len;
> > +
> > bool shadow_register;
> > };
> >
>
>
^ permalink raw reply
* [PATCH v2 2/2] KVM: arm/arm64: harden unmap_stage2_ptes in case end is not PAGE_SIZE aligned
From: Christoffer Dall @ 2018-06-08 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50c98169-1606-48bf-0489-124adefd2a54@gmail.com>
On Fri, May 18, 2018 at 09:04:40PM +0800, Jia He wrote:
>
>
> On 5/18/2018 5:48 PM, Marc Zyngier Wrote:
> > On 18/05/18 10:27, Jia He wrote:
> >> If it passes addr=0x202920000,size=0xfe00 to unmap_stage2_range->
> >> ...->unmap_stage2_ptes, unmap_stage2_ptes will get addr=0x202920000,
> >> end=0x20292fe00. After first while loop addr=0x202930000, end=0x20292fe00,
> >> then addr!=end. Thus it will touch another pages by put_pages() in the
> >> 2nd loop.
> >>
> >> This patch fixes it by hardening the break condition of while loop.
> >>
> >> Signed-off-by: jia.he at hxt-semitech.com
> >> ---
> >> v2: newly added
> >>
> >> virt/kvm/arm/mmu.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> >> index 8dac311..45cd040 100644
> >> --- a/virt/kvm/arm/mmu.c
> >> +++ b/virt/kvm/arm/mmu.c
> >> @@ -217,7 +217,7 @@ static void unmap_stage2_ptes(struct kvm *kvm, pmd_t *pmd,
> >>
> >> put_page(virt_to_page(pte));
> >> }
> >> - } while (pte++, addr += PAGE_SIZE, addr != end);
> >> + } while (pte++, addr += PAGE_SIZE, addr < end);
> >>
> >> if (stage2_pte_table_empty(start_pte))
> >> clear_stage2_pmd_entry(kvm, pmd, start_addr);
> >>
> >
> > I don't think this change is the right thing to do. You get that failure
> > because you're being passed a size that is not a multiple of PAGE_SIZE.
> > That's the mistake.
> >
> > You should ensure that this never happens, rather than changing the page
> > table walkers (which are consistent with the way this kind of code is
> > written in other places of the kernel). As you mentioned in your first
> > patch, the real issue is that KSM is broken, and this is what should be
> > fixed.
> >
> Got it, thanks
> Should I resend the patch 1/2 without any changes after droping patch 2/2?
>
That's fine if you trim the commit message to make it look nicer.
Also, in the future, please include a cover letter if you send more than
one patch to the list.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v4 9/9] drm/mediatek: Add support for mediatek SOC MT2712
From: Stu Hsieh @ 2018-06-08 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527494014.24367.14.camel@mtksdaap41>
Hi, CK:
On Mon, 2018-05-28 at 15:53 +0800, CK Hu wrote:
> Hi, Stu:
>
> Two inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch add support for the Mediatek MT2712 DISP subsystem.
> > There are two OVL engine and three disp output in MT2712.
> >
> > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 39 ++++++++++++++++++++++++++++++++++
> > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 +++++++++++++++++++++++++++++++++
> > 2 files changed, 77 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index 8bfc0debd2c2..3b22b48a6022 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -61,6 +61,24 @@
> > #define MT8173_MUTEX_MOD_DISP_PWM1 24
> > #define MT8173_MUTEX_MOD_DISP_OD 25
> >
> > +#define MT2712_MUTEX_MOD_DISP_PWM2 10
> > +#define MT2712_MUTEX_MOD_DISP_OVL0 11
> > +#define MT2712_MUTEX_MOD_DISP_OVL1 12
> > +#define MT2712_MUTEX_MOD_DISP_RDMA0 13
> > +#define MT2712_MUTEX_MOD_DISP_RDMA1 14
> > +#define MT2712_MUTEX_MOD_DISP_RDMA2 15
> > +#define MT2712_MUTEX_MOD_DISP_WDMA0 16
> > +#define MT2712_MUTEX_MOD_DISP_WDMA1 17
> > +#define MT2712_MUTEX_MOD_DISP_COLOR0 18
> > +#define MT2712_MUTEX_MOD_DISP_COLOR1 19
> > +#define MT2712_MUTEX_MOD_DISP_AAL0 20
> > +#define MT2712_MUTEX_MOD_DISP_UFOE 22
> > +#define MT2712_MUTEX_MOD_DISP_PWM0 23
> > +#define MT2712_MUTEX_MOD_DISP_PWM1 24
> > +#define MT2712_MUTEX_MOD_DISP_OD0 25
> > +#define MT2712_MUTEX_MOD2_DISP_AAL1 33
> > +#define MT2712_MUTEX_MOD2_DISP_OD1 34
> > +
> > #define MT2701_MUTEX_MOD_DISP_OVL 3
> > #define MT2701_MUTEX_MOD_DISP_WDMA 6
> > #define MT2701_MUTEX_MOD_DISP_COLOR 7
> > @@ -110,6 +128,26 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> > };
> >
> > +static const unsigned int mt2712_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > + [DDP_COMPONENT_AAL0] = MT2712_MUTEX_MOD_DISP_AAL0,
> > + [DDP_COMPONENT_AAL1] = MT2712_MUTEX_MOD2_DISP_AAL1,
> > + [DDP_COMPONENT_COLOR0] = MT2712_MUTEX_MOD_DISP_COLOR0,
> > + [DDP_COMPONENT_COLOR1] = MT2712_MUTEX_MOD_DISP_COLOR1,
> > + [DDP_COMPONENT_OD0] = MT2712_MUTEX_MOD_DISP_OD0,
> > + [DDP_COMPONENT_OD1] = MT2712_MUTEX_MOD2_DISP_OD1,
> > + [DDP_COMPONENT_OVL0] = MT2712_MUTEX_MOD_DISP_OVL0,
> > + [DDP_COMPONENT_OVL1] = MT2712_MUTEX_MOD_DISP_OVL1,
> > + [DDP_COMPONENT_PWM0] = MT2712_MUTEX_MOD_DISP_PWM0,
> > + [DDP_COMPONENT_PWM1] = MT2712_MUTEX_MOD_DISP_PWM1,
> > + [DDP_COMPONENT_PWM2] = MT2712_MUTEX_MOD_DISP_PWM2,
> > + [DDP_COMPONENT_RDMA0] = MT2712_MUTEX_MOD_DISP_RDMA0,
> > + [DDP_COMPONENT_RDMA1] = MT2712_MUTEX_MOD_DISP_RDMA1,
> > + [DDP_COMPONENT_RDMA2] = MT2712_MUTEX_MOD_DISP_RDMA2,
> > + [DDP_COMPONENT_UFOE] = MT2712_MUTEX_MOD_DISP_UFOE,
> > + [DDP_COMPONENT_WDMA0] = MT2712_MUTEX_MOD_DISP_WDMA0,
> > + [DDP_COMPONENT_WDMA1] = MT2712_MUTEX_MOD_DISP_WDMA1,
> > +};
> > +
> > static const unsigned int mt8173_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > [DDP_COMPONENT_AAL0] = MT8173_MUTEX_MOD_DISP_AAL,
> > [DDP_COMPONENT_COLOR0] = MT8173_MUTEX_MOD_DISP_COLOR0,
> > @@ -430,6 +468,7 @@ static int mtk_ddp_remove(struct platform_device *pdev)
> >
> > static const struct of_device_id ddp_driver_dt_match[] = {
> > { .compatible = "mediatek,mt2701-disp-mutex", .data = mt2701_mutex_mod},
> > + { .compatible = "mediatek,mt2712-disp-mutex", .data = mt2712_mutex_mod},
> > { .compatible = "mediatek,mt8173-disp-mutex", .data = mt8173_mutex_mod},
> > {},
> > };
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > index 3d279a299383..3a866e1d6af4 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > @@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> > DDP_COMPONENT_DPI0,
> > };
> >
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> > + DDP_COMPONENT_OVL0,
> > + DDP_COMPONENT_COLOR0,
> > + DDP_COMPONENT_AAL0,
> > + DDP_COMPONENT_OD0,
> > + DDP_COMPONENT_RDMA0,
> > + DDP_COMPONENT_DPI0,
> > + DDP_COMPONENT_PWM0,
> > +};
> > +
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
> > + DDP_COMPONENT_OVL1,
> > + DDP_COMPONENT_COLOR1,
> > + DDP_COMPONENT_AAL1,
> > + DDP_COMPONENT_OD1,
> > + DDP_COMPONENT_RDMA1,
> > + DDP_COMPONENT_DPI1,
>
> Where do you define DDP_COMPONENT_DPI1?
>
> > + DDP_COMPONENT_PWM1,
> > +};
> > +
> > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
> > + DDP_COMPONENT_RDMA2,
> > + DDP_COMPONENT_DSI2,
>
> Where do you define DDP_COMPONENT_DSI2?
>
I would add another patch for these component in next version patch
series.And add some connection patch from RDMAx to
DPI0/DPI1/DSI1/DSI2/DSI3.
Regards,
Stu
> Regards,
> CK
>
> > + DDP_COMPONENT_PWM2,
> > +};
> > +
> > static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> > DDP_COMPONENT_OVL0,
> > DDP_COMPONENT_COLOR0,
> > @@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> > .shadow_register = true,
> > };
> >
> > +static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> > + .main_path = mt2712_mtk_ddp_main,
> > + .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
> > + .ext_path = mt2712_mtk_ddp_ext,
> > + .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
> > + .third_path = mt2712_mtk_ddp_third,
> > + .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
> > +};
> > +
> > static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> > .main_path = mt8173_mtk_ddp_main,
> > .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> > @@ -379,6 +414,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> > { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> > { .compatible = "mediatek,mt8173-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,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
> > { .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
> > @@ -557,6 +593,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
> > static const struct of_device_id mtk_drm_of_ids[] = {
> > { .compatible = "mediatek,mt2701-mmsys",
> > .data = &mt2701_mmsys_driver_data},
> > + { .compatible = "mediatek,mt2712-mmsys",
> > + .data = &mt2712_mmsys_driver_data},
> > { .compatible = "mediatek,mt8173-mmsys",
> > .data = &mt8173_mmsys_driver_data},
> > { }
>
>
^ permalink raw reply
* [v3, 07/10] fsl/fman_port: support getting timestamp
From: kbuild test robot @ 2018-06-08 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607092050.46128-8-yangbo.lu@nxp.com>
Hi Yangbo,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20180608]
[cannot apply to v4.17]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yangbo-Lu/Support-DPAA-PTP-clock-and-timestamping/20180608-131649
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:879:26: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1035:36: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1247:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
drivers/net/ethernet/freescale/fman/fman_port.c:1249:17: sparse: expression using sizeof(void)
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
>> drivers/net/ethernet/freescale/fman/fman_port.c:1739:19: sparse: cast to restricted __be64
vim +1739 drivers/net/ethernet/freescale/fman/fman_port.c
1733
1734 int fman_port_get_tstamp(struct fman_port *port, const void *data, u64 *tstamp)
1735 {
1736 if (port->buffer_offsets.time_stamp_offset == ILLEGAL_BASE)
1737 return -EINVAL;
1738
> 1739 *tstamp = be64_to_cpu(*(u64 *)(data +
1740 port->buffer_offsets.time_stamp_offset));
1741
1742 return 0;
1743 }
1744 EXPORT_SYMBOL(fman_port_get_tstamp);
1745
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: condor: specify EtherAVB PHY IRQ
From: Simon Horman @ 2018-06-08 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <049a712d-7381-c771-c352-6badc2978175@cogentembedded.com>
On Mon, Jun 04, 2018 at 05:22:52PM +0300, Sergei Shtylyov wrote:
> On 06/04/2018 01:33 PM, Simon Horman wrote:
>
> >> Specify EtherAVB PHY IRQ in the Condor board's device tree, now that
> >> we have the GPIO support (previously phylib had to resort to polling).
> >>
> >> Based on the original (and large) patch by Vladimir Barinov.
> >>
> >> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >>
> >> ---
> >> arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> ===================================================================
> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980-condor.dts
> >> @@ -59,6 +59,8 @@
> >> phy0: ethernet-phy at 0 {
> >> rxc-skew-ps = <1500>;
> >> reg = <0>;
> >> + interrupt-parent = <&gpio1>;
> >> + interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
> >
> > I don't see this documented. Perhaps I'm missing something obvious.
>
> Have you looked into the V3H PFC section for where in the GPSRs AVB_PHY_INT
> is mapped?
Thanks, I see that now.
> The Condor schematics doesn't explicitly list the GPIO for AVB_PHY_INT
> because that signal is meant to be routed thru the MAC. Unfortunately, the
> sh_eth/ravb drivers don't support the PHY interrupt (the phylib function,
> phy_mac_interrupt() reporting the PHY interrupts routed thru MAC is clearly
> inadequate as it wants the link state as an argument), so we have to resort
> to the GPIO interrupts...
Understood.
> > Or you have some extra information or newer documentation?
>
> No.
>
> > Also, given Olof Johansson's recent comments in ("Re: [GIT PULL] Renesas
> > ARM64 Based SoC DT Updates for v4.18") please consider squashing this patch
> > and the following one.
>
> Hm... note that the different Ether cores are involved in these 2 PHY IRQ
> patches. If that's OK, I can merge the patches...
Tough call. Functionally these are both ethernet even though they are
different IP cores. So I think I prefer a squash.
I have applied 1/3 of this series and will push shortly.
^ permalink raw reply
* [PATCH v2 0/5] add virt-dma support for imx-sdma
From: Sascha Hauer @ 2018-06-08 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528465490-19684-1-git-send-email-yibin.gong@nxp.com>
On Fri, Jun 08, 2018 at 09:44:45PM +0800, Robin Gong wrote:
> The legacy sdma driver has below limitations or drawbacks:
> 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
> one page size for one channel regardless of only few BDs needed
> most time. But in few cases, the max PAGE_SIZE maybe not enough.
> 2. One SDMA channel can't stop immediatley once channel disabled which
> means SDMA interrupt may come in after this channel terminated.There
> are some patches for this corner case such as commit "2746e2c389f9",
> but not cover non-cyclic.
>
> The common virt-dma overcomes the above limitations. It can alloc bd
> dynamically and free bd once this tx transfer done. No memory wasted or
> maximum limititation here, only depends on how many memory can be requested
> from kernel. For No.2, such issue can be workaround by checking if there
> is available descript("sdmac->desc") now once the unwanted interrupt
> coming. At last the common virt-dma is easier for sdma driver maintain.
>
> Change from v1:
> 1. split v1 patch into 5 patches.
> 2. remove some unnecessary condition check.
> 3. remove unneccessary 'pending' list.
>
> Robin Gong (5):
> dmaengine: imx-sdma: add virt-dma support
> Revert "dmaengine: imx-sdma: fix pagefault when channel is disabled
> during interrupt"
> dmaengine: imx-sdma: remove usless lock
> dmaengine: imx-sdma: remove the maximum limation for bd numbers
> dmaengine: imx-sdma: add sdma_transfer_init to decrease code overlap
>
> drivers/dma/Kconfig | 1 +
> drivers/dma/imx-sdma.c | 392 ++++++++++++++++++++++++++++---------------------
> 2 files changed, 227 insertions(+), 166 deletions(-)
Please put the attached patch in front of your series. It makes the
virt-dma support patch smaller and thus easier to review.
Sascha
--------------------------------8<----------------------------------
>From a70ccdf780cc6fcddd2d06c4a3eb0123d4aba443 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Fri, 8 Jun 2018 10:20:18 +0200
Subject: [PATCH 1/2] dmaengine: imx-sdma: factor out a struct sdma_desc from
struct sdma_channel
This is a preparation step to make the adding of virt-dma easier.
We create a struct sdma_desc, move some fields from struct sdma_channel
there and add a pointer from the former to the latter. For now we
allocate the data statically in struct sdma_channel, but with
virt-dma support it will be dynamically allocated.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/dma/imx-sdma.c | 137 +++++++++++++++++++++++++----------------
1 file changed, 83 insertions(+), 54 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index ccd03c3cedfe..556d08712f4a 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -295,6 +295,30 @@ struct sdma_context_data {
struct sdma_engine;
+/**
+ * struct sdma_desc - descriptor structor for one transfer
+ * @vd descriptor for virt dma
+ * @num_bd max NUM_BD. number of descriptors currently handling
+ * @buf_tail ID of the buffer that was processed
+ * @buf_ptail ID of the previous buffer that was processed
+ * @period_len period length, used in cyclic.
+ * @chn_real_count the real count updated from bd->mode.count
+ * @chn_count the transfer count setuped
+ * @sdmac sdma_channel pointer
+ * @bd pointer of alloced bd
+ */
+struct sdma_desc {
+ unsigned int num_bd;
+ dma_addr_t bd_phys;
+ unsigned int buf_tail;
+ unsigned int buf_ptail;
+ unsigned int period_len;
+ unsigned int chn_real_count;
+ unsigned int chn_count;
+ struct sdma_channel *sdmac;
+ struct sdma_buffer_descriptor *bd;
+};
+
/**
* struct sdma_channel - housekeeping for a SDMA channel
*
@@ -305,11 +329,10 @@ struct sdma_engine;
* @event_id0 aka dma request line
* @event_id1 for channels that use 2 events
* @word_size peripheral access size
- * @buf_tail ID of the buffer that was processed
- * @buf_ptail ID of the previous buffer that was processed
- * @num_bd max NUM_BD. number of descriptors currently handling
*/
struct sdma_channel {
+ struct sdma_desc *desc;
+ struct sdma_desc _desc;
struct sdma_engine *sdma;
unsigned int channel;
enum dma_transfer_direction direction;
@@ -317,12 +340,6 @@ struct sdma_channel {
unsigned int event_id0;
unsigned int event_id1;
enum dma_slave_buswidth word_size;
- unsigned int buf_tail;
- unsigned int buf_ptail;
- unsigned int num_bd;
- unsigned int period_len;
- struct sdma_buffer_descriptor *bd;
- dma_addr_t bd_phys;
unsigned int pc_from_device, pc_to_device;
unsigned int device_to_device;
unsigned long flags;
@@ -332,10 +349,8 @@ struct sdma_channel {
u32 shp_addr, per_addr;
struct dma_chan chan;
spinlock_t lock;
- struct dma_async_tx_descriptor desc;
+ struct dma_async_tx_descriptor txdesc;
enum dma_status status;
- unsigned int chn_count;
- unsigned int chn_real_count;
struct tasklet_struct tasklet;
struct imx_dma_data data;
bool enabled;
@@ -398,6 +413,8 @@ struct sdma_engine {
u32 spba_start_addr;
u32 spba_end_addr;
unsigned int irq;
+ dma_addr_t bd0_phys;
+ struct sdma_buffer_descriptor *bd0;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -632,7 +649,7 @@ static int sdma_run_channel0(struct sdma_engine *sdma)
static int sdma_load_script(struct sdma_engine *sdma, void *buf, int size,
u32 address)
{
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
void *buf_virt;
dma_addr_t buf_phys;
int ret;
@@ -707,7 +724,9 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* call callback function.
*/
while (1) {
- bd = &sdmac->bd[sdmac->buf_tail];
+ struct sdma_desc *desc = sdmac->desc;
+
+ bd = &desc->bd[desc->buf_tail];
if (bd->mode.status & BD_DONE)
break;
@@ -723,11 +742,11 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* the number of bytes present in the current buffer descriptor.
*/
- sdmac->chn_real_count = bd->mode.count;
+ desc->chn_real_count = bd->mode.count;
bd->mode.status |= BD_DONE;
- bd->mode.count = sdmac->period_len;
- sdmac->buf_ptail = sdmac->buf_tail;
- sdmac->buf_tail = (sdmac->buf_tail + 1) % sdmac->num_bd;
+ bd->mode.count = desc->period_len;
+ desc->buf_ptail = desc->buf_tail;
+ desc->buf_tail = (desc->buf_tail + 1) % desc->num_bd;
/*
* The callback is called from the interrupt context in order
@@ -736,7 +755,7 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
* executed.
*/
- dmaengine_desc_get_callback_invoke(&sdmac->desc, NULL);
+ dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
if (error)
sdmac->status = old_status;
@@ -749,17 +768,17 @@ static void mxc_sdma_handle_channel_normal(unsigned long data)
struct sdma_buffer_descriptor *bd;
int i, error = 0;
- sdmac->chn_real_count = 0;
+ sdmac->desc->chn_real_count = 0;
/*
* non loop mode. Iterate over all descriptors, collect
* errors and call callback function
*/
- for (i = 0; i < sdmac->num_bd; i++) {
- bd = &sdmac->bd[i];
+ for (i = 0; i < sdmac->desc->num_bd; i++) {
+ bd = &sdmac->desc->bd[i];
if (bd->mode.status & (BD_DONE | BD_RROR))
error = -EIO;
- sdmac->chn_real_count += bd->mode.count;
+ sdmac->desc->chn_real_count += bd->mode.count;
}
if (error)
@@ -767,9 +786,9 @@ static void mxc_sdma_handle_channel_normal(unsigned long data)
else
sdmac->status = DMA_COMPLETE;
- dma_cookie_complete(&sdmac->desc);
+ dma_cookie_complete(&sdmac->txdesc);
- dmaengine_desc_get_callback_invoke(&sdmac->desc, NULL);
+ dmaengine_desc_get_callback_invoke(&sdmac->txdesc, NULL);
}
static irqreturn_t sdma_int_handler(int irq, void *dev_id)
@@ -897,7 +916,7 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int channel = sdmac->channel;
int load_address;
struct sdma_context_data *context = sdma->context;
- struct sdma_buffer_descriptor *bd0 = sdma->channel[0].bd;
+ struct sdma_buffer_descriptor *bd0 = sdma->bd0;
int ret;
unsigned long flags;
@@ -1100,18 +1119,22 @@ static int sdma_set_channel_priority(struct sdma_channel *sdmac,
static int sdma_request_channel(struct sdma_channel *sdmac)
{
struct sdma_engine *sdma = sdmac->sdma;
+ struct sdma_desc *desc;
int channel = sdmac->channel;
int ret = -EBUSY;
- sdmac->bd = dma_zalloc_coherent(NULL, PAGE_SIZE, &sdmac->bd_phys,
+ sdmac->desc = &sdmac->_desc;
+ desc = sdmac->desc;
+
+ desc->bd = dma_zalloc_coherent(NULL, PAGE_SIZE, &desc->bd_phys,
GFP_KERNEL);
- if (!sdmac->bd) {
+ if (!desc->bd) {
ret = -ENOMEM;
goto out;
}
- sdma->channel_control[channel].base_bd_ptr = sdmac->bd_phys;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ sdma->channel_control[channel].base_bd_ptr = desc->bd_phys;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
sdma_set_channel_priority(sdmac, MXC_SDMA_DEFAULT_PRIORITY);
return 0;
@@ -1176,10 +1199,10 @@ static int sdma_alloc_chan_resources(struct dma_chan *chan)
if (ret)
goto disable_clk_ahb;
- dma_async_tx_descriptor_init(&sdmac->desc, chan);
- sdmac->desc.tx_submit = sdma_tx_submit;
+ dma_async_tx_descriptor_init(&sdmac->txdesc, chan);
+ sdmac->txdesc.tx_submit = sdma_tx_submit;
/* txd.flags will be overwritten in prep funcs */
- sdmac->desc.flags = DMA_CTRL_ACK;
+ sdmac->txdesc.flags = DMA_CTRL_ACK;
return 0;
@@ -1194,6 +1217,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
+ struct sdma_desc *desc = sdmac->desc;
sdma_disable_channel(chan);
@@ -1207,7 +1231,7 @@ static void sdma_free_chan_resources(struct dma_chan *chan)
sdma_set_channel_priority(sdmac, 0);
- dma_free_coherent(NULL, PAGE_SIZE, sdmac->bd, sdmac->bd_phys);
+ dma_free_coherent(NULL, PAGE_SIZE, desc->bd, desc->bd_phys);
clk_disable(sdma->clk_ipg);
clk_disable(sdma->clk_ahb);
@@ -1223,6 +1247,7 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
int ret, i, count;
int channel = sdmac->channel;
struct scatterlist *sg;
+ struct sdma_desc *desc = sdmac->desc;
if (sdmac->status == DMA_IN_PROGRESS)
return NULL;
@@ -1230,9 +1255,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
sdmac->flags = 0;
- sdmac->buf_tail = 0;
- sdmac->buf_ptail = 0;
- sdmac->chn_real_count = 0;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->chn_real_count = 0;
dev_dbg(sdma->dev, "setting up %d entries for channel %d.\n",
sg_len, channel);
@@ -1249,9 +1274,9 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
goto err_out;
}
- sdmac->chn_count = 0;
+ desc->chn_count = 0;
for_each_sg(sgl, sg, sg_len, i) {
- struct sdma_buffer_descriptor *bd = &sdmac->bd[i];
+ struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
bd->buffer_addr = sg->dma_address;
@@ -1266,7 +1291,7 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
}
bd->mode.count = count;
- sdmac->chn_count += count;
+ desc->chn_count += count;
if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES) {
ret = -EINVAL;
@@ -1307,10 +1332,10 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
bd->mode.status = param;
}
- sdmac->num_bd = sg_len;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ desc->num_bd = sg_len;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
- return &sdmac->desc;
+ return &sdmac->txdesc;
err_out:
sdmac->status = DMA_ERROR;
return NULL;
@@ -1326,6 +1351,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
int num_periods = buf_len / period_len;
int channel = sdmac->channel;
int ret, i = 0, buf = 0;
+ struct sdma_desc *desc = sdmac->desc;
dev_dbg(sdma->dev, "%s channel: %d\n", __func__, channel);
@@ -1334,10 +1360,10 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
sdmac->status = DMA_IN_PROGRESS;
- sdmac->buf_tail = 0;
- sdmac->buf_ptail = 0;
- sdmac->chn_real_count = 0;
- sdmac->period_len = period_len;
+ desc->buf_tail = 0;
+ desc->buf_ptail = 0;
+ desc->chn_real_count = 0;
+ desc->period_len = period_len;
sdmac->flags |= IMX_DMA_SG_LOOP;
sdmac->direction = direction;
@@ -1358,7 +1384,7 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
}
while (buf < buf_len) {
- struct sdma_buffer_descriptor *bd = &sdmac->bd[i];
+ struct sdma_buffer_descriptor *bd = &desc->bd[i];
int param;
bd->buffer_addr = dma_addr;
@@ -1389,10 +1415,10 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
i++;
}
- sdmac->num_bd = num_periods;
- sdma->channel_control[channel].current_bd_ptr = sdmac->bd_phys;
+ desc->num_bd = num_periods;
+ sdma->channel_control[channel].current_bd_ptr = desc->bd_phys;
- return &sdmac->desc;
+ return &sdmac->txdesc;
err_out:
sdmac->status = DMA_ERROR;
return NULL;
@@ -1431,13 +1457,14 @@ static enum dma_status sdma_tx_status(struct dma_chan *chan,
struct dma_tx_state *txstate)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
+ struct sdma_desc *desc = sdmac->desc;
u32 residue;
if (sdmac->flags & IMX_DMA_SG_LOOP)
- residue = (sdmac->num_bd - sdmac->buf_ptail) *
- sdmac->period_len - sdmac->chn_real_count;
+ residue = (desc->num_bd - desc->buf_ptail) *
+ desc->period_len - desc->chn_real_count;
else
- residue = sdmac->chn_count - sdmac->chn_real_count;
+ residue = desc->chn_count - desc->chn_real_count;
dma_set_tx_state(txstate, chan->completed_cookie, chan->cookie,
residue);
@@ -1661,6 +1688,8 @@ static int sdma_init(struct sdma_engine *sdma)
if (ret)
goto err_dma_alloc;
+ sdma->bd0 = sdma->channel[0].desc->bd;
+
sdma_config_ownership(&sdma->channel[0], false, true, false);
/* Set Command Channel (Channel Zero) */
--
2.17.1
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply related
* [PATCH v2 1/5] dmaengine: imx-sdma: add virt-dma support
From: Sascha Hauer @ 2018-06-08 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528465490-19684-2-git-send-email-yibin.gong@nxp.com>
On Fri, Jun 08, 2018 at 09:44:46PM +0800, Robin Gong wrote:
> The legacy sdma driver has below limitations or drawbacks:
> 1. Hardcode the max BDs number as "PAGE_SIZE / sizeof(*)", and alloc
> one page size for one channel regardless of only few BDs needed
> most time. But in few cases, the max PAGE_SIZE maybe not enough.
> 2. One SDMA channel can't stop immediatley once channel disabled which
> means SDMA interrupt may come in after this channel terminated.There
> are some patches for this corner case such as commit "2746e2c389f9",
> but not cover non-cyclic.
>
> The common virt-dma overcomes the above limitations. It can alloc bd
> dynamically and free bd once this tx transfer done. No memory wasted or
> maximum limititation here, only depends on how many memory can be requested
> from kernel. For No.2, such issue can be workaround by checking if there
> is available descript("sdmac->desc") now once the unwanted interrupt
> coming. At last the common virt-dma is easier for sdma driver maintain.
>
> The main changes as below:
> --new "sdma_desc" structure containing virt_dma_desc and some members
> which moved from "sdma_channel" such as "num_bd","bd_phys","bd",etc,
> since multi descriptors may exist on virtual dma framework
> rather than only one as before.
> --remove some members of "sdma_channel" structure since it's handled
> by virtual dma common framework, such as "tasklet", "dma_chan",etc.
> --add specific BD0 for channel0 since such bd descriptor is must and
> basic for other dma channel, no need alloc/free as other channel,so
> request it during probe.
> --remove sdma_request_channel(),sdma_tx_submit(),etc.
> --alloc/free bd descriptor added and code changes for virtual dma.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> ---
> drivers/dma/Kconfig | 1 +
> drivers/dma/imx-sdma.c | 332 ++++++++++++++++++++++++++++++++-----------------
> 2 files changed, 220 insertions(+), 113 deletions(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index ca1680a..d4a4230 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -250,6 +250,7 @@ config IMX_SDMA
> tristate "i.MX SDMA support"
> depends on ARCH_MXC
> select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> help
> Support the i.MX SDMA engine. This engine is integrated into
> Freescale i.MX25/31/35/51/53/6 chips.
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index ccd03c3..8d0c1fd 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -48,6 +48,7 @@
> #include <linux/mfd/syscon/imx6q-iomuxc-gpr.h>
>
> #include "dmaengine.h"
> +#include "virt-dma.h"
>
> /* SDMA registers */
> #define SDMA_H_C0PTR 0x000
> @@ -296,6 +297,31 @@ struct sdma_context_data {
> struct sdma_engine;
>
> /**
> + * struct sdma_desc - descriptor structor for one transfer
> + * @vd descriptor for virt dma
> + * @num_bd max NUM_BD. number of descriptors currently handling
> + * @buf_tail ID of the buffer that was processed
> + * @buf_ptail ID of the previous buffer that was processed
> + * @period_len period length, used in cyclic.
> + * @chn_real_count the real count updated from bd->mode.count
> + * @chn_count the transfer count setuped
> + * @sdmac sdma_channel pointer
> + * @bd pointer of alloced bd
> + */
> +struct sdma_desc {
> + struct virt_dma_desc vd;
> + unsigned int num_bd;
> + dma_addr_t bd_phys;
> + unsigned int buf_tail;
> + unsigned int buf_ptail;
> + unsigned int period_len;
> + unsigned int chn_real_count;
> + unsigned int chn_count;
> + struct sdma_channel *sdmac;
> + struct sdma_buffer_descriptor *bd;
> +};
> +
> +/**
> * struct sdma_channel - housekeeping for a SDMA channel
> *
> * @sdma pointer to the SDMA engine for this channel
> @@ -305,11 +331,10 @@ struct sdma_engine;
> * @event_id0 aka dma request line
> * @event_id1 for channels that use 2 events
> * @word_size peripheral access size
> - * @buf_tail ID of the buffer that was processed
> - * @buf_ptail ID of the previous buffer that was processed
> - * @num_bd max NUM_BD. number of descriptors currently handling
> */
> struct sdma_channel {
> + struct virt_dma_chan vc;
> + struct sdma_desc *desc;
> struct sdma_engine *sdma;
> unsigned int channel;
> enum dma_transfer_direction direction;
> @@ -317,12 +342,6 @@ struct sdma_channel {
> unsigned int event_id0;
> unsigned int event_id1;
> enum dma_slave_buswidth word_size;
> - unsigned int buf_tail;
> - unsigned int buf_ptail;
> - unsigned int num_bd;
> - unsigned int period_len;
> - struct sdma_buffer_descriptor *bd;
> - dma_addr_t bd_phys;
> unsigned int pc_from_device, pc_to_device;
> unsigned int device_to_device;
> unsigned long flags;
> @@ -330,13 +349,10 @@ struct sdma_channel {
> unsigned long event_mask[2];
> unsigned long watermark_level;
> u32 shp_addr, per_addr;
> - struct dma_chan chan;
> spinlock_t lock;
> - struct dma_async_tx_descriptor desc;
> enum dma_status status;
> unsigned int chn_count;
> unsigned int chn_real_count;
These are no longer used here and should be removed.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v4 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-06-08 8:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <OSBPR01MB2054A701CF65784FAB947692D27B0@OSBPR01MB2054.jpnprd01.prod.outlook.com>
On Fri, Jun 8, 2018 at 8:50 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> On 07 June 2018 16:55, Rob wrote:
>> On Thu, Jun 7, 2018 at 1:59 AM, Michel Pollet
>> <michel.pollet@bp.renesas.com> wrote:
>> > On 06 June 2018 22:53, Frank wrote:
>> >> On 06/06/18 14:48, Frank Rowand wrote:
>> >> > On 06/05/18 23:36, Michel Pollet wrote:
>> >> >> On 05 June 2018 18:34, Frank wrote:
>> >> >>> On 06/05/18 04:28, Michel Pollet wrote:
>> >> >>>> The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot
>> >> >>>> time, it requires a special enable method to get it started.
>>
>> [...]
>>
>> >> >>>> + * The second CPU is parked in ROM at boot time. It requires
>> >> >>>> +waking it after
>> >> >>>> + * writing an address into the BOOTADDR register of sysctrl.
>> >> >>>> + *
>> >> >>>> + * So the default value of the "cpu-release-addr" corresponds
>> >> >>>> +to
>> >> >>> BOOTADDR...
>> >> >>>> + *
>> >> >>>> + * *However* the BOOTADDR register is not available when the
>> >> >>>> +kernel
>> >> >>>> + * starts in NONSEC mode.
>> >> >>>> + *
>> >> >>>> + * So for NONSEC mode, the bootloader re-parks the second CPU
>> >> >>>> +into a pen
>> >> >>>> + * in SRAM, and changes the "cpu-release-addr" of linux's DT to
>> >> >>>> +a SRAM address,
>> >> >>>> + * which is not restricted.
>> >> >>>
>> >> >>> The binding document for cpu-release-addr does not have a
>> >> >>> definition for 32 bit arm. The existing definition is only 64
>> >> >>> bit arm. Please add the definition for 32 bit arm to patch 1.
>> >> >>
>> >> >> Hmmm I do find a definition in
>> >> >> Documentation/devicetree/bindings/arm/cpus.txt -- just under where
>> >> >> I added my 'enable-method' -- And it is already used as 32 bits in
>> >> >> at least arch/arm/boot/dts/stih407-family.dtsi.
>> >> >
>> >> > If the correct answer is for cpu-release-addr to be 64 bits in
>> >> > certain cases (that discussion is ongoing further downthread) then
>> >> > one approach to maintain compatibility _and_ to fix the devicetree
>> >> > source files is to change the source code that currently gets
>> >> > cpu-release-addr as a
>> >> > 32 bit object to check the size of the property and get it as
>> >> > either a
>> >> > 32 bit or 64 bit object, based on the actual size of the property
>> >> > in the device tree and then change the value in the devicetree
>> >> > source files to be two cells. BUT this does not consider the
>> >> > bootloader complication. arch/arm/boot/dts/axm5516-cpus.dtsi has a
>> >> > note "// Fixed by the boot loader", so the boot loader also has to
>> >> > be modified to be able to handle the possibility that the property
>> >> > could be either
>> >> > 32 bits or 64 bits. I don't know how to maintain compatibility
>> >> > with the boot loader since we can't force it to change
>> >> > synchronously with changes in the kernel.
>> >> >
>> >> > You can consider this comment to be a drive-by observation. I
>> >> > think Rob and Geert and people like that are likely to be more
>> >> > helpful with what to actually do, and you can treat my comment more
>> >> > as pointing out the issue than as providing the perfect solution.
>> >>
>> >> Darn it, hit <send> too quickly.
>> >>
>> >> I meant to mention that there are several devicetree source files
>> >> that have a single cell value for cpu-release-addr, and thus
>> >> potentially face the same situation, depending on what the final
>> >> decision is on the proper size for cpu- release-addr. As of v4.17, a git grep
>> shows one cell values in:
>> >>
>> >> arch/arm/boot/dts/axm5516-cpus.dtsi
>> >> arch/arm/boot/dts/stih407-family.dtsi
>> >> arch/arm/boot/dts/stih418.dtsi
>> >
>> > Yes, I had grepped before I used 32 bits on mine...
>> >
>> > Now, what is the decision here? Our bootloader is already modified to
>> > set it to 32 bits, so I propose that
>>
>> And too late to fix the bootloader?
>
>
> Well not too late, but read further on...
>
>>
>> >
>> > + I change the driver to handle 32 and 64 bits properties
>>
>> That's fine if you can't fix the bootloader.
>>
>> > + I add this to the cpu.txt, as a separate patch:
>> > # On other systems, the property can be either
>> > 32 bits or 64 bits, it is the driver's responsibility
>> > to deal with either sizes.
>>
>> That is definitely not what we want to say. Use of 32-bit should be
>> considered out of spec. Yes, we have a few platforms in that category, but
>> they already handle that themselves. Would be nice to fix them, but at least
>> the STi platforms don't seem too active.
>>
>> IMO, we should delete whatever text we can here and at most just refer to
>> the spec.
>
> So actually I didn't use 32 bits by plain chance, I read the cpu.txt file which says
> that 64 bits systems use 64 bits property, concluded that in my case I ought to
> use 32 bits, then grepped around and found other systems using 32 bits, therefore
> I went forward and used it..
>
> Nothing said here that it should be 64 bits everywhere -- So the documentation
> needs fixing somehow. Right now it certainly led me wrong.
Perhaps we should add to Documentation/devicetree/bindings/ the standard
bindings from ePAPR and successors, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-08 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608082125.tjnd6jayecv26csv@verge.net.au>
On 6/8/2018 11:21 AM, Simon Horman wrote:
>> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's
>> 'renesas-devel-20180604-v4.17' tag. We're adding the R8A77980 FCPVD/VSPD/
>> DU/LVDS device nodes and then describing the LVDS decoder and HDMI encoder
>> connected to the LVDS output. These patches depend on the Thine THC63LVD1024
>> driver and the R8A77980 LVDS support patch in order to work, and R8A77980 GPIO
>> DT patches in order to apply/compile...
>>
>> [1/5] arm64: dts: renesas: r8a77980: add FCPVD support
>> [2/5] arm64: dts: renesas: r8a77980: add VSPD support
>> [3/5] arm64: dts: renesas: r8a77980: add DU support
>> [4/5] arm64: dts: renesas: r8a77980: add LVDS support
>> [5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
>
> Sergei,
>
> what are the changes in this series between v1 and v2?
See patch #5. I've added the V3HSK DT update there...
MBR, Sergei
^ 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