* [PATCH] media: helene: fix xtal frequency setting at power on
From: Abylay Ospan @ 2018-05-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516084120.28674-1-suzuki.katsuhiro@socionext.com>
Acked-by: Abylay Ospan <aospan@netup.ru>
2018-05-16 4:41 GMT-04:00 Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>:
> This patch fixes crystal frequency setting when power on this device.
>
> Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
> ---
> drivers/media/dvb-frontends/helene.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/helene.c b/drivers/media/dvb-frontends/helene.c
> index 0a4f312c4368..8fcf7a00782a 100644
> --- a/drivers/media/dvb-frontends/helene.c
> +++ b/drivers/media/dvb-frontends/helene.c
> @@ -924,7 +924,10 @@ static int helene_x_pon(struct helene_priv *priv)
> helene_write_regs(priv, 0x99, cdata, sizeof(cdata));
>
> /* 0x81 - 0x94 */
> - data[0] = 0x18; /* xtal 24 MHz */
> + if (priv->xtal == SONY_HELENE_XTAL_16000)
> + data[0] = 0x10; /* xtal 16 MHz */
> + else
> + data[0] = 0x18; /* xtal 24 MHz */
> data[1] = (uint8_t)(0x80 | (0x04 & 0x1F)); /* 4 x 25 = 100uA */
> data[2] = (uint8_t)(0x80 | (0x26 & 0x7F)); /* 38 x 0.25 = 9.5pF */
> data[3] = 0x80; /* REFOUT signal output 500mVpp */
> --
> 2.17.0
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
^ permalink raw reply
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
From: Sudeep Holla @ 2018-05-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VciOAMX1HWifZ+K9GiVicZRFrwHaGteJFVe1uFrh+qu0w@mail.gmail.com>
Hi Andy,
On 15/05/18 20:32, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>
>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>> + cache_size = of_get_property(np, propname, NULL);
>>> if (cache_size)
>>> this_leaf->size = of_read_number(cache_size, 1);
>
> Can't you switch to of_read_property_uXX() variant here?
>
This patch is just changing the first argument to the calls. So if we
need to change, it has to be separate patch.
Now, we can use of_property_read_u64() but is there any particular
reason you mention that ? One reason I can see is that we can avoid
making explicit of_get_property call. Just wanted to the motive before I
can write the patch.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] arm64: Select ARCH_HAS_FAST_MULTIPLIER
From: Catalin Marinas @ 2018-05-16 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877b532d8d240c1d9e9db923c84b924443a218ed.1524583390.git.robin.murphy@arm.com>
On Tue, Apr 24, 2018 at 04:25:47PM +0100, Robin Murphy wrote:
> It is probably safe to assume that all Armv8-A implementations have a
> multiplier whose efficiency is comparable or better than a sequence of
> three or so register-dependent arithmetic instructions. Select
> ARCH_HAS_FAST_MULTIPLIER to get ever-so-slightly nicer codegen in the
> few dusty old corners which care.
>
> In a contrived benchmark calling hweight64() in a loop, this does indeed
> turn out to be a small win overall, with no measurable impact on
> Cortex-A57 but about 5% performance improvement on Cortex-A53.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* [PULL v8] KVM: arm64: Optimise FPSIMD context switching
From: Dave Martin @ 2018-05-16 10:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Marc,
This is a trivial update to the previously posted v7 [1]. The only
changes are a couple of minor cosmetic changes requested by reviewers,
on-list and the addition of Acked-by/Reviewed-by tags received since the
series was posted.
Let me know if you need anything else on this.
Cheers
---Dave
[1] [PATCH v7 00/16] KVM: arm64: Optimise FPSIMD context switching
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-May/576595.html
The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
are available in the git repository at:
git://linux-arm.org/linux-dm.git
for you to fetch changes up to 90255dd95fe71a9bd1c4ce728abad4b0eec240d9:
KVM: arm64: Invoke FPSIMD context switch trap from C (2018-05-16 10:44:00 +0100)
----------------------------------------------------------------
Christoffer Dall (1):
KVM: arm/arm64: Introduce kvm_arch_vcpu_run_pid_change
Dave Martin (15):
thread_info: Add update_thread_flag() helpers
arm64: Use update{,_tsk}_thread_flag()
KVM: arm64: Convert lazy FPSIMD context switch trap to C
arm64: fpsimd: Generalise context saving for non-task contexts
arm64/sve: Refactor user SVE trap maintenance for external use
KVM: arm64: Repurpose vcpu_arch.debug_flags for general-purpose flags
KVM: arm64: Optimise FPSIMD handling to reduce guest/host thrashing
arm64/sve: Move read_zcr_features() out of cpufeature.h
arm64/sve: Switch sve_pffr() argument from task to thread
arm64/sve: Move sve_pffr() to fpsimd.h and make inline
KVM: arm64: Save host SVE context as appropriate
KVM: arm64: Remove eager host SVE state saving
KVM: arm64: Remove redundant *exit_code changes in fpsimd_guest_exit()
KVM: arm64: Fold redundant exit code checks out of fixup_guest_exit()
KVM: arm64: Invoke FPSIMD context switch trap from C
arch/arm/include/asm/kvm_host.h | 9 ++-
arch/arm64/Kconfig | 7 ++
arch/arm64/include/asm/cpufeature.h | 29 -------
arch/arm64/include/asm/fpsimd.h | 21 ++++++
arch/arm64/include/asm/kvm_asm.h | 3 -
arch/arm64/include/asm/kvm_host.h | 32 +++++---
arch/arm64/include/asm/processor.h | 2 +
arch/arm64/kernel/fpsimd.c | 147 +++++++++++++++++++-----------------
arch/arm64/kernel/ptrace.c | 1 +
arch/arm64/kvm/Kconfig | 1 +
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/debug.c | 8 +-
arch/arm64/kvm/fpsimd.c | 111 +++++++++++++++++++++++++++
arch/arm64/kvm/hyp/debug-sr.c | 6 +-
arch/arm64/kvm/hyp/entry.S | 43 -----------
arch/arm64/kvm/hyp/hyp-entry.S | 19 -----
arch/arm64/kvm/hyp/switch.c | 124 ++++++++++++++++++++----------
arch/arm64/kvm/hyp/sysreg-sr.c | 4 +-
arch/arm64/kvm/sys_regs.c | 9 +--
include/linux/kvm_host.h | 9 +++
include/linux/sched.h | 6 ++
include/linux/thread_info.h | 11 +++
virt/kvm/Kconfig | 3 +
virt/kvm/arm/arm.c | 25 +++++-
virt/kvm/kvm_main.c | 7 +-
25 files changed, 406 insertions(+), 233 deletions(-)
create mode 100644 arch/arm64/kvm/fpsimd.c
^ permalink raw reply
* [PATCH v2] arm64: Remove duplicate include
From: Catalin Marinas @ 2018-05-16 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1523630675-30687-1-git-send-email-vincenzo.frascino@arm.com>
On Fri, Apr 13, 2018 at 03:44:35PM +0100, Vincenzo Frascino wrote:
> "make includecheck" detected few duplicated includes in arch/arm64.
>
> This patch removes the double inclusions.
>
> Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
> ---
> arch/arm64/include/asm/kvm_mmu.h | 1 -
> arch/arm64/kernel/armv8_deprecated.c | 3 +--
> arch/arm64/kernel/fpsimd.c | 1 -
> arch/arm64/kernel/ptrace.c | 2 --
> 4 files changed, 1 insertion(+), 6 deletions(-)
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: remove no-op macro VMLINUX_SYMBOL()
From: Catalin Marinas @ 2018-05-16 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525851986-28631-1-git-send-email-yamada.masahiro@socionext.com>
On Wed, May 09, 2018 at 04:46:26PM +0900, Masahiro Yamada wrote:
> VMLINUX_SYMBOL() is no-op unless CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX
> is defined. It has ever been selected only by BLACKFIN and METAG.
> VMLINUX_SYMBOL() is unneeded for ARM64-specific code.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Queued for 4.18. Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Sekhar Nori @ 2018-05-16 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJUKGS_wm1O+HJBt2yY=BQ4169ka1p0264O-PJFdGj5Fdg@mail.gmail.com>
On Wednesday 16 May 2018 01:17 PM, Bartosz Golaszewski wrote:
> 2018-05-16 0:44 GMT+02:00 Adam Ford <aford173@gmail.com>:
>> On Tue, May 15, 2018 at 4:25 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>> 2018-05-14 2:40 GMT+02:00 Adam Ford <aford173@gmail.com>:
>>>> On Wed, May 9, 2018 at 12:25 PM, David Lechner <david@lechnology.com> wrote:
>>>>> This series converts mach-davinci to use the common clock framework.
>>>>>
>>>>> The series works like this, the first 3 patches fix some issues with the clock
>>>>> drivers that have already been accepted into the mainline kernel.
>>>>>
>>>>> Then, starting with "ARM: davinci: pass clock as parameter to
>>>>> davinci_timer_init()", we get the mach code ready for the switch by adding the
>>>>> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
>>>>> around the legacy clocks so that we can switch easily between the old and the
>>>>> new.
>>>>>
>>>>> "ARM: davinci: switch to common clock framework" actually flips the switch
>>>>> to start using the new clock drivers. Then the next 8 patches remove all
>>>>> of the old clock code.
>>>>>
>>>>> The final four patches add device tree clock support to the one SoC that
>>>>> supports it.
>>>>>
>>>>> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
>>>>> board file).
>>>>>
>>>>
>>>> I am not sure if I did something wrong, but I attempted to build and I
>>>> wasn't able to boot the da850-evm.dtb your repo common-clk-v11,
>>>> however the legacy board file boot was OK.
>>>>
>>>> make davinci_all_defconfig ARCH=arm
>>>> make zImage modules da850-evm.dtb ARCH=arm CROSS_COMPILE=arm-linux- -j8
>>>>
>>>> 3140416 bytes read in 1464 ms (2 MiB/s)
>>>> 20353 bytes read in 15 ms (1.3 MiB/s)
>>>> ## Flattened Device Tree blob at c0600000
>>>> Booting using the fdt blob at 0xc0600000
>>>> Loading Device Tree to c7e57000, end c7e5ef80 ... OK
>>>>
>>>> Starting kernel ...
>>>>
>>>> Uncompressing Linux... done, booting the kernel.
>>>>
>>>> (and hang)
>>>>
>>>> If you have some suggestions, I am try them as I get time.
>>>>
>>>> adam
>>>>
>>>
>>> Runs fine on da850-lcdk and dm365-evm. I'll test the da850-evm
>>> tomorrow when I'll have access to it.
>>
>> I set the bootargs to: bootargs=console=ttyS2,115200n8
>> clk_ignore_unused root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait
>>
>> I enabled DEBUG_LL and EARLY_PRINTK, yet when it loads, I only get:
With DEBUG_LL, you dont get any prints "automatically". You need add
printascii() calls where you need. I use the attached patch which
patches printk() calls with printascii()[1]
>>
>> ## Flattened Device Tree blob at c0600000
>> Booting using the fdt blob at 0xc0600000
>> Loading Device Tree to c7e57000, end c7e5ef35 ... OK
>>
>> Starting kernel ...
>>
>> Uncompressing Linux... done, booting the kernel.
>>
>>
>> I am doing this at my home, so I don't have a debugger for the
>> DA850-EVM. I am using a SOM that is an AM1808, but I vaguely remember
>> something about enabling a DSP clock somewhere, but I cannot seem to
>> find the e-mail. I know its counter intuitive that we'd need to
>> enable a clock that runs the DSP since it doesn't exist on the AM1808,
>> but I would have thought the clk_ignore_unused would have worked
>> around that issue.
>>
>> If someone else has a DA850-EVM or suggestions, I'm willing to try
>> them as I have time.
>>
>> adam
>
> Hi Adam,
>
> everything works fine for me both when booting the DTB and in legacy
> mode on da850-evm.
>
> I'm using the following bootargs:
> ip=dhcp console=ttyS2,115200n8 root=/dev/nfs rw nfsroot=<snip!>,v3
> nfsrootdebug
>
> Regular davinci_all_defconfig on David's common-clk-v11 branch.
Adam, if you still cannot get it to work, one problem could be that the
DT size has increased and its being overwritten. You could look at where
you are loading various binaries. Or append the .dtb to zImage and
switch on APPENDED_DTB config in kernel.
Thanks,
Sekhar
[1]
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 5b5a708..c3419c0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1488,6 +1488,7 @@ static size_t cont_print_text(char *text, size_t size)
return textlen;
}
+void printascii(char *);
asmlinkage int vprintk_emit(int facility, int level,
const char *dict, size_t dictlen,
const char *fmt, va_list args)
@@ -1552,6 +1553,7 @@ asmlinkage int vprintk_emit(int facility, int level,
text_len--;
lflags |= LOG_NEWLINE;
}
+ printascii(text);
/* strip kernel syslog prefix and extract log level or control flags */
if (facility == 0) {
^ permalink raw reply related
* issue with kexec/kdump on imx6ull
From: Russell King - ARM Linux @ 2018-05-16 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516103120.GA17813@arthur-bzh>
On Wed, May 16, 2018 at 12:31:20PM +0200, Arthur LAMBERT wrote:
> Le Monday 09 Apr 2018 ? 15:31:23 (+0100), Russell King - ARM Linux a ?crit :
> >
> > > kernel command line: "console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk maxcpus=1 reset_devices elfcorehdr=0x9b100000 mem=50176K"
> >
> > This is the command line which the target kernel should boot with, but...
> >
> > > [ 0.000000] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw crashkernel=50M
> >
> > it appears that it hasn't, so something is still wrong. Without the
> > right command line, you won't get the vmcore.
>
> Sorry for my very late answer Russell.
>
> We can see that kexec is able to build the correct command line but instead of booting with this kernel
> command line. Kexec boot the target kernel with default kernel command line.
>
> I am currently forcing kernel command line on my target kernel :
>
> CONFIG_CMDLINE="console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk crashkernel=50M"
> # CONFIG_CMDLINE_FROM_BOOTLOADER is not set
> # CONFIG_CMDLINE_EXTEND is not set
> CONFIG_CMDLINE_FORCE=y
I guess it's taken quite a while to track this down.
I wonder if we should encode that into the zImage, and have kexec print
a friendly error or warning message suggesting the kernel be more
appropriately configured.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH] arm64: dts: juno: fix graph node unit addresses for coresight components
From: Sudeep Holla @ 2018-05-16 10:34 UTC (permalink / raw)
To: linux-arm-kernel
Currently the coresight components graph node unit addresses are
continuous for both input and output ports while the "reg" properties
are restarted for input and output ports separately. This results is
the following DTC warnings:
(graph_port): /etf at 20010000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /etf at 20140000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20040000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20040000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 20040000/ports/port at 3: graph node unit address error, expected "2"
(graph_port): /funnel at 20130000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20150000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 20150000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 220c0000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 220c0000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 230c0000/ports/port at 1: graph node unit address error, expected "0"
(graph_port): /funnel at 230c0000/ports/port at 2: graph node unit address error, expected "1"
(graph_port): /funnel at 230c0000/ports/port at 3: graph node unit address error, expected "2"
(graph_port): /funnel at 230c0000/ports/port at 4: graph node unit address error, expected "3"
(graph_port): /replicator at 20120000/ports/port at 2: graph node unit address error, expected "0"
This patch makes even the reg property to follow the continuous
numbering as in the graph node unit address.
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 20 ++++++++++----------
arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 8 ++++----
arch/arm64/boot/dts/arm/juno.dts | 2 +-
3 files changed, 15 insertions(+), 15 deletions(-)
Hi Suzuki/Mathieu,
I did a quick scan @ drivers/hwtracing/coresight/of_coresight.c to check
if reg field is being used or not and whether this change causes any
regression. I don't think so, but I may be wrong, let me know.
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 708a15887af4..dbeca292a57c 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -131,7 +131,7 @@
/* output port */
port at 1 {
- reg = <0>;
+ reg = <1>;
etf0_out_port: endpoint {
};
};
@@ -175,7 +175,7 @@
/* input ports */
port at 1 {
- reg = <0>;
+ reg = <1>;
main_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&cluster0_funnel_out_port>;
@@ -183,7 +183,7 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
main_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&cluster1_funnel_out_port>;
@@ -265,7 +265,7 @@
};
port at 1 {
- reg = <0>;
+ reg = <1>;
cluster0_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&cluster0_etm0_out_port>;
@@ -273,7 +273,7 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
cluster0_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&cluster0_etm1_out_port>;
@@ -347,7 +347,7 @@
};
port at 1 {
- reg = <0>;
+ reg = <1>;
cluster1_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm0_out_port>;
@@ -355,21 +355,21 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
cluster1_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm1_out_port>;
};
};
port at 3 {
- reg = <2>;
+ reg = <3>;
cluster1_funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm2_out_port>;
};
};
port at 4 {
- reg = <3>;
+ reg = <4>;
cluster1_funnel_in_port3: endpoint {
slave-mode;
remote-endpoint = <&cluster1_etm3_out_port>;
@@ -476,7 +476,7 @@
/* replicator input port */
port at 2 {
- reg = <0>;
+ reg = <2>;
replicator_in_port0: endpoint {
slave-mode;
};
diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
index 21287f2d75d3..a99f311c8dcb 100644
--- a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
@@ -21,7 +21,7 @@
/* input port */
port at 1 {
- reg = <0>;
+ reg = <1>;
csys1_funnel_in_port0: endpoint {
slave-mode;
};
@@ -52,7 +52,7 @@
/* output port */
port at 1 {
- reg = <0>;
+ reg = <1>;
etf1_out_port: endpoint {
remote-endpoint = <&csys2_funnel_in_port1>;
};
@@ -81,7 +81,7 @@
/* input ports */
port at 1 {
- reg = <0>;
+ reg = <1>;
csys2_funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&etf0_out_port>;
@@ -89,7 +89,7 @@
};
port at 2 {
- reg = <1>;
+ reg = <2>;
csys2_funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&etf1_out_port>;
diff --git a/arch/arm64/boot/dts/arm/juno.dts b/arch/arm64/boot/dts/arm/juno.dts
index aa3b341a7547..34e940e7465b 100644
--- a/arch/arm64/boot/dts/arm/juno.dts
+++ b/arch/arm64/boot/dts/arm/juno.dts
@@ -260,7 +260,7 @@
&main_funnel {
ports {
port at 3 {
- reg = <2>;
+ reg = <3>;
main_funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&stm_out_port>;
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: KVM: reduce guest fpsimd trap
From: Dave Martin @ 2018-05-16 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4a812440-b5c6-8a11-a89d-0bad0e7d5150@arm.com>
On Wed, May 16, 2018 at 10:25:40AM +0100, Marc Zyngier wrote:
> [+Dave]
>
> Hi Nianyao,
>
> On 16/05/18 10:08, Tangnianyao (ICT) wrote:
> > Add last_fpsimd_trap to notify if guest last exit reason is handling fpsimd. If guest is using fpsimd frequently, save host's fpsimd state and restore guest's fpsimd state and deactive fpsimd trap before returning to guest. It can avoid guest fpsimd trap soon to improve performance.
So, the purpose of this patch is to context switch the FPSIMD state on
initial entry to the guest, instead of enabling the trap and context
switching the FPSIMD state lazily?
And you decide whether to do this or not, based on whether the guest
triggered a lazy FPSIMD switch previously?
> >
> > Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
> > ---
> > arch/arm64/kernel/asm-offsets.c | 1 +
> > arch/arm64/kvm/hyp/entry.S | 5 +++++
> > arch/arm64/kvm/hyp/switch.c | 38 ++++++++++++++++++++++++++++++++++++--
> > include/linux/kvm_host.h | 1 +
> > 4 files changed, 43 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/asm-offsets.c b/arch/arm64/kernel/asm-offsets.c index 5bdda65..35a9c5c 100644
> > --- a/arch/arm64/kernel/asm-offsets.c
> > +++ b/arch/arm64/kernel/asm-offsets.c
> > @@ -136,6 +136,7 @@ int main(void)
> > #ifdef CONFIG_KVM_ARM_HOST
> > DEFINE(VCPU_CONTEXT, offsetof(struct kvm_vcpu, arch.ctxt));
> > DEFINE(VCPU_FAULT_DISR, offsetof(struct kvm_vcpu, arch.fault.disr_el1));
> > + DEFINE(VCPU_LAST_FPSIMD_TRAP, offsetof(struct kvm_vcpu,
> > + last_fpsimd_trap));
> > DEFINE(CPU_GP_REGS, offsetof(struct kvm_cpu_context, gp_regs));
> > DEFINE(CPU_USER_PT_REGS, offsetof(struct kvm_regs, regs));
> > DEFINE(CPU_FP_REGS, offsetof(struct kvm_regs, fp_regs));
> > diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S index e41a161..956e042 100644
> > --- a/arch/arm64/kvm/hyp/entry.S
> > +++ b/arch/arm64/kvm/hyp/entry.S
> > @@ -197,6 +197,11 @@ alternative_endif
> > add x0, x2, #CPU_GP_REG_OFFSET(CPU_FP_REGS)
> > bl __fpsimd_restore_state
> >
> > + // Mark guest using fpsimd now
> > + ldr x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
> > + add x0, x0, #1
Can this overflow?
> > + str x0, [x3, #VCPU_LAST_FPSIMD_TRAP]
> > +
> > // Skip restoring fpexc32 for AArch64 guests
> > mrs x1, hcr_el2
> > tbnz x1, #HCR_RW_SHIFT, 1f
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c index d964523..86eea1b 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -92,7 +92,13 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu)
> >
> > val = read_sysreg(cpacr_el1);
> > val |= CPACR_EL1_TTA;
> > - val &= ~(CPACR_EL1_FPEN | CPACR_EL1_ZEN);
> > + val &= ~CPACR_EL1_ZEN;
> > +
> > + if (vcpu->last_fpsimd_trap)
> > + val |= CPACR_EL1_FPEN;
> > + else
> > + val &= ~CPACR_EL1_FPEN;
> > +
> > write_sysreg(val, cpacr_el1);
> >
> > write_sysreg(kvm_get_hyp_vector(), vbar_el1); @@ -105,7 +111,13 @@ static void __hyp_text __activate_traps_nvhe(struct kvm_vcpu *vcpu)
> > __activate_traps_common(vcpu);
> >
> > val = CPTR_EL2_DEFAULT;
> > - val |= CPTR_EL2_TTA | CPTR_EL2_TFP | CPTR_EL2_TZ;
> > + val |= CPTR_EL2_TTA | CPTR_EL2_TZ;
> > +
> > + if (vcpu->last_fpsimd_trap)
> > + val &= ~CPTR_EL2_TFP;
> > + else
> > + val |= CPTR_EL2_TFP;
> > +
> > write_sysreg(val, cptr_el2);
> > }
> >
> > @@ -406,6 +418,17 @@ int kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
> > __activate_traps(vcpu);
> > __activate_vm(vcpu->kvm);
> >
> > + /*
> > + * If guest last trap to host for handling fpsimd, last_fpsimd_trap
> > + * is set. Restore guest's fpsimd state and deactivate fpsimd trap
> > + * to avoid guest traping soon.
> > + */
> > + if (vcpu->last_fpsimd_trap) {
> > + __fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> > + __fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
> > + vcpu->last_fpsimd_trap = 0;
> > + }
> > +
> > sysreg_restore_guest_state_vhe(guest_ctxt);
> > __debug_switch_to_guest(vcpu);
> >
> > @@ -454,6 +477,17 @@ int __hyp_text __kvm_vcpu_run_nvhe(struct kvm_vcpu *vcpu)
> > __activate_traps(vcpu);
> > __activate_vm(kern_hyp_va(vcpu->kvm));
> >
> > + /*
> > + * If guest last trap to host for handling fpsimd, last_fpsimd_trap
> > + * is set. Restore guest's fpsimd state and deactivate fpsimd trap
> > + * to avoid guest traping soon.
> > + */
> > + if (vcpu->last_fpsimd_trap) {
> > + __fpsimd_save_state(&host_ctxt->gp_regs.fp_regs);
> > + __fpsimd_restore_state(&guest_ctxt->gp_regs.fp_regs);
> > + vcpu->last_fpsimd_trap = 0;
> > + }
> > +
> > __hyp_vgic_restore_state(vcpu);
> > __timer_enable_traps(vcpu);
> >
> > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 6930c63..46bdf0d 100644
> > --- a/include/linux/kvm_host.h
> > +++ b/include/linux/kvm_host.h
> > @@ -274,6 +274,7 @@ struct kvm_vcpu {
> > bool preempted;
> > struct kvm_vcpu_arch arch;
> > struct dentry *debugfs_dentry;
> > + unsigned int last_fpsimd_trap;
> > };
> >
> > static inline int kvm_vcpu_exiting_guest_mode(struct kvm_vcpu *vcpu)
> > --
> > 2.7.4
> >
>
> This doesn't seem to be the 100% correct. I can't see how this works
> when being preempted, for example... I suggest you look at Dave Martin's
> series[1], which does this correctly.
If I've understood correctly, this chooses between eager and lazy
switching, which is addressing a different issue from [1].
In effect, this code is attempting to predict whether the guest will
use FPSIMD before the next exit. If the prediction is correct and the
guest does use FPSIMD, then the overhead of the lazy FPSIMD trap
disappears. This is probably a good thing, though it may increase
interrupt latency a little. However, if the prediction is wrong and
the guest doesn't use FPSIMD before the next exit, then the overhead of
guest entry increases for no benefit, because FPSIMD was switched
unnecessarily.
Do you have any benchmarks or metrics on the accuracy of the
prediction and the overall impact on performance?
The changes in [1] should reduce the number of FPSIMD context switches
overall, so may reduce the benefit of this patch.
Cheers
---Dave
^ permalink raw reply
* issue with kexec/kdump on imx6ull
From: Arthur LAMBERT @ 2018-05-16 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180409143123.GA4251@n2100.armlinux.org.uk>
Le Monday 09 Apr 2018 ? 15:31:23 (+0100), Russell King - ARM Linux a ?crit :
>
> > kernel command line: "console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk maxcpus=1 reset_devices elfcorehdr=0x9b100000 mem=50176K"
>
> This is the command line which the target kernel should boot with, but...
>
> > [ 0.000000] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw crashkernel=50M
>
> it appears that it hasn't, so something is still wrong. Without the
> right command line, you won't get the vmcore.
Sorry for my very late answer Russell.
We can see that kexec is able to build the correct command line but instead of booting with this kernel
command line. Kexec boot the target kernel with default kernel command line.
I am currently forcing kernel command line on my target kernel :
CONFIG_CMDLINE="console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk crashkernel=50M"
# CONFIG_CMDLINE_FROM_BOOTLOADER is not set
# CONFIG_CMDLINE_EXTEND is not set
CONFIG_CMDLINE_FORCE=y
By just using extend bootlader command line, it seems to be better :
CONFIG_CMDLINE="bazinga"
# CONFIG_CMDLINE_FROM_BOOTLOADER is not set
CONFIG_CMDLINE_EXTEND=y
# CONFIG_CMDLINE_FORCE is not set
New result :
[ 117.998829] Loading crashdump kernel...
[ 118.002830] Bye!
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.16.0-rc7KEXEC (arthur at arthur-bzh) (gcc version 5.4.0 (Buildroot 2017.05-git-38202-gb94bcd1-dirty)) #9 SMP Tue May 15 15:50:55 CEST 2018
[ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Freescale i.MX6 UlltraLite 14x14 EVK Board
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x98000000
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Failed to reserve 64 MiB
[ 0.000000] random: fast init done
[ 0.000000] percpu: Embedded 16 pages/cpu @(ptrval) s36136 r8192 d21208 u65536
[ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 12446
[ 0.000000] Kernel command line: console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk elfcorehdr=0x9b100000 mem=50176K bazinga
(...)
# cat /proc/cmdline
console=ttymxc0,115200 root=/dev/mmcblk1p2 rootwait rw earlyprintk elfcorehdr=0x9b100000 mem=50176K bazinga
# ls -l /proc/vmcore
-r-------- 1 root root 484450304 Jan 1 00:07 /proc/vmcore
Now I just need to compare behavior between kernel mainline and nxp bsp to understand and fix the kernel freeze
issue with the bsp. At least now I have a working setup. I will try to find some time to work on that
next week.
Do you have a reliable method to analyze vmcore from ARM architecture ?
On your first message you wrote :
>> There's also a ti-keystone2 branch which contains an additional
>> (hacky and untested) patch which allows reading the coredump
>> generated by kexec on a crash.
Thanks for your help !
^ permalink raw reply
* [PATCH v3 20/26] drm/mediatek: hdmi: provide an owner .odev device for the bridge
From: Philipp Zabel @ 2018-05-16 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-21-peda@axentia.se>
On Wed, 2018-05-16 at 12:15 +0200, Peter Rosin wrote:
> The .of_node member is going away.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> index 59a11026dceb..d8c7d93d0a87 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> @@ -1694,8 +1694,8 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
>
> mtk_hdmi_register_audio_driver(dev);
>
> + hdmi->bridge.odev = &pdev->dev;
> hdmi->bridge.funcs = &mtk_hdmi_bridge_funcs;
> - hdmi->bridge.of_node = pdev->dev.of_node;
> drm_bridge_add(&hdmi->bridge);
>
> ret = mtk_hdmi_clk_enable_audio(hdmi);
^ permalink raw reply
* [GIT PULL ++] Immutable branch between MFD and PWM due for the v4.18 merge window (v2)
From: Lee Jones @ 2018-05-16 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516081910.GF5130@dell>
Subsequent pull-request containing additional bindings patch.
Enjoy!
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-pwm-v4.18-1
for you to fetch changes up to acc8e22f5d41558c90519aadc011b6d2839aedfe:
dt-bindings: mfd: stm32-timers: Add support for dmas (2018-05-16 11:13:13 +0100)
----------------------------------------------------------------
Immutable branch between MFD and PWM due for the v4.18 merge window (v2)
----------------------------------------------------------------
Fabrice Gasnier (5):
mfd: stm32-timers: Add support for DMAs
pwm: stm32: Add capture support
pwm: stm32: Improve capture by tuning counter prescaler
pwm: stm32: Use input prescaler to improve period capture
dt-bindings: mfd: stm32-timers: Add support for dmas
Documentation/devicetree/bindings/mfd/stm32-timers.txt | 20 ++++
drivers/mfd/stm32-timers.c | 201 +++++++++++++++++++++++++++++++-
drivers/pwm/pwm-stm32.c | 257 +++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/stm32-timers.h | 58 ++++++++++
4 files changed, 534 insertions(+), 2 deletions(-)
--
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v3 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
If the bridge supplier is unbound, this will bring the bridge consumer
down along with the bridge. Thus, there will no longer linger any
dangling pointers from the bridge consumer (the drm_device) to some
non-existent bridge supplier.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
include/drm/drm_bridge.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 78d186b6831b..0259f0a3ff27 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -26,6 +26,7 @@
#include <linux/mutex.h>
#include <drm/drm_bridge.h>
+#include <drm/drm_device.h>
#include <drm/drm_encoder.h>
#include "drm_crtc_internal.h"
@@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
if (bridge->dev)
return -EBUSY;
+ if (encoder->dev->dev != bridge->odev) {
+ bridge->link = device_link_add(encoder->dev->dev,
+ bridge->odev, 0);
+ if (!bridge->link) {
+ dev_err(bridge->odev, "failed to link bridge to %s\n",
+ dev_name(encoder->dev->dev));
+ return -EINVAL;
+ }
+ }
+
bridge->dev = encoder->dev;
bridge->encoder = encoder;
if (bridge->funcs->attach) {
ret = bridge->funcs->attach(bridge);
if (ret < 0) {
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
bridge->dev = NULL;
bridge->encoder = NULL;
return ret;
@@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
if (bridge->funcs->detach)
bridge->funcs->detach(bridge);
+ if (bridge->link)
+ device_link_del(bridge->link);
+ bridge->link = NULL;
+
bridge->dev = NULL;
}
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index b656e505d11e..bd1265c5a0bc 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -261,6 +261,7 @@ struct drm_bridge_timings {
* @list: to keep track of all added bridges
* @timings: the timing specification for the bridge, if any (may
* be NULL)
+ * @link: device link between the drm consumer and the bridge supplier
* @funcs: control functions
* @driver_private: pointer to the bridge driver's internal context
*/
@@ -271,6 +272,7 @@ struct drm_bridge {
struct drm_bridge *next;
struct list_head list;
const struct drm_bridge_timings *timings;
+ struct device_link *link;
const struct drm_bridge_funcs *funcs;
void *driver_private;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
The .odev owner device will be handy to have around.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index df084db33494..78d186b6831b 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -70,6 +70,9 @@ static LIST_HEAD(bridge_list);
*/
void drm_bridge_add(struct drm_bridge *bridge)
{
+ if (WARN_ON(!bridge->odev))
+ return;
+
mutex_lock(&bridge_lock);
list_add_tail(&bridge->list, &bridge_list);
mutex_unlock(&bridge_lock);
@@ -115,6 +118,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
if (!encoder || !bridge)
return -EINVAL;
+ if (WARN_ON(!bridge->odev))
+ return -EINVAL;
+
if (previous && (!previous->dev || previous->encoder != encoder))
return -EINVAL;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 24/26] drm/bridge: remove the .of_node member
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
It is unused.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 3 +--
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
include/drm/drm_bridge.h | 4 ----
3 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 3872f5379998..df084db33494 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,8 +365,7 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
mutex_lock(&bridge_lock);
list_for_each_entry(bridge, &bridge_list, list) {
- if ((bridge->odev && bridge->odev->of_node == np) ||
- bridge->of_node == np) {
+ if (bridge->odev->of_node == np) {
mutex_unlock(&bridge_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 557e0079c98d..e77d4c909582 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
- else if (lvds->bridge->of_node)
- remote = lvds->bridge->of_node;
else
remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", &name))
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 7c17977c3537..b656e505d11e 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -258,7 +258,6 @@ struct drm_bridge_timings {
* @dev: DRM device this bridge belongs to
* @encoder: encoder to which this bridge is connected
* @next: the next bridge in the encoder chain
- * @of_node: device node pointer to the bridge
* @list: to keep track of all added bridges
* @timings: the timing specification for the bridge, if any (may
* be NULL)
@@ -270,9 +269,6 @@ struct drm_bridge {
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
-#ifdef CONFIG_OF
- struct device_node *of_node;
-#endif
struct list_head list;
const struct drm_bridge_timings *timings;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 20/26] drm/mediatek: hdmi: provide an owner .odev device for the bridge
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
The .of_node member is going away.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 59a11026dceb..d8c7d93d0a87 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1694,8 +1694,8 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
mtk_hdmi_register_audio_driver(dev);
+ hdmi->bridge.odev = &pdev->dev;
hdmi->bridge.funcs = &mtk_hdmi_bridge_funcs;
- hdmi->bridge.of_node = pdev->dev.of_node;
drm_bridge_add(&hdmi->bridge);
ret = mtk_hdmi_clk_enable_audio(hdmi);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 19/26] drm/exynos: mic: provide an owner .odev device for the bridge
From: Peter Rosin @ 2018-05-16 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
The .of_node member is going away.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 2174814273e2..f9ff8d3ec937 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -417,8 +417,8 @@ static int exynos_mic_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, mic);
+ mic->bridge.odev = dev;
mic->bridge.funcs = &mic_bridge_funcs;
- mic->bridge.of_node = dev->of_node;
drm_bridge_add(&mic->bridge);
--
2.11.0
^ permalink raw reply related
* [PATCH v3 01/26] drm/bridge: allow optionally specifying an owner .odev device
From: Peter Rosin @ 2018-05-16 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516101510.13215-1-peda@axentia.se>
Bridge drivers can now (temporarily, in a transition phase) select if
they want to provide a full owner device or keep just providing an
of_node.
By providing a full owner device, the bridge drivers no longer need
to provide an of_node since that node is available via the owner
device.
When all bridge drivers provide an owner device, that will become
mandatory and the .of_node member will be removed.
There is an interaction with the rockchip lvds driver, since that
driver peeks into somewhat private parts of the bridge struct in
order to find out things about the remote bridge. When there are
now two ways to get to the remote bridge, the rockchip lvds driver
has to adapt. That said, the correct thing to do for the rockchip
lvds driver is to use some other way than DT to find things out
about the remote bridge, but that is orthogonal to this patch.
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/drm_bridge.c | 3 ++-
drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
include/drm/drm_bridge.h | 2 ++
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 1638bfe9627c..3872f5379998 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -365,7 +365,8 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
mutex_lock(&bridge_lock);
list_for_each_entry(bridge, &bridge_list, list) {
- if (bridge->of_node == np) {
+ if ((bridge->odev && bridge->odev->of_node == np) ||
+ bridge->of_node == np) {
mutex_unlock(&bridge_lock);
return bridge;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 4bd94b167d2c..557e0079c98d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -377,8 +377,10 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
}
if (lvds->panel)
remote = lvds->panel->dev->of_node;
- else
+ else if (lvds->bridge->of_node)
remote = lvds->bridge->of_node;
+ else
+ remote = lvds->bridge->odev->of_node;
if (of_property_read_string(dev->of_node, "rockchip,output", &name))
/* default set it as output rgb */
lvds->output = DISPLAY_OUTPUT_RGB;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3270fec46979..7c17977c3537 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -254,6 +254,7 @@ struct drm_bridge_timings {
/**
* struct drm_bridge - central DRM bridge control structure
+ * @odev: device that owns the bridge
* @dev: DRM device this bridge belongs to
* @encoder: encoder to which this bridge is connected
* @next: the next bridge in the encoder chain
@@ -265,6 +266,7 @@ struct drm_bridge_timings {
* @driver_private: pointer to the bridge driver's internal context
*/
struct drm_bridge {
+ struct device *odev;
struct drm_device *dev;
struct drm_encoder *encoder;
struct drm_bridge *next;
--
2.11.0
^ permalink raw reply related
* [PATCH v3 00/26] device link, bridge supplier <-> drm device
From: Peter Rosin @ 2018-05-16 10:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
It was noted by Russell King [1] that bridges (not using components)
might disappear unexpectedly if the owner of the bridge was unbound.
Jyri Sarha had previously noted the same thing with panels [2]. Jyri
came up with using device links to resolve the panel issue, which
was also my (independent) reaction to the note from Russell.
This series builds up to the addition of that link in the last
patch, but in my opinion the other 25 patches do have merit on their
own.
The last patch needs testing, while the others look trivial. Jyri, are
you able to test? That said, I might have missed some subtlety.
Oh, and the reason I'm pushing this is of course so that the issue
noted by Russell in [1] is addressed which in turn means that the
tda998x bridge driver can be patched according to that series without
objection (hopefully) and then used from the atmel-hlcdc driver (and
other drivers that are not componentized).
Changes since v2 https://lkml.org/lkml/2018/5/4/443
- Russell King spells his name this way. Sorry!
- Add review tag from Andrzej Hajda (patches 1, 25 and 26).
- Add ack tag from Daniel Vetter (patches 1, 24, 25 and 26).
- Mention the interaction with the rockchip_lvds driver in the
commit message for patch 1.
- Change the comment for the new @link member in patch 26, so that a
symmetric relationchip between cunsumer/supplier isn't implied.
Changes since v1 https://lkml.org/lkml/2018/4/26/1018
- rename .owner to .odev to not get mixed up with the module owner.
- added patches for new recent drivers thc63lvd1024 and cdns-dsi
- fix for problem in the rockchip_lvds driver reported by 0day
- added a WARN in drm_bridge_add if there is no .odev owner device
Cheers,
Peter
[1] https://lkml.org/lkml/2018/4/23/769
[2] https://www.spinics.net/lists/dri-devel/msg174275.html
Peter Rosin (26):
drm/bridge: allow optionally specifying an owner .odev device
drm/bridge: adv7511: provide an owner .odev device
drm/bridge/analogix: core: specify the owner .odev of the bridge
drm/bridge: analogix-anx78xx: provide an owner .odev device
drm/bridge: cdns-dsi: provide an owner .odev device
drm/bridge: vga-dac: provide an owner .odev device
drm/bridge: lvds-encoder: provide an owner .odev device
drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: provide an owner .odev
device
drm/bridge: nxp-ptn3460: provide an owner .odev device
drm/bridge: panel: provide an owner .odev device
drm/bridge: ps8622: provide an owner .odev device
drm/bridge: sii902x: provide an owner .odev device
drm/bridge: sii9234: provide an owner .odev device
drm/bridge: sii8620: provide an owner .odev device
drm/bridge: synopsys: provide an owner .odev device for the bridges
drm/bridge: tc358767: provide an owner .odev device
drm/bridge: thc63lvd1024: provide an owner .odev device
drm/bridge: ti-tfp410: provide an owner .odev device
drm/exynos: mic: provide an owner .odev device for the bridge
drm/mediatek: hdmi: provide an owner .odev device for the bridge
drm/msm: specify the owner .odev of the bridges
drm/rcar-du: lvds: provide an owner .odev device for the bridge
drm/sti: provide an owner .odev device for the bridges
drm/bridge: remove the .of_node member
drm/bridge: require the owner .odev to be filled in on
drm_bridge_add/attach
drm/bridge: establish a link between the bridge supplier and consumer
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 2 +-
drivers/gpu/drm/bridge/analogix-anx78xx.c | 5 +----
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
drivers/gpu/drm/bridge/cdns-dsi.c | 2 +-
drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +-
drivers/gpu/drm/bridge/lvds-encoder.c | 2 +-
.../drm/bridge/megachips-stdpxxxx-ge-b850v3-fw.c | 2 +-
drivers/gpu/drm/bridge/nxp-ptn3460.c | 2 +-
drivers/gpu/drm/bridge/panel.c | 4 +---
drivers/gpu/drm/bridge/parade-ps8622.c | 2 +-
drivers/gpu/drm/bridge/sii902x.c | 2 +-
drivers/gpu/drm/bridge/sii9234.c | 2 +-
drivers/gpu/drm/bridge/sil-sii8620.c | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 4 +---
drivers/gpu/drm/bridge/tc358767.c | 2 +-
drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +-
drivers/gpu/drm/bridge/ti-tfp410.c | 2 +-
drivers/gpu/drm/drm_bridge.c | 26 +++++++++++++++++++++-
drivers/gpu/drm/exynos/exynos_drm_mic.c | 2 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
drivers/gpu/drm/msm/dsi/dsi_manager.c | 1 +
drivers/gpu/drm/msm/edp/edp_bridge.c | 1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 1 +
drivers/gpu/drm/rcar-du/rcar_lvds.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +-
drivers/gpu/drm/sti/sti_dvo.c | 2 +-
drivers/gpu/drm/sti/sti_hda.c | 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 1 +
include/drm/drm_bridge.h | 8 +++----
30 files changed, 57 insertions(+), 36 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH 2/4] ARM: davinci: board-da850-evm: fix GPIO lookup for MMC/SD
From: Sekhar Nori @ 2018-05-16 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7x+eNpeyv27WPqZyy-X9S7Ffvujo+y3Mmt1ZP=LEk+4+=g@mail.gmail.com>
On Wednesday 16 May 2018 04:23 AM, Adam Ford wrote:
> On Thu, Apr 26, 2018 at 8:40 PM, David Lechner <david@lechnology.com> wrote:
>> On 04/24/2018 09:35 AM, Sekhar Nori wrote:
>>>
>>> The GPIO chip is called davinci_gpio.0 in legacy mode. Fix it, so that
>>> mmc can correctly lookup the wp and cp gpios. Also fix the GPIO numbers
>>> as they are not offsets within a bank.
>>>
>>> Note that it is the gpio-davinci driver that sets the gpiochip label to
>>> davinci_gpio.0.
>>>
>>> Fixes: bdf0e8364fd3 ("ARM: davinci: da850-evm: use gpio descriptor for mmc
>>> pins")
>>> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
>>> ---
>>> arch/arm/mach-davinci/board-da850-evm.c | 9 +++++++--
>>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
>>> b/arch/arm/mach-davinci/board-da850-evm.c
>>> index 3063478bcc36..158ed9a1483f 100644
>>> --- a/arch/arm/mach-davinci/board-da850-evm.c
>>> +++ b/arch/arm/mach-davinci/board-da850-evm.c
>>> @@ -763,12 +763,17 @@ static const short da850_evm_mcasp_pins[]
>>> __initconst = {
>>> -1
>>> };
>>> +#define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
>>> +#define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1)
>>> +
>>> static struct gpiod_lookup_table mmc_gpios_table = {
>>> .dev_id = "da830-mmc.0",
>>> .table = {
>>> /* gpio chip 2 contains gpio range 64-95 */
>>> - GPIO_LOOKUP("davinci_gpio.2", 0, "cd", GPIO_ACTIVE_LOW),
>>> - GPIO_LOOKUP("davinci_gpio.2", 1, "wp", GPIO_ACTIVE_LOW),
>>> + GPIO_LOOKUP("davinci_gpio.0", DA850_MMCSD_CD_PIN, "cd",
>>> + GPIO_ACTIVE_LOW),
>>> + GPIO_LOOKUP("davinci_gpio.0", DA850_MMCSD_WP_PIN, "wp",
>>> + GPIO_ACTIVE_LOW),
>
> I don't think the WP polarity is working correctly. If I boot the
> board 'rw' enabled but WP disabled on the SD card, the system crashes.
> If I enable WP, the board boots correctly.
>
> Comparing this to the device tree version that I did, and double
> checking the behavior for my sanity, I believe WP needs to be
> GPIO_ACTIVE_HIGH
You are right, I see the issue on my board too. Although this patch did
not touch the polarity, we could have fixed it here.
Anyway, do you want to send a patch for that? Or I can do it too. A
similar fix is needed for DA830 EVM too.
Thanks,
Sekhar
^ permalink raw reply
* [RESEND PATCH v5 0/6] Add support for PWM input capture on STM32
From: Lee Jones @ 2018-05-16 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c48acc96-1eca-9adc-abb7-131921305ee8@st.com>
On Wed, 16 May 2018, Fabrice Gasnier wrote:
> On 05/16/2018 10:06 AM, Lee Jones wrote:
> > On Wed, 16 May 2018, Fabrice Gasnier wrote:
> >
> >> This series adds support for capture to stm32-pwm driver.
> >> Capture is based on DMAs.
> >> - First two patches add support for requesting DMAs to MFD core
> >> - Next three patches add support for capture to stm32-pwm driver
> >> - This has been tested on stm32429i-eval board.
> >>
> >> ---
> >> Changes in v5:
> >> - update patch 2 (mfd: stm32-timers: add support for dmas)
> >> move stm32_timers_dma struct to header file,
> >> fix warning on dma_mapping_error().
> >>
> >> Changes in v4:
> >> - Lee's comments on patch 2 (mfd: stm32-timers: add support for dmas)
> >> Add kerneldoc header, better format comments.
> >>
> >> Changes in v3:
> >> - Dropped 2 precusor patches applied by Thierry in pwm tree:
> >> "pwm: stm32: fix, remove unused struct device"
> >> "pwm: stm32: protect common prescaler for all channels"
> >> - Note: this series applies on top on pwm tree
> >> - Implements Lee's comments on MFD part: rework stm32_timers_dma struct,
> >> exported routine prototype now use generic device struct, more
> >> various comments (see patch 2 changelog).
> >>
> >> Resend v2:
> >> - Add collected Acks
> >>
> >> Changes in v2:
> >> - Abstract DMA handling from child driver: move it to MFD core
> >> - Rework pwm capture routines to adopt this change
> >> - Comment on optional dma support, beautify DMAs probe
> >>
> >> Fabrice Gasnier (6):
> >> dt-bindings: mfd: stm32-timers: add support for dmas
> >> mfd: stm32-timers: add support for dmas
> >> pwm: stm32: add capture support
> >> pwm: stm32: improve capture by tuning counter prescaler
> >> pwm: stm32: use input prescaler to improve period capture
> >> ARM: dts: stm32: Enable pwm3 input capture on stm32f429i-eval
> >
> > Applied patches 1-5.
>
> Many thanks Lee !
>
> Maybe I missed something, but just in case...
> In your pull request ("[GIT PULL] Immutable branch between MFD and PWM
> due for the v4.18 merge window") I only see 4 patches:
> Fabrice Gasnier (4):
> mfd: stm32-timers: Add support for DMAs
> pwm: stm32: Add capture support
> pwm: stm32: Improve capture by tuning counter prescaler
> pwm: stm32: Use input prescaler to improve period capture
>
> I can't see patch 1 ("dt-bindings: mfd: stm32-timers: add support for dmas")
> Is it applied on another tree ?
Good spot.
Looks like a fumbled the key combination for the bindings patch.
Pull-request to follow.
> >> .../devicetree/bindings/mfd/stm32-timers.txt | 20 ++
> >> arch/arm/boot/dts/stm32429i-eval.dts | 3 +
> >> drivers/mfd/stm32-timers.c | 201 +++++++++++++++-
> >> drivers/pwm/pwm-stm32.c | 257 +++++++++++++++++++++
> >> include/linux/mfd/stm32-timers.h | 58 +++++
> >> 5 files changed, 537 insertions(+), 2 deletions(-)
> >>
> >
--
Lee Jones [???]
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v9 07/11] arm64: kexec_file: add crash dump support
From: James Morse @ 2018-05-16 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f8d8305d-42f5-e1e2-20c4-733cb38cbb8d@arm.com>
Hi Akashi,
On 15/05/18 18:11, James Morse wrote:
> On 25/04/18 07:26, AKASHI Takahiro wrote:
>> Enabling crash dump (kdump) includes
>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>> using crash_prepare_elf64_headers(), and
>> * add two device tree properties, "linux,usable-memory-range" and
>> "linux,elfcorehdr", which represent repsectively a memory range
>> to be used by crash dump kernel and the header's location
>> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
>> index 37c0a9dc2e47..ec674f4d267c 100644
>> --- a/arch/arm64/kernel/machine_kexec_file.c
>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>> +static struct crash_mem *get_crash_memory_ranges(void)
>> +{
>> + unsigned int nr_ranges;
>> + struct crash_mem *cmem;
>> +
>> + nr_ranges = 1; /* for exclusion of crashkernel region */
>> + walk_system_ram_res(0, -1, &nr_ranges, get_nr_ranges_callback);
>> +
>> + cmem = vmalloc(sizeof(struct crash_mem) +
>> + sizeof(struct crash_mem_range) * nr_ranges);
>> + if (!cmem)
>> + return NULL;
>> +
>> + cmem->max_nr_ranges = nr_ranges;
>> + cmem->nr_ranges = 0;
>> + walk_system_ram_res(0, -1, cmem, add_mem_range_callback);
>> +
>> + /* Exclude crashkernel region */
>> + if (crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end)) {
>> + vfree(cmem);
>> + return NULL;
>> + }
>> +
>> + return cmem;
>> +}
>
> Could this function be included in prepare_elf_headers() so that the alloc() and
> free() occur together.
>
>
>> +static int prepare_elf_headers(void **addr, unsigned long *sz)
>> +{
>> + struct crash_mem *cmem;
>> + int ret = 0;
>> +
>> + cmem = get_crash_memory_ranges();
>> + if (!cmem)
>> + return -ENOMEM;
>> +
>> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> +
>> + vfree(cmem);
>
>> + return ret;
>> +}
>
> All this is moving memory-range information from core-code's
> walk_system_ram_res() into core-code's struct crash_mem, and excluding
> crashk_res, which again is accessible to the core code.
>
> It looks like this is duplicated in arch/x86 and arch/arm64 because arm64
> doesn't have a second 'crashk_low_res' region, and always wants elf64, instead
> of when IS_ENABLED(CONFIG_X86_64).
Thinking about it some more: don't we want to walk memblock here, not
walk_system_ram_res()? What we want is a list of not-nomap regions that the
kernel may have been using, to form part of vmcore.
walk_system_ram_res() is becoming a murkier list of maybe-nomap, maybe-reserved.
I think we should walk the same list here as we do in patch 4.
Thanks,
James
^ permalink raw reply
* [PATCH 10/14] vgem: separate errno from VM_FAULT_* values
From: Daniel Vetter @ 2018-05-16 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180516054348.15950-11-hch@lst.de>
On Wed, May 16, 2018 at 07:43:44AM +0200, Christoph Hellwig wrote:
> And streamline the code in vgem_fault with early returns so that it is
> a little bit more readable.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 51 +++++++++++++++------------------
> 1 file changed, 23 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 2524ff116f00..a261e0aab83a 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -61,12 +61,13 @@ static void vgem_gem_free_object(struct drm_gem_object *obj)
> kfree(vgem_obj);
> }
>
> -static int vgem_gem_fault(struct vm_fault *vmf)
> +static vm_fault_t vgem_gem_fault(struct vm_fault *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct drm_vgem_gem_object *obj = vma->vm_private_data;
> /* We don't use vmf->pgoff since that has the fake offset */
> unsigned long vaddr = vmf->address;
> + struct page *page;
> int ret;
> loff_t num_pages;
> pgoff_t page_offset;
> @@ -85,35 +86,29 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> ret = 0;
> }
> mutex_unlock(&obj->pages_lock);
> - if (ret) {
> - struct page *page;
> -
> - page = shmem_read_mapping_page(
> - file_inode(obj->base.filp)->i_mapping,
> - page_offset);
> - if (!IS_ERR(page)) {
> - vmf->page = page;
> - ret = 0;
> - } else switch (PTR_ERR(page)) {
> - case -ENOSPC:
> - case -ENOMEM:
> - ret = VM_FAULT_OOM;
> - break;
> - case -EBUSY:
> - ret = VM_FAULT_RETRY;
> - break;
> - case -EFAULT:
> - case -EINVAL:
> - ret = VM_FAULT_SIGBUS;
> - break;
> - default:
> - WARN_ON(PTR_ERR(page));
> - ret = VM_FAULT_SIGBUS;
> - break;
> - }
> + if (!ret)
> + return 0;
> +
> + page = shmem_read_mapping_page(file_inode(obj->base.filp)->i_mapping,
> + page_offset);
> + if (!IS_ERR(page)) {
> + vmf->page = page;
> + return 0;
> + }
>
> + switch (PTR_ERR(page)) {
> + case -ENOSPC:
> + case -ENOMEM:
> + return VM_FAULT_OOM;
> + case -EBUSY:
> + return VM_FAULT_RETRY;
> + case -EFAULT:
> + case -EINVAL:
> + return VM_FAULT_SIGBUS;
> + default:
> + WARN_ON(PTR_ERR(page));
> + return VM_FAULT_SIGBUS;
> }
> - return ret;
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Want me to merge this through drm-misc or plan to pick it up yourself?
-Daniel
> }
>
> static const struct vm_operations_struct vgem_gem_vm_ops = {
> --
> 2.17.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] arm64: dts: move berlin SoC files from marvell dir to synaptics dir
From: Jisheng Zhang @ 2018-05-16 9:51 UTC (permalink / raw)
To: linux-arm-kernel
Move device tree files as part of transition from Marvell berlin to
Synaptics berlin.
Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
---
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/marvell/Makefile | 4 ----
arch/arm64/boot/dts/synaptics/Makefile | 4 ++++
arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts | 0
arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts | 0
arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi | 0
6 files changed, 5 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/synaptics/Makefile
rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts (100%)
rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts (100%)
rename arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi (100%)
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 4aa50b9b26bc..3543bc324553 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -22,5 +22,6 @@ subdir-y += renesas
subdir-y += rockchip
subdir-y += socionext
subdir-y += sprd
+subdir-y += synaptics
subdir-y += xilinx
subdir-y += zte
diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index cb454beede55..ea9d49f2a911 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -1,8 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-# Berlin SoC Family
-dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
-dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
-
# Mvebu SoC Family
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
diff --git a/arch/arm64/boot/dts/synaptics/Makefile b/arch/arm64/boot/dts/synaptics/Makefile
new file mode 100644
index 000000000000..de71ddda6835
--- /dev/null
+++ b/arch/arm64/boot/dts/synaptics/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+# Berlin SoC Family
+dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-dmp.dtb
+dtb-$(CONFIG_ARCH_BERLIN) += berlin4ct-stb.dtb
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts b/arch/arm64/boot/dts/synaptics/berlin4ct-dmp.dts
similarity index 100%
rename from arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts
rename to arch/arm64/boot/dts/synaptics/berlin4ct-dmp.dts
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct-stb.dts b/arch/arm64/boot/dts/synaptics/berlin4ct-stb.dts
similarity index 100%
rename from arch/arm64/boot/dts/marvell/berlin4ct-stb.dts
rename to arch/arm64/boot/dts/synaptics/berlin4ct-stb.dts
diff --git a/arch/arm64/boot/dts/marvell/berlin4ct.dtsi b/arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/marvell/berlin4ct.dtsi
rename to arch/arm64/boot/dts/synaptics/berlin4ct.dtsi
--
2.17.0
^ 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