* [v3, 00/10] Support DPAA PTP clock and timestamping
From: Y.b. Lu @ 2018-06-08 4:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180608042706.7gfg5p6574ntc2lq@localhost>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: Friday, June 8, 2018 12:27 PM
> To: Y.b. Lu <yangbo.lu@nxp.com>
> Cc: netdev at vger.kernel.org; Madalin-cristian Bucur
> <madalin.bucur@nxp.com>; Rob Herring <robh+dt@kernel.org>; Shawn Guo
> <shawnguo@kernel.org>; David S . Miller <davem@davemloft.net>;
> devicetree at vger.kernel.org; linuxppc-dev at lists.ozlabs.org;
> linux-arm-kernel at lists.infradead.org; linux-kernel at vger.kernel.org
> Subject: Re: [v3, 00/10] Support DPAA PTP clock and timestamping
>
> On Thu, Jun 07, 2018 at 05:20:40PM +0800, Yangbo Lu wrote:
> > This patchset is to support DPAA FMAN PTP clock and HW timestamping.
> > It had been verified on both ARM platform and PPC platform.
> > - The patch #1 to patch #5 are to support DPAA FMAN 1588 timer in
> > ptp_qoriq driver.
> > - The patch #6 to patch #10 are to add HW timestamping support in
> > DPAA ethernet driver.
>
> Right now, net-next is closed for new stuff. You will have to post the series
> again after the merge window closes. You can check the status here:
>
>
> https://emea01.safelinks.protection.outlook.com/?url=http:%2F%2Fvger.kern
> el.org%2F~davem%2Fnet-next.html&data=02%7C01%7Cyangbo.lu%40nxp.co
> m%7Cbaab0b22e7444386c37008d5ccf81b37%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C0%7C636640288347563742&sdata=jCmNlwoeWA50PV4
> w3lKZ%2Fs4akPjw0VV2OrJ3t4FizJ0%3D&reserved=0
>
> When you do re-post, you can add my:
>
> Acked-by: Richard Cochran <richardcochran@gmail.com>
[Y.b. Lu] Get it. And thanks a lot ?
^ permalink raw reply
* [v3, 00/10] Support DPAA PTP clock and timestamping
From: Richard Cochran @ 2018-06-08 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607092050.46128-1-yangbo.lu@nxp.com>
On Thu, Jun 07, 2018 at 05:20:40PM +0800, Yangbo Lu wrote:
> This patchset is to support DPAA FMAN PTP clock and HW timestamping.
> It had been verified on both ARM platform and PPC platform.
> - The patch #1 to patch #5 are to support DPAA FMAN 1588 timer in
> ptp_qoriq driver.
> - The patch #6 to patch #10 are to add HW timestamping support in
> DPAA ethernet driver.
Right now, net-next is closed for new stuff. You will have to post
the series again after the merge window closes. You can check the
status here:
http://vger.kernel.org/~davem/net-next.html
When you do re-post, you can add my:
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
From: Sascha Hauer @ 2018-06-08 4:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM0PR04MB42119006042C993F410D6CB080640@AM0PR04MB4211.eurprd04.prod.outlook.com>
On Thu, Jun 07, 2018 at 01:59:26PM +0000, A.s. Dong wrote:
> Hi Sascha,
>
> > -----Original Message-----
> > From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
> > Sent: Thursday, June 7, 2018 3:09 PM
> > To: A.s. Dong <aisheng.dong@nxp.com>
> > Cc: dongas86 at gmail.com; dl-linux-imx <linux-imx@nxp.com>;
> > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH 4/4] soc: imx: add SC firmware IPC and APIs
> >
> > On Thu, Jun 07, 2018 at 04:18:54AM +0000, A.s. Dong wrote:
> > > Hi Sascha,
> > >
> > > > > One problem of the way you suggested may be that:
> > > > > If we doing like below, we may lose flexibility to change the MU
> > > > > used for SCU firmware communication.
> > > > > scu at 5d1b0000 {
> > > > > compatible = "fsl,imx8qxp-scu";
> > > > > reg = <0x0 0x5d1b0000 0x0 0x10000>;
> > > > > };
> > > > >
> > > > > And current design is that the system supports multiple MU
> > > > > channels used by various users at the same time, e.g. SCU, Power
> > > > > Domain, Clock and
> > > > others.
> > > > > User can flexibly change it under their nodes: And each MU channel
> > > > > is protected by their private lock and not affect each others.
> > > > >
> > > > > e.g.
> > > > > scu {
> > > > > compatible = "nxp,imx8qxp-scu", "simple-bus";
> > > > > fsl,mu = <&lsio_mu0>;
> > > > >
> > > > > clk: clk {
> > > > > compatible = "fsl,imx8qxp-clk";
> > > > > #clock-cells = <1>;
> > > > > };
> > > > >
> > > > > iomuxc: iomuxc {
> > > > > compatible = "fsl,imx8qxp-iomuxc";
> > > > > fsl,mu = <&lsio_mu3>;
> > > > > };
> > > > >
> > > > > imx8qx-pm {
> > > > > #address-cells = <1>;
> > > > > #size-cells = <0>;
> > > > > fsl,mu = <&lsio_mu4>;
> > > > > .............
> > > > > }
> > > > >
> > > > > The default code only uses MU0 which is used by SCU.
> > > > >
> > > > > The change may affect this design. Any ideas?
> > > >
> > > > Sorry for the delay.
> > > >
> > > > You can add the child nodes to the mu nodes they should use:
> > > >
> > > > scu1 {
> > > > compatible = "nxp,imx8qxp-scu";
> > > > reg = <0x0 0x5d1b0000 0x0 0x10000>;
> > > >
> > > > clk: clk {
> > > > compatible = "fsl,imx8qxp-clk";
> > > > #clock-cells = <1>;
> > > > };
> > > >
> > > > ...
> > > > };
> > > >
> > > > scu2 {
> > > > compatible = "nxp,imx8qxp-scu";
> > > > reg = <0x0 someothermu 0x0 0x10000>;
> > > >
> > > > iomuxc: iomuxc {
> > > > compatible = "fsl,imx8qxp-iomuxc";
> > > > };
> > > >
> > > > ...
> > > > };
> > > >
> > > > So instead of adding all possible children to a single mu and
> > > > phandle to other mu's, just add the right children to each mu.
> > > >
> > >
> > > I got your point now. But sorry i'm still a bit hestitate to it....
> > >
> > > This way increases complexity and looks more like a per-channel binding.
> > > But we normally have only one (abstract) SCU firmware node in a system
> > > which may use different channels to implement different functions like clk,
> > pd and etc.
> > > Multiple faked SCU nodes make people a bit confusing.
> >
> > They are not faked, indeed that's the MU units that physically exist.
> >
> > > Furthermore, it's still lose the flexibility for user to changing a MU to use.
> > >
> > > Looking at all exist users in kernel, seems no one to use like this.
> > > See:
> > > Documentation/devicetree/bindings/arm/arm,scpi.txt
> > > Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> > >
> > > All are similar like:
> > > xxx: protocol-node {
> > > compatible = "xxx-protocal";
> > > channel = ...
> > > ...
> > >
> > > clk_node: clk_node {
> > > ...
> > > };
> > >
> > > pd_node: pd_node {
> > > ...
> > > };
> > > };
> > > The protocol node work is selecting the correct channel, do necessary
> > > initialization and populate the all child function device nodes.
> > >
> > > IMHO I'm still a bit like to this common way used in kernel if no stronger
> > objection.
> > > Do you think we can choose this way to go step forward?
> >
> > I'm not convinced, but go ahead if you think this is the better way to proceed.
> >
> > I think my original point that led to this discussion is the muddled way the
> > MUs are handled in the code.
> >
> > To start with in the system controller code you ioremap the physical address
> > of the MU and later on pass this address as a reference to the MU library
> > code. There's no way for the MU code to ever create a private data. It would
> > be much better if you would pass mu_init a pointer to the device node it shall
> > initialize, let mu_init allocate a private data struct, ioremap the base and put
> > it in the private data struct, and return the private data struct.
> >
>
> Actually I have tried that way initially, but ....
>
> > Then there is this sc_ipc_get_handle() thing that your consumers shall use to
> > get a handle to the SCU. Instead of returning a struct sc_ipc * there you
> > return a ida which you first have to search for each time a consumer wants to
> > do something on the SCU. Please just return a pointer there (which can be a
> > cookie, i.e. the struct definition is unknown to the consumer but privately to
> > the SCU code).
> >
>
> The problem is that sc_ipc_t is defined as uint32_t.
> /*
> * This type is used to declare a handle for an IPC communication
> * channel. Its meaning is specific to the IPC implementation.
> */
> typedef uint32_t sc_ipc_t;
>
> which is referenced by the standard rpc call:
> void sc_call_rpc(sc_ipc_t ipc, sc_rpc_msg_t *msg, bool no_resp)
>
> I can't return a pointer which is 64bit on ARMv8 platform and used it
> for sc_call_rpc directly.
>
> That why I need a way to convert struct sc_ipc_t to struct sc_ipc
> (done by sc_ipc_get(ipc)).
>
> But you're right, that means we have to search for each time a consumer
> wants to do something on the SCU.
>
> If we want to void it, one possible way may be changing the prototype of
> both ipc handle sc_ipc_t and IPC channel ID sc_ipc_id_t to unsigned long,
> then we can directly pass them the address pointer.
>
> Although I initially don't want to changing SCU API prototype, but if we
> have to, I will do it.
Don't try to push crappy code just because you use the same crappy code
internally elsewhere. Everything you post for the Kernel is subject for
discussion, review and change. If we would follow the
it's-in-sync-with-internal-company-code argument the Kernel would loook
differently now and surely not better.
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/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: kbuild test robot @ 2018-06-08 3:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528401833-29963-3-git-send-email-gengdongjiu@huawei.com>
Hi Dongjiu,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on v4.17]
[cannot apply to next-20180607]
[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/Dongjiu-Geng/support-exception-state-migration-and-set-VSESR_EL2-by-user-space/20180608-063827
base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All warnings (new ones prefixed by >>):
arch/arm64/kvm/guest.c: In function 'kvm_arm_vcpu_get_events':
>> arch/arm64/kvm/guest.c:295:26: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to dereference it? [-Wsizeof-pointer-memaccess]
memset(events, 0, sizeof(events));
^
vim +295 arch/arm64/kvm/guest.c
291
292 int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
293 struct kvm_vcpu_events *events)
294 {
> 295 memset(events, 0, sizeof(events));
296
297 events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
298 events->exception.serror_has_esr =
299 cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
300
301 if (events->exception.serror_pending &&
302 events->exception.serror_has_esr)
303 events->exception.serror_esr = vcpu_get_vsesr(vcpu);
304 else
305 events->exception.serror_esr = 0;
306
307 return 0;
308 }
309
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37498 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180608/69ebaa7b/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 1/2] KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
From: Jia He @ 2018-06-08 1:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526635630-18917-1-git-send-email-hejianet@gmail.com>
Ping?thanks
--
Cheers,
Jia
On 5/18/2018 5:27 PM, Jia He Wrote:
> There is a panic in armv8a server(QDF2400) under memory pressure tests
> (start 20 guests and run memhog in the host).
>
> ---------------------------------begin--------------------------------
> [35380.800950] BUG: Bad page state in process qemu-kvm pfn:dd0b6
> [35380.805825] page:ffff7fe003742d80 count:-4871 mapcount:-2126053375
> mapping: (null) index:0x0
> [35380.815024] flags: 0x1fffc00000000000()
> [35380.818845] raw: 1fffc00000000000 0000000000000000 0000000000000000
> ffffecf981470000
> [35380.826569] raw: dead000000000100 dead000000000200 ffff8017c001c000
> 0000000000000000
> [35380.805825] page:ffff7fe003742d80 count:-4871 mapcount:-2126053375
> mapping: (null) index:0x0
> [35380.815024] flags: 0x1fffc00000000000()
> [35380.818845] raw: 1fffc00000000000 0000000000000000 0000000000000000
> ffffecf981470000
> [35380.826569] raw: dead000000000100 dead000000000200 ffff8017c001c000
> 0000000000000000
> [35380.834294] page dumped because: nonzero _refcount
> [35380.839069] Modules linked in: vhost_net vhost tap ebtable_filter
> ebtables ip6table_filter ip6_tables iptable_filter fcoe libfcoe libfc
> 8021q garp mrp stp llc scsi_transport_fc openvswitch nf_conntrack_ipv6
> nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_defrag_ipv6
> nf_nat nf_conntrack vfat fat rpcrdma ib_isert iscsi_target_mod ib_iser
> libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp
> scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm
> ib_cm iw_cm mlx5_ib ib_core crc32_ce ipmi_ssif tpm_tis tpm_tis_core sg
> nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_multipath ip_tables xfs
> libcrc32c mlx5_core mlxfw devlink ahci_platform libahci_platform libahci
> qcom_emac sdhci_acpi sdhci hdma mmc_core hdma_mgmt i2c_qup dm_mirror
> dm_region_hash dm_log dm_mod
> [35380.908341] CPU: 29 PID: 18323 Comm: qemu-kvm Tainted: G W
> 4.14.15-5.hxt.aarch64 #1
> [35380.917107] Hardware name: <snip for confidential issues>
> [35380.930909] Call trace:
> [35380.933345] [<ffff000008088f00>] dump_backtrace+0x0/0x22c
> [35380.938723] [<ffff000008089150>] show_stack+0x24/0x2c
> [35380.943759] [<ffff00000893c078>] dump_stack+0x8c/0xb0
> [35380.948794] [<ffff00000820ab50>] bad_page+0xf4/0x154
> [35380.953740] [<ffff000008211ce8>] free_pages_check_bad+0x90/0x9c
> [35380.959642] [<ffff00000820c430>] free_pcppages_bulk+0x464/0x518
> [35380.965545] [<ffff00000820db98>] free_hot_cold_page+0x22c/0x300
> [35380.971448] [<ffff0000082176fc>] __put_page+0x54/0x60
> [35380.976484] [<ffff0000080b1164>] unmap_stage2_range+0x170/0x2b4
> [35380.982385] [<ffff0000080b12d8>] kvm_unmap_hva_handler+0x30/0x40
> [35380.988375] [<ffff0000080b0104>] handle_hva_to_gpa+0xb0/0xec
> [35380.994016] [<ffff0000080b2644>] kvm_unmap_hva_range+0x5c/0xd0
> [35380.999833] [<ffff0000080a8054>]
> kvm_mmu_notifier_invalidate_range_start+0x60/0xb0
> [35381.007387] [<ffff000008271f44>]
> __mmu_notifier_invalidate_range_start+0x64/0x8c
> [35381.014765] [<ffff0000082547c8>] try_to_unmap_one+0x78c/0x7a4
> [35381.020493] [<ffff000008276d04>] rmap_walk_ksm+0x124/0x1a0
> [35381.025961] [<ffff0000082551b4>] rmap_walk+0x94/0x98
> [35381.030909] [<ffff0000082555e4>] try_to_unmap+0x100/0x124
> [35381.036293] [<ffff00000828243c>] unmap_and_move+0x480/0x6fc
> [35381.041847] [<ffff000008282b6c>] migrate_pages+0x10c/0x288
> [35381.047318] [<ffff00000823c164>] compact_zone+0x238/0x954
> [35381.052697] [<ffff00000823c944>] compact_zone_order+0xc4/0xe8
> [35381.058427] [<ffff00000823d25c>] try_to_compact_pages+0x160/0x294
> [35381.064503] [<ffff00000820f074>]
> __alloc_pages_direct_compact+0x68/0x194
> [35381.071187] [<ffff000008210138>] __alloc_pages_nodemask+0xc20/0xf7c
> [35381.077437] [<ffff0000082709e4>] alloc_pages_vma+0x1a4/0x1c0
> [35381.083080] [<ffff000008285b68>]
> do_huge_pmd_anonymous_page+0x128/0x324
> [35381.089677] [<ffff000008248a24>] __handle_mm_fault+0x71c/0x7e8
> [35381.095492] [<ffff000008248be8>] handle_mm_fault+0xf8/0x194
> [35381.101049] [<ffff000008240dcc>] __get_user_pages+0x124/0x34c
> [35381.106777] [<ffff000008241870>] populate_vma_page_range+0x90/0x9c
> [35381.112941] [<ffff000008241940>] __mm_populate+0xc4/0x15c
> [35381.118322] [<ffff00000824b294>] SyS_mlockall+0x100/0x164
> [35381.123705] Exception stack(0xffff800dce5f3ec0 to 0xffff800dce5f4000)
> [35381.130128] 3ec0: 0000000000000003 d6e6024cc9b87e00 0000aaaabe94f000
> 0000000000000000
> [35381.137940] 3ee0: 0000000000000002 0000000000000000 0000000000000000
> 0000aaaacf6fc3c0
> [35381.145753] 3f00: 00000000000000e6 0000aaaacf6fc490 0000ffffeeeab0f0
> d6e6024cc9b87e00
> [35381.153565] 3f20: 0000000000000000 0000aaaabe81b3c0 0000000000000020
> 00009e53eff806b5
> [35381.161379] 3f40: 0000aaaabe94de48 0000ffffa7c269b0 0000000000000011
> 0000ffffeeeabf68
> [35381.169190] 3f60: 0000aaaaceacfe60 0000aaaabe94f000 0000aaaabe9ba358
> 0000aaaabe7ffb80
> [35381.177003] 3f80: 0000aaaabe9ba000 0000aaaabe959f64 0000000000000000
> 0000aaaabe94f000
> [35381.184815] 3fa0: 0000000000000000 0000ffffeeeabdb0 0000aaaabe5f3bf8
> 0000ffffeeeabdb0
> [35381.192628] 3fc0: 0000ffffa7c269b8 0000000060000000 0000000000000003
> 00000000000000e6
> [35381.200440] 3fe0: 0000000000000000 0000000000000000 0000000000000000
> 0000000000000000
> [35381.208254] [<ffff00000808339c>] __sys_trace_return+0x0/0x4
> [35381.213809] Disabling lock debugging due to kernel taint
> --------------------------------end--------------------------------------
>
> The root cause might be what I fixed at [1]. But from arm kvm points of
> view, it would be better we caught the exception earlier and clearer.
>
> If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the
> wrong(more or less) page range. Hence it caused the "BUG: Bad page
> state"
>
> [1] https://lkml.org/lkml/2018/5/3/1042
>
> Signed-off-by: jia.he at hxt-semitech.com
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> v2: refine the commit log
>
> virt/kvm/arm/mmu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index 7f6a944..8dac311 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -297,6 +297,8 @@ static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
> phys_addr_t next;
>
> assert_spin_locked(&kvm->mmu_lock);
> + WARN_ON(size & ~PAGE_MASK);
> +
> pgd = kvm->arch.pgd + stage2_pgd_index(addr);
> do {
> /*
>
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 441/942] drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1854:18: error: 'struct axienet_local' has no member named 'tx_irq'; did you mean 'rtc_irq'?
From: kbuild test robot @ 2018-06-08 0:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi Saurabh,
FYI, the error/warning still remains.
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: ad4cd988ba86ab0fb306d57f244b7eaa6cce79a4
commit: 27eb94d2931872784a5e740adbddd1b823dc7b95 [441/942] drivers: net: ethernet: TSN: Kconfig and Makefile
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 27eb94d2931872784a5e740adbddd1b823dc7b95
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
drivers/net//ethernet/xilinx/xilinx_axienet_main.c: In function 'axienet_start_xmit':
drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1069:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
const struct ethhdr *eth;
^~~~~
drivers/net//ethernet/xilinx/xilinx_axienet_main.c: In function 'axienet_poll_controller':
>> drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1854:18: error: 'struct axienet_local' has no member named 'tx_irq'; did you mean 'rtc_irq'?
disable_irq(lp->tx_irq);
^~~~~~
rtc_irq
>> drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1855:18: error: 'struct axienet_local' has no member named 'rx_irq'; did you mean 'rtc_irq'?
disable_irq(lp->rx_irq);
^~~~~~
rtc_irq
drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1856:21: error: 'struct axienet_local' has no member named 'tx_irq'; did you mean 'rtc_irq'?
axienet_rx_irq(lp->tx_irq, ndev);
^~~~~~
rtc_irq
drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1857:21: error: 'struct axienet_local' has no member named 'rx_irq'; did you mean 'rtc_irq'?
axienet_tx_irq(lp->rx_irq, ndev);
^~~~~~
rtc_irq
drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1858:17: error: 'struct axienet_local' has no member named 'tx_irq'; did you mean 'rtc_irq'?
enable_irq(lp->tx_irq);
^~~~~~
rtc_irq
drivers/net//ethernet/xilinx/xilinx_axienet_main.c:1859:17: error: 'struct axienet_local' has no member named 'rx_irq'; did you mean 'rtc_irq'?
enable_irq(lp->rx_irq);
^~~~~~
rtc_irq
vim +1854 drivers/net//ethernet/xilinx/xilinx_axienet_main.c
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1841
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1842 #ifdef CONFIG_NET_POLL_CONTROLLER
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1843 /**
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1844 * axienet_poll_controller - Axi Ethernet poll mechanism.
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1845 * @ndev: Pointer to net_device structure
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1846 *
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1847 * This implements Rx/Tx ISR poll mechanisms. The interrupts are disabled prior
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1848 * to polling the ISRs and are enabled back after the polling is done.
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1849 */
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1850 static void axienet_poll_controller(struct net_device *ndev)
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1851 {
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1852 struct axienet_local *lp = netdev_priv(ndev);
c0ebb862 Kedareswara rao Appana 2017-09-18 1853
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 @1854 disable_irq(lp->tx_irq);
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 @1855 disable_irq(lp->rx_irq);
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1856 axienet_rx_irq(lp->tx_irq, ndev);
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1857 axienet_tx_irq(lp->rx_irq, ndev);
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1858 enable_irq(lp->tx_irq);
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1859 enable_irq(lp->rx_irq);
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1860 }
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1861 #endif
8a3b7a25 danborkmann at iogearbox.net 2012-01-19 1862
:::::: The code at line 1854 was first introduced by commit
:::::: 8a3b7a252dca9fb28c23b5bf76c49180a2b60d3b drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver
:::::: TO: danborkmann at iogearbox.net <danborkmann@iogearbox.net>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 64342 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180608/b05c3446/attachment-0001.gz>
^ permalink raw reply
* [PATCH v6 2/2] regulator: add QCOM RPMh regulator driver
From: Matthias Kaehlcke @ 2018-06-08 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6d7abf248493cf81d62eb17ecb5030783aa85f72.1528138319.git.collinsd@codeaurora.org>
Hi David,
On Mon, Jun 04, 2018 at 12:15:12PM -0700, David Collins wrote:
> Add the QCOM RPMh regulator driver to manage PMIC regulators
> which are controlled via RPMh on some Qualcomm Technologies, Inc.
> SoCs. RPMh is a hardware block which contains several
> accelerators which are used to manage various hardware resources
> that are shared between the processors of the SoC. The final
> hardware state of a regulator is determined within RPMh by
> performing max aggregation of the requests made by all of the
> processors.
>
> Add support for PMIC regulator control via the voltage regulator
> manager (VRM) and oscillator buffer (XOB) RPMh accelerators.
> VRM supports manipulation of enable state, voltage, and mode.
> XOB supports manipulation of enable state.
>
> Signed-off-by: David Collins <collinsd@codeaurora.org>
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/qcom-rpmh-regulator.c | 767 ++++++++++++++++++++++++++++++++
> 3 files changed, 777 insertions(+)
> create mode 100644 drivers/regulator/qcom-rpmh-regulator.c
>
> ...
>
> diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c
> new file mode 100644
> index 0000000..a7fffb6
> --- /dev/null
> +++ b/drivers/regulator/qcom-rpmh-regulator.c
>
> ...
> static int rpmh_regulator_send_request(struct rpmh_vreg *vreg,
> + struct tcs_cmd *cmd, int count, bool wait_for_ack)
>
nit: as of now this is only called with a single command. If you
anticipate that this is unlikely to change consider removing 'count',
not having it in the calls slightly improves readability.
> ...
> +static int _rpmh_regulator_vrm_set_voltage_sel(struct regulator_dev *rdev,
> + unsigned int selector, bool wait_for_ack)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_VRM_VOLTAGE,
> + };
> + int ret;
> +
> + /* VRM voltage control register is set with voltage in millivolts. */
> + cmd.data = DIV_ROUND_UP(regulator_list_voltage_linear_range(rdev,
> + selector), 1000);
> +
> + ret = rpmh_regulator_send_request(vreg, &cmd, 1, wait_for_ack);
> + if (!ret)
> + vreg->voltage_selector = selector;
> +
> + return 0;
Shouldn't this return 'ret'?
> +static int rpmh_regulator_enable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 1,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, &cmd, 1, true);
> + if (!ret)
> + vreg->enabled = true;
> +
> + return ret;
> +}
> +
> +static int rpmh_regulator_disable(struct regulator_dev *rdev)
> +{
> + struct rpmh_vreg *vreg = rdev_get_drvdata(rdev);
> + struct tcs_cmd cmd = {
> + .addr = vreg->addr + RPMH_REGULATOR_REG_ENABLE,
> + .data = 0,
> + };
> + int ret;
> +
> + if (vreg->enabled == -EINVAL &&
> + vreg->voltage_selector != -ENOTRECOVERABLE) {
> + ret = _rpmh_regulator_vrm_set_voltage_sel(rdev,
> + vreg->voltage_selector, true);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = rpmh_regulator_send_request(vreg, &cmd, 1, false);
> + if (!ret)
> + vreg->enabled = false;
> +
> + return ret;
> +}
nit: rpmh_regulator_enable() and rpmh_regulator_disable() are
essentially the same code, consider introducing a helper like
_rpmh_regulator_enable(struct regulator_dev *rdev, bool enable).
> +/**
> + * rpmh_regulator_init_vreg() - initialize all attributes of an rpmh-regulator
> + * vreg: Pointer to the individual rpmh-regulator resource
> + * dev: Pointer to the top level rpmh-regulator PMIC device
> + * node: Pointer to the individual rpmh-regulator resource
> + * device node
> + * pmic_id: String used to identify the top level rpmh-regulator
> + * PMIC device on the board
> + * rpmh_data: Pointer to a null-terminated array of rpmh-regulator
> + * resources defined for the top level PMIC device
> + *
> + * Return: 0 on success, errno on failure
> + */
> +static int rpmh_regulator_init_vreg(struct rpmh_vreg *vreg, struct device *dev,
> + struct device_node *node, const char *pmic_id,
> + const struct rpmh_vreg_init_data *rpmh_data)
> +{
> + struct regulator_config reg_config = {};
> + char rpmh_resource_name[20] = "";
> + struct regulator_dev *rdev;
> + struct regulator_init_data *init_data;
> + int ret;
> +
> + vreg->dev = dev;
> +
> + for (; rpmh_data->name; rpmh_data++)
> + if (!strcmp(rpmh_data->name, node->name))
> + break;
nit: it's a bit odd to use the parameter itself for iteration, but I
guess it's a matter of preferences.
Thanks
Matthias
^ permalink raw reply
* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC
From: Nishanth Menon @ 2018-06-07 23:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJusWTvr4A_-Bk81meYddMHBMJ4=Fch6L0MFoF7HfBW2w@mail.gmail.com>
On 14:05-20180605, Rob Herring wrote:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote:
[...]
> > + soc0: soc0 {
> > + compatible = "simple-bus";
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
>
> Really need 64-bit addresses and sizes? Use ranges to limit the
> address space if possible.
Done -> overall the addresses are really in the 64bit addresses, but
used bus segments and ranges to reduce to 32bit maps where possible.
OSPI, PCIE, FSS (Flash subsystem) , CPTS are some of the ones that
probably will need some level of cleanups when those are introduced
later.
Unfortunately, there is a lot of interleaved addressing between bus
segments themselves, I have tried to keep the ranges as clean as
reasonably possible. I also tried to use 1-1 map for children nodes to
maintain some level of sanity as we add more device nodes. There might
be a few exceptions, but overall the ranges currently map 1-1 physical
32bit address - OSPI, CPTS, FSS will however have to have a different
mapping.
See [1]
>
> > +
> > + a53_timer0: timer-cl0-cpu0 {
> > + compatible = "arm,armv8-timer";
> > + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> > + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> > + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> > + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> > + };
> > +
> > + pmu: pmu {
> > + compatible = "arm,armv8-pmuv3";
> > + /* Recommendation from GIC500 TRM Table A.3 */
> > + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> > + };
>
> These 2 nodes aren't on the bus, so move them up a level.
Thanks. oversight on my end. I have fixed it (see [1])
>
> > +
> > + gic: interrupt-controller at 1800000 {
> > + compatible = "arm,gic-v3";
>
> gic-500?
Yes, GIC500.
>
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + ranges;
> > + #interrupt-cells = <3>;
> > + interrupt-controller;
> > + /*
> > + * NOTE: we are NOT gicv2 backward compat, so no GICC,
> > + * GICH or GICV
>
> The compatible should imply this.
GIC500 at SoC design instantiation takes a parameter
"are_option" -> this is set to no-compatibility for V2 for AM6. This is indeed
discovered by the driver, However,
Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
just notes that GICC, GICH, GICV as optional.. With backward
compatibility disabled, these are'nt even present.
I have dropped the comment, was helpful for me when I was first
adding support for GIC500, It is pretty common knowledge now for other
ARMV8 developers, so no point in retaining newbie info as comment.
[...]
> > diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> > new file mode 100644
> > index 000000000000..d9b70081daba
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
> > @@ -0,0 +1,117 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Device Tree Source for AM6 SoC family in Quad core configuration
> > + *
> > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
> > + */
> > +
> > +#include "k3-am6.dtsi"
> > +
> > +/ {
> > + cpus: cpus {
>
> Really need a label?
Thanks. Dropped.
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + cpu-map {
>
> IIRC, this goes at the top level.
Documentation/devicetree/bindings/arm/topology.txt
States to keep in cpus node. Quote:
| The ARM CPU topology is defined within the cpu-map node, which is a direct
| child of the cpus node and provides a container where the actual topology
| nodes are listed.
Retained as is to stay in sync with binding.
> > + cpu0: cpu at 0 {
> > + compatible = "arm,cortex-a53","arm,armv8";
>
> space between compatibles.
Oops. Fixed. thanks.
>
> > + reg = <0x000>;
> > + device_type = "cpu";
> > + enable-method = "psci";
>
> > + i-cache-size = <0x8000>;
> > + i-cache-line-size = <64>;
> > + i-cache-sets = <256>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <64>;
> > + d-cache-sets = <128>;
>
> All this should be discoverable.
Unfortunately no.
Previously CCSIDR_EL1 was a good place to lookup this data.
But as Sudeep pointed me offline:
commit a8d4636f96ad ("arm64: cacheinfo: Remove CCSIDR-based cache information probing")
and commit 9a802431c527 ("arm64: cacheinfo: add support to override cache levels via device tree")
had already provided options to override cache information from the device tree.
This is what I am using.
Quote from commit:
The architecture explicitly states:
| You cannot make any inference about the actual sizes of caches based
| on these parameters.
[...]
> > +
> > +&soc0 {
> > + L2_0: l2-cache0 {
> > + compatible = "cache";
>
> Is this documented?
Just what Documentation/devicetree/bindings/arm/cpu-capacity.txt states
as an example. We dont seem to have anything similar to
Documentation/devicetree/bindings/arm/l2c2x0.txt in armv8 as per the
comments in the document at least.
>
> > + cache-level = <2>;
> > + cache-size = <0x80000>;
> > + cache-line-size = <64>;
> > + cache-sets = <512>;
>
> Discoverable?
Same comment as L1 cache details.
>
> > + next-level-cache = <&msmc_l3>;
> > + };
> > +
> > + L2_1: l2-cache1 {
> > + compatible = "cache";
> > + cache-level = <2>;
> > + cache-size = <0x80000>;
> > + cache-line-size = <64>;
> > + cache-sets = <512>;
> > + next-level-cache = <&msmc_l3>;
> > + };
> > +
> > + msmc_l3: l3-cache0 {
> > + compatible = "cache";
>
> Is this something TI specific or follows the (ARM) architecture?
ARM Architecture permits an L3 Cache. TI implements it differently (we
dont use CCI), instead an L3 Cache is always active in our
implementation - backing memory is configurable and is designed to be
completely transparent to s/w running on ARMv8.
Description here is to meet the hardware description of cache topology
to be accurate.
[...]
> > diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
> > index 92770d84a288..be4570baad96 100644
> > --- a/drivers/soc/ti/Kconfig
> > +++ b/drivers/soc/ti/Kconfig
> > @@ -1,3 +1,17 @@
> > +# 64-bit ARM SoCs from TI
> > +if ARM64
> > +
> > +if ARCH_K3
> > +
> > +config ARCH_K3_AM6_SOC
>
> This should be in another patch (or dropped?).
Agreed and split off into another patch.
[1]
Here is how the patch looks now (after incorporating changes suggested
by Tony as well) - Thoughts please:
https://github.com/nmenon/linux-2.6-playground/tree/upstream/next-20180604/k3-5-defconfig/arch/arm64/boot/dts/ti
has everything consolidated.
8<--
>From 88857a8241fc67d63021e5c9070092b11398d11f Mon Sep 17 00:00:00 2001
From: Nishanth Menon <nm@ti.com>
Date: Wed, 14 Sep 2016 19:12:42 -0500
Subject: [RFC V2 PATCH] arm64: dts: ti: Add Support for AM654 SoC
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
We introduce the Kconfig symbol for the SoC along with this patch since
it is logically relevant point, however the usage is in subsequent
patches.
NOTE: AM654 is the first of the device variants, hence we introduce a
generic am6.dtsi.
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/ti/k3-am6.dtsi | 172 +++++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++
3 files changed, 290 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index cfb35b252ac7..5f5c4eddec7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi
new file mode 100644
index 000000000000..700c56eda12d
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "Texas Instruments K3 AM654 SoC";
+ compatible = "ti,am654";
+ interrupt-parent = <&gic500>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &wkup_uart0;
+ serial1 = &mcu_uart0;
+ serial2 = &main_uart0;
+ serial3 = &main_uart1;
+ serial4 = &main_uart2;
+ };
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ a53_timer0: timer-cl0-cpu0 {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+ };
+
+ pmu: pmu {
+ compatible = "arm,armv8-pmuv3";
+ /* Recommendation from GIC500 TRM Table A.3 */
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ soc0: soc0 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ main_domain: cbass at 100000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00100000 0x00 0x00100000 0x00020000>, /* ctrl mmr */
+ <0x00600000 0x00 0x00600000 0x00001100>, /* GPIO */
+ <0x00900000 0x00 0x00900000 0x00012000>, /* serdes */
+ <0x01000000 0x00 0x01000000 0x0AF02400>, /* Most peripherals */
+ <0x30800000 0x00 0x30800000 0x0BC00000>; /* MAIN NAVSS */
+
+ gic500: interrupt-controller at 1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x01800000 0x10000>, /* GICD */
+ <0x01880000 0x90000>; /* GICR */
+
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: gic-its at 18200000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x01820000 0x10000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ main_uart0: serial at 2800000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x02800000 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart1: serial at 2810000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x02810000 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ main_uart2: serial at 2820000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x02820000 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+ };
+
+ wkup_domain: cbass at 42040000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x42040000 0x00 0x42040000 0x03AC2400>; /* Basic peripherals */
+
+ wkup_uart0: serial at 42300000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x42300000 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ };
+
+ mcu_domain: cbass at 28380000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x28380000 0x00 0x28380000 0x03880000>, /* MCU NAVSS*/
+ <0x40200000 0x00 0x40200000 0x00900100>, /* First peripheral window */
+ <0x45100000 0x00 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */
+ <0x46000000 0x00 0x46000000 0x00200000>, /* CPSW */
+ <0x47000000 0x00 0x47000000 0x00068400>; /* OSPI space 1 */
+
+ mcu_uart0: serial at 40a00000 {
+ compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a";
+ reg = <0x40a00000 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <96000000>;
+ current-speed = <115200>;
+ status = "disabled";
+ };
+
+ };
+
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
new file mode 100644
index 000000000000..bffa414180ea
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
@@ -0,0 +1,117 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC family in Quad core configuration
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include "k3-am6.dtsi"
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+
+ cluster1: cluster1 {
+ core0 {
+ cpu = <&cpu2>;
+ };
+
+ core1 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu at 0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x000>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu at 1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x001>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu2: cpu at 100 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu3: cpu at 101 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+ };
+};
+
+&soc0 {
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ L2_1: l2-cache1 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ msmc_l3: l3-cache0 {
+ compatible = "cache";
+ cache-level = <3>;
+ };
+};
--
2.15.1
--
Regards,
Nishanth Menon
^ permalink raw reply related
* [PATCH] ARM: spectre-v2: Try to set IBE bit for Cortex-A15 and Brahma-B15
From: Florian Fainelli @ 2018-06-07 22:58 UTC (permalink / raw)
To: linux-arm-kernel
Per the ARM reference manual for the Cortex-A15, The ACTLR:
Is a read/write register.
Common to the Secure and Non-secure states.
Is only accessible from PL1 or higher, with access rights that depend
on the mode:
* Read/write in Secure PL1 modes.
* Read-only and write-ignored in Non-secure PL1 and PL2 modes
if NSACR.NS_SMP is 0.
* Read/write in Non-secure PL1 and PL2 modes if NSACR.NS_SMP
is 1. In this case, all bits are write-ignored except for the SMP bit.
We can attempt to set this bit from within the kernel, which helps
avoiding firmware side modifications to set the IBE bit when that is
impractical. We do this within __v7_ca15mp_setup and __v7_b15mp_setup
because by then we already took those labels because the processors we
run on do match.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/mm/proc-v7.S | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 6fe52819e014..a21cf3729efa 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -284,10 +284,16 @@ __v7_cr8mp_setup:
b 1f
__v7_ca7mp_setup:
__v7_ca12mp_setup:
+ b 2f
__v7_ca15mp_setup:
__v7_b15mp_setup:
+#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
+ mrc p15, 0, r0, c1, c0, 1
+ orr r0, r0, #1 @ Enable IBE bit
+ mcr p15, 0, r0, c1, c0, 1
+#endif
__v7_ca17mp_setup:
- mov r10, #0
+2: mov r10, #0
1: adr r0, __v7_setup_stack_ptr
ldr r12, [r0]
add r12, r12, r0 @ the local stack
--
2.14.1
^ permalink raw reply related
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Mathieu Poirier @ 2018-06-07 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607164747.7e4bb30f69a1fb4c160b6ef1@arm.com>
On 7 June 2018 at 15:47, Kim Phillips <kim.phillips@arm.com> wrote:
> On Thu, 7 Jun 2018 22:10:07 +0100
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
>> On 06/07/2018 06:13 PM, Kim Phillips wrote:
>> > I'm going to assume the series is still valid after this discussion,
>> > since technically just this patch can get dropped, and the user is able
>> > to shoot themselves in the foot.
>>
>> That doesn't mean the kernel can panic() if the user decided to unload
>> the module while the trace session is in progress. It only means that
>> the trace session could be stopped in between in the worst case. But
>> nothing more harmful to the system.
>
> FWIW, I didn't see the kernel panic in my basic tests; just some bad
> accesses: the new remove functions take care of cleaning up most items,
> and most drivers still depend on the links and sinks (funnel,
> replicator) drivers, so they can't be upset too bad.
>
>> > This series is for development purposes, after all.
>>
>> Do you mean that this series is for internal development purposes and
>> not upstream ? Making the drivers modular are always helpful, especially
>
> no, I'm posting them for upstream review because I'd like them upstream.
>
>> for something related to tracing, that allows the module to be unloaded
>> after use. So, it would be good to have this series in, but in a manner
>> which is usable and doesn't cause harm to the overall system usage.
>>
>> I think the summary of the discussion is that we need more robust code
>> to handle the situation, which also allows unloading the modules without
>> any trouble.
>
> Trouble's relative. My point was since the series is going to be used
> mainly by developers testing their code, they already prepare for, and
> expect badness to occur anyway. Greg's point isn't lost here, and in
> my interpretation, his review of this patch was that it was in the
> wrong direction of safety: it made things unnecessarily too safe, up
> front, and that items relative to the perf core should strive to adhere
> to the higher standards set in place by the networking subsystem. So,
> this patch doesn't get his ack.
Greg's point was that it's OK to let users harm themselves (which I
totally support), but if you're going to prevent it, make sure to do
it right.
>
> I compiled a new v5 series that omits this patch, and overwrote the v4
> series here:
>
> git://linux-arm.org/linux-kp.git, coresight-modules branch
>
> but I'll hold of submitting a v5 for now.
>
> I don't know how the perf core handles AUXTRACE drivers hanging up on
> it. I see intel-pt record support can't be built as a module. I'm
> guessing more testing for actual panics when using perf or sysfs is
> what's being sought here?
There are two ways to approach the problem:
1) Kill active trace sessions (either sysFS or perf) if a driver that
is being used is removed.
2) Deal with the removal in the coresight core, making sure we don't
access operations provided by removed drivers.
The end result in both cases will be the same: failure to properly
terminate the trace session because of user action.
I'm personally in favour of the second option, simply because it keeps
problems resolution with the CS subsystem.
>
> Kim
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Kim Phillips @ 2018-06-07 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39d1089f-585d-bc19-2ecd-c9c9c812f85f@arm.com>
On Thu, 7 Jun 2018 22:10:07 +0100
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 06/07/2018 06:13 PM, Kim Phillips wrote:
> > I'm going to assume the series is still valid after this discussion,
> > since technically just this patch can get dropped, and the user is able
> > to shoot themselves in the foot.
>
> That doesn't mean the kernel can panic() if the user decided to unload
> the module while the trace session is in progress. It only means that
> the trace session could be stopped in between in the worst case. But
> nothing more harmful to the system.
FWIW, I didn't see the kernel panic in my basic tests; just some bad
accesses: the new remove functions take care of cleaning up most items,
and most drivers still depend on the links and sinks (funnel,
replicator) drivers, so they can't be upset too bad.
> > This series is for development purposes, after all.
>
> Do you mean that this series is for internal development purposes and
> not upstream ? Making the drivers modular are always helpful, especially
no, I'm posting them for upstream review because I'd like them upstream.
> for something related to tracing, that allows the module to be unloaded
> after use. So, it would be good to have this series in, but in a manner
> which is usable and doesn't cause harm to the overall system usage.
>
> I think the summary of the discussion is that we need more robust code
> to handle the situation, which also allows unloading the modules without
> any trouble.
Trouble's relative. My point was since the series is going to be used
mainly by developers testing their code, they already prepare for, and
expect badness to occur anyway. Greg's point isn't lost here, and in
my interpretation, his review of this patch was that it was in the
wrong direction of safety: it made things unnecessarily too safe, up
front, and that items relative to the perf core should strive to adhere
to the higher standards set in place by the networking subsystem. So,
this patch doesn't get his ack.
I compiled a new v5 series that omits this patch, and overwrote the v4
series here:
git://linux-arm.org/linux-kp.git, coresight-modules branch
but I'll hold of submitting a v5 for now.
I don't know how the perf core handles AUXTRACE drivers hanging up on
it. I see intel-pt record support can't be built as a module. I'm
guessing more testing for actual panics when using perf or sysfs is
what's being sought here?
Kim
^ permalink raw reply
* [PATCH v4 14/14] coresight: allow the coresight core driver to be built as a module
From: Mathieu Poirier @ 2018-06-07 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605210710.22227-15-kim.phillips@arm.com>
On 5 June 2018 at 15:07, Kim Phillips <kim.phillips@arm.com> wrote:
> Allow to build coresight as a module. This enhances
> coresight developer efficiency by allowing the development to
> take place exclusively on the target, and without needing to
> reboot in between changes.
>
> - Kconfig becomes a tristate, to allow =m
> - append -core to source file name to allow module to
> be called coresight by the Makefile
> - modules can have only one init/exit, so we add the core bus
> register/unregister function calls to the etm_perf init/exit
> functions, since coresight.c does not have etm_pmu defined.
> - add a MODULE_DEVICE_TABLE for autoloading on boot
>
> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
> Cc: Leo Yan <leo.yan@linaro.org>
> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Kim Phillips <kim.phillips@arm.com>
> ---
> drivers/hwtracing/coresight/Kconfig | 5 ++++-
> drivers/hwtracing/coresight/Makefile | 7 +++++--
> .../coresight/{coresight.c => coresight-core.c} | 6 ------
> .../hwtracing/coresight/coresight-etm-perf.c | 17 ++++++++++++++++-
> 4 files changed, 25 insertions(+), 10 deletions(-)
> rename drivers/hwtracing/coresight/{coresight.c => coresight-core.c} (99%)
>
> diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> index 181a44ea2d61..c05b265f7731 100644
> --- a/drivers/hwtracing/coresight/Kconfig
> +++ b/drivers/hwtracing/coresight/Kconfig
> @@ -2,7 +2,7 @@
> # Coresight configuration
> #
> menuconfig CORESIGHT
> - bool "CoreSight Tracing Support"
> + tristate "CoreSight Tracing Support"
> select ARM_AMBA
> select PERF_EVENTS
> help
> @@ -12,6 +12,9 @@ menuconfig CORESIGHT
> specification and configure the right series of components when a
> trace source gets enabled.
>
> + To compile this driver as a module, choose M here: the
> + module will be called coresight.
> +
> if CORESIGHT
> config CORESIGHT_LINKS_AND_SINKS
> tristate "CoreSight Link and Sink drivers"
> diff --git a/drivers/hwtracing/coresight/Makefile b/drivers/hwtracing/coresight/Makefile
> index 45d7a0f34170..ed2d4bcb017b 100644
> --- a/drivers/hwtracing/coresight/Makefile
> +++ b/drivers/hwtracing/coresight/Makefile
> @@ -2,8 +2,11 @@
> #
> # Makefile for CoreSight drivers.
> #
> -obj-$(CONFIG_CORESIGHT) += coresight.o coresight-etm-perf.o
> -obj-$(CONFIG_OF) += of_coresight.o
> +obj-$(CONFIG_CORESIGHT) += coresight.o
> +coresight-objs := coresight-core.o coresight-etm-perf.o
> +ifeq ($(CONFIG_OF), y)
> +coresight-objs += of_coresight.o
> +endif
> obj-$(CONFIG_CORESIGHT_LINK_AND_SINK_TMC) += coresight-tmc.o
> coresight-tmc-objs := coresight-tmc-core.o coresight-tmc-etf.o \
> coresight-tmc-etr.o
> diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight-core.c
> similarity index 99%
> rename from drivers/hwtracing/coresight/coresight.c
> rename to drivers/hwtracing/coresight/coresight-core.c
> index 1c941351f1d1..f96258de1e9b 100644
> --- a/drivers/hwtracing/coresight/coresight.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -948,12 +948,6 @@ struct bus_type coresight_bustype = {
> .name = "coresight",
> };
>
> -static int __init coresight_init(void)
> -{
> - return bus_register(&coresight_bustype);
> -}
> -postcore_initcall(coresight_init);
> -
> struct coresight_device *coresight_register(struct coresight_desc *desc)
> {
> int i;
> diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c b/drivers/hwtracing/coresight/coresight-etm-perf.c
> index 0fe7e43ea1c4..ceac9aee4a82 100644
> --- a/drivers/hwtracing/coresight/coresight-etm-perf.c
> +++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
> @@ -472,6 +472,10 @@ static int __init etm_perf_init(void)
> {
> int ret;
>
> + ret = bus_register(&coresight_bustype);
> + if (ret)
> + return ret;
> +
> etm_pmu.capabilities = PERF_PMU_CAP_EXCLUSIVE;
>
> etm_pmu.attr_groups = etm_pmu_attr_groups;
> @@ -494,4 +498,15 @@ static int __init etm_perf_init(void)
>
> return ret;
> }
> -device_initcall(etm_perf_init);
> +postcore_initcall(etm_perf_init);
> +
> +static void __exit etm_perf_exit(void)
> +{
> + perf_pmu_unregister(&etm_pmu);
> + bus_unregister(&coresight_bustype);
> +}
> +module_exit(etm_perf_exit);
I see the perf functionality as an accessory to the core rather than
the other way around. Initialisation in the core code should be
driving the PMU registration.
> +
> +MODULE_AUTHOR("Mathieu Poirier <mathieu.poirier@linaro.org>");
> +MODULE_DESCRIPTION("Arm CoreSight tracer driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.17.0
>
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Mathieu Poirier @ 2018-06-07 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39d1089f-585d-bc19-2ecd-c9c9c812f85f@arm.com>
On 7 June 2018 at 15:10, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 06/07/2018 06:13 PM, Kim Phillips wrote:
>>
>> On Thu, 7 Jun 2018 11:07:15 +0100
>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>
>>> On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote:
>>>>
>>>> On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote:
>>>>>
>>>>> On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote:
>>>>>>
>>>>>> On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote:
>>>>>>>
>>>>>>> Hi Greg,
>>>>>>>
>>>>>>> On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote:
>>>>>>>>
>>>>>>>> On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote:
>>>>>>>>>
>>>>>>>>> On Wed, 6 Jun 2018 10:46:36 +0100
>>>>>>>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Increment the refcnt for driver modules in current use by
>>>>>>>>>>>> calling
>>>>>>>>>>>> module_get in coresight_build_path and module_put in
>>>>>>>>>>>> release_path.
>>>>>>>>>>>>
>>>>>>>>>>>> This prevents driver modules from being unloaded when they are
>>>>>>>>>>>> in use,
>>>>>>>>>>>> either in sysfs or perf mode.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Why does it matter? Shouldn't you be allowed to remove any
>>>>>>>>>>> module at
>>>>>>>>>>> any point in time, much like a networking driver?
>>>>>>>
>>>>>>>
>>>>>>> The user doesn't have an explicit refcount on the individual
>>>>>>> components
>>>>>>> in a trace session. So, when a trace session is in progress, it is as
>>>>>>> good as having a "file" open on each component that is part of the
>>>>>>> active trace session. So, we don't want the driver to be removed when
>>>>>>> the component is being used in the trace collection.
>>>>>>
>>>>>>
>>>>>> Why not? What's wrong with that happening and then the trace
>>>>>> collection
>>>>>> starts failing with -ENODEV or something?
>>>>>
>>>>>
>>>>> May be I am missing something here. Can we allow the driver to be
>>>>> removed
>>>>> when one of its device is "turned ON" and we need the same
>>>>> driver to "turn it OFF" when the session ends ? To make a better
>>>>> comparison :
>>>>>
>>>>> Can we unload a usb_mass_storage module when a USB disk(which uses the
>>>>> module driver) is mounted and is being used ? I believe, the module
>>>>> will eventually get unloaded when we unmount the disk, if someone did
>>>>> a unload.
>>>>
>>>>
>>>> No, mount causes the module count to be incrememted. Mount and
>>>> "open/close" are the old-school way of doing module reference counting.
>>>>
>>>> Look at how network drivers work today, you can unload any network
>>>> driver even if there is a valid network connection "up and running"
>>>> attached to it. It just gets torn down when that request happens.
>>>
>>>
>>> Ok, that makes more sense now. Thanks for the hints. However, it doesn't
>>> look that easy from the coresight point due to the way the devices are
>>> used in an interconnected manner which could be part of multiple trace
>>> sessions.
>>>
>>> e.g, a funnel could be part of two independent trace sessions with
>>> different sets of sources/sinks. Tearing down the trace sessions is
>>> going to be a difficult task unless we make drastic changes to the PMU
>>> framework itself. But will see, what best we can do to make it modern
>>> :-)
>>>>
>>>>
>>>>> We have a similar situation here. The only difference is the driver is
>>>>> referenced only when one of its device is in a trace session.
>>>>
>>>>
>>>> I understand, I'm saying that you have to be very careful when messing
>>>> around with module reference counts to get it correct and perhaps you
>>>> should just change your design to not care about module reference counts
>>>> at all, like networking did 15+ years ago.
>>>>
>>>> Let's learn from the good examples in our past (like networking), and
>>>> not like the older bad examples (like mount/files).
>>>>
>>>>>> Remember, removing a kernel module is something that only happens very
>>>>>> rarely, and is an explicit choice by someone with root permissions.
>>>>>> If
>>>>>> you want to remove that module, it should be able to go, as you know
>>>>>> what you are doing at that point in time.
>>>>>
>>>>>
>>>>> Right, but when a device is "in use" can we do that ? I thought the
>>>>> user
>>>>> will get a module is in use or busy, error.
>>>>
>>>>
>>>> Try it on networking today :)
>>>>
>>>>>> Don't try to "protect the user from themselves" here, they want to
>>>>>> shoot
>>>>>> their foot, make it hurt if they are aiming it there :)
>>>>>>
>>>>>
>>>>> The module_get/put added here are only triggered when we start a trace
>>>>> session, where we build a path for the current session from the
>>>>> configured
>>>>> "source" to the configured "sink" and the path is destroyed
>>>>> at the end of the trace session. i.e, the path is not a permanent
>>>>> thing.
>>>>> It is constructed per session. So it is perfectly possible to remove a
>>>>> device in between trace sessions.
>>>>
>>>>
>>>> That's fine, but again, just be careful to get this correct. The patch
>>>> I reviewed did not seem to do that.
>>>
>>>
>>> Thanks for the useful suggestions, we will explore this more.
>
>
> Kim,
>
>>
>> I'm going to assume the series is still valid after this discussion,
>> since technically just this patch can get dropped, and the user is able
>> to shoot themselves in the foot.
>
>
> That doesn't mean the kernel can panic() if the user decided to unload the
> module while the trace session is in progress. It only means that
> the trace session could be stopped in between in the worst case. But
> nothing more harmful to the system.
>
>> This series is for development purposes, after all.
>
>
> Do you mean that this series is for internal development purposes and not
> upstream ? Making the drivers modular are always helpful, especially for
> something related to tracing, that allows the module to be unloaded after
> use. So, it would be good to have this series in, but in a manner which is
> usable and doesn't cause harm to the overall system usage.
Correct, we can't have a patchset that generates a kernel panic.
>
> I think the summary of the discussion is that we need more robust code
> to handle the situation, which also allows unloading the modules without
> any trouble.
The tricky part is the "unloading without any trouble". The first
thing to so is if the driver is being used, the _remove() functions
need to go through the same process as it would under normal
condition. That will allow to reinsert the module and have a fairly
good level of assurance that things will work properly.
Looking at things a little closer all the interconnection dependencies
in the core are done using a csdev and a lot of the current code is
already checking for a NULL condition (more checks may be needed with
the introduction of this set). The real problem is with the "path"
used to keep track of the devices taking part in active sessions.
Those can be accessed when a process is swapped in and out, mandating
something fast and efficient. One thing we could do is in a path,
keep track of a reference on csdev rather than make a copy of their
addresses. That way the _remove() functions could simply set those to
NULL, making it easy to deal with.
>
> Cheers
>
> Suzuki
>
>>
>> Let me know if I'm missing something.
>>
>> Thanks,
>>
>> Kim
>>
>
^ permalink raw reply
* [PATCH v4 05/14] coresight: get/put module in coresight_build/release_path
From: Suzuki K Poulose @ 2018-06-07 21:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607121304.017d1d6804466050dd5c0af2@arm.com>
On 06/07/2018 06:13 PM, Kim Phillips wrote:
> On Thu, 7 Jun 2018 11:07:15 +0100
> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
>> On 06/07/2018 10:53 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Jun 07, 2018 at 10:32:21AM +0100, Suzuki K Poulose wrote:
>>>> On 06/07/2018 10:13 AM, Greg Kroah-Hartman wrote:
>>>>> On Thu, Jun 07, 2018 at 10:04:33AM +0100, Suzuki K Poulose wrote:
>>>>>> Hi Greg,
>>>>>>
>>>>>> On 06/07/2018 09:34 AM, Greg Kroah-Hartman wrote:
>>>>>>> On Wed, Jun 06, 2018 at 03:55:01PM -0500, Kim Phillips wrote:
>>>>>>>> On Wed, 6 Jun 2018 10:46:36 +0100
>>>>>>>> Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>>>>>>>>
>>>>>>>>> On 06/06/2018 09:24 AM, Greg Kroah-Hartman wrote:
>>>>>>>>>> On Tue, Jun 05, 2018 at 04:07:01PM -0500, Kim Phillips wrote:
>>>>>>>>>>> Increment the refcnt for driver modules in current use by calling
>>>>>>>>>>> module_get in coresight_build_path and module_put in release_path.
>>>>>>>>>>>
>>>>>>>>>>> This prevents driver modules from being unloaded when they are in use,
>>>>>>>>>>> either in sysfs or perf mode.
>>>>>>>>>>
>>>>>>>>>> Why does it matter? Shouldn't you be allowed to remove any module at
>>>>>>>>>> any point in time, much like a networking driver?
>>>>>>
>>>>>> The user doesn't have an explicit refcount on the individual components
>>>>>> in a trace session. So, when a trace session is in progress, it is as
>>>>>> good as having a "file" open on each component that is part of the
>>>>>> active trace session. So, we don't want the driver to be removed when
>>>>>> the component is being used in the trace collection.
>>>>>
>>>>> Why not? What's wrong with that happening and then the trace collection
>>>>> starts failing with -ENODEV or something?
>>>>
>>>> May be I am missing something here. Can we allow the driver to be removed
>>>> when one of its device is "turned ON" and we need the same
>>>> driver to "turn it OFF" when the session ends ? To make a better
>>>> comparison :
>>>>
>>>> Can we unload a usb_mass_storage module when a USB disk(which uses the
>>>> module driver) is mounted and is being used ? I believe, the module
>>>> will eventually get unloaded when we unmount the disk, if someone did
>>>> a unload.
>>>
>>> No, mount causes the module count to be incrememted. Mount and
>>> "open/close" are the old-school way of doing module reference counting.
>>>
>>> Look at how network drivers work today, you can unload any network
>>> driver even if there is a valid network connection "up and running"
>>> attached to it. It just gets torn down when that request happens.
>>
>> Ok, that makes more sense now. Thanks for the hints. However, it doesn't
>> look that easy from the coresight point due to the way the devices are
>> used in an interconnected manner which could be part of multiple trace
>> sessions.
>>
>> e.g, a funnel could be part of two independent trace sessions with
>> different sets of sources/sinks. Tearing down the trace sessions is
>> going to be a difficult task unless we make drastic changes to the PMU
>> framework itself. But will see, what best we can do to make it modern
>> :-)
>>>
>>>> We have a similar situation here. The only difference is the driver is
>>>> referenced only when one of its device is in a trace session.
>>>
>>> I understand, I'm saying that you have to be very careful when messing
>>> around with module reference counts to get it correct and perhaps you
>>> should just change your design to not care about module reference counts
>>> at all, like networking did 15+ years ago.
>>>
>>> Let's learn from the good examples in our past (like networking), and
>>> not like the older bad examples (like mount/files).
>>>
>>>>> Remember, removing a kernel module is something that only happens very
>>>>> rarely, and is an explicit choice by someone with root permissions. If
>>>>> you want to remove that module, it should be able to go, as you know
>>>>> what you are doing at that point in time.
>>>>
>>>> Right, but when a device is "in use" can we do that ? I thought the user
>>>> will get a module is in use or busy, error.
>>>
>>> Try it on networking today :)
>>>
>>>>> Don't try to "protect the user from themselves" here, they want to shoot
>>>>> their foot, make it hurt if they are aiming it there :)
>>>>>
>>>>
>>>> The module_get/put added here are only triggered when we start a trace
>>>> session, where we build a path for the current session from the configured
>>>> "source" to the configured "sink" and the path is destroyed
>>>> at the end of the trace session. i.e, the path is not a permanent thing.
>>>> It is constructed per session. So it is perfectly possible to remove a
>>>> device in between trace sessions.
>>>
>>> That's fine, but again, just be careful to get this correct. The patch
>>> I reviewed did not seem to do that.
>>
>> Thanks for the useful suggestions, we will explore this more.
Kim,
>
> I'm going to assume the series is still valid after this discussion,
> since technically just this patch can get dropped, and the user is able
> to shoot themselves in the foot.
That doesn't mean the kernel can panic() if the user decided to unload
the module while the trace session is in progress. It only means that
the trace session could be stopped in between in the worst case. But
nothing more harmful to the system.
> This series is for development purposes, after all.
Do you mean that this series is for internal development purposes and
not upstream ? Making the drivers modular are always helpful, especially
for something related to tracing, that allows the module to be unloaded
after use. So, it would be good to have this series in, but in a manner
which is usable and doesn't cause harm to the overall system usage.
I think the summary of the discussion is that we need more robust code
to handle the situation, which also allows unloading the modules without
any trouble.
Cheers
Suzuki
>
> Let me know if I'm missing something.
>
> Thanks,
>
> Kim
>
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gx: fix ATF reserved memory region
From: Kevin Hilman @ 2018-06-07 20:55 UTC (permalink / raw)
To: linux-arm-kernel
Vendor firmware/uboot has different reserved regions depending on
firmware version, but current codebase reserves the same regions on
GXL and GXBB, so move the additional reserved memory region to common
.dtsi.
Found when putting a recent vendor u-boot on meson-gxbb-p200.
Recommended-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 8 --------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index b003f324ca31..b8dc4dbb391b 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -35,6 +35,12 @@
no-map;
};
+ /* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon_reserved_alt: secmon at 5000000 {
+ reg = <0x0 0x05000000 0x0 0x300000>;
+ no-map;
+ };
+
linux,cma {
compatible = "shared-dma-pool";
reusable;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index 27538eea547b..c87a80e9bcc6 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -13,14 +13,6 @@
/ {
compatible = "amlogic,meson-gxl";
- reserved-memory {
- /* Alternate 3 MiB reserved for ARM Trusted Firmware (BL31) */
- secmon_reserved_alt: secmon at 5000000 {
- reg = <0x0 0x05000000 0x0 0x300000>;
- no-map;
- };
- };
-
soc {
usb0: usb at c9000000 {
status = "disabled";
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: sdm845: Enable debug UART and I2C10 on sdm845-mtp
From: Douglas Anderson @ 2018-06-07 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180607204608.27688-1-dianders@chromium.org>
The debug UART is very useful to have. I2C10 is enabled as an example
of a I2C port we can talk on for now. Eventually we'll want to put
peripherals under it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845-mtp.dts | 52 +++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
index 979ab49913f1..e1eda143a725 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-mtp.dts
@@ -12,4 +12,56 @@
/ {
model = "Qualcomm Technologies, Inc. SDM845 MTP";
compatible = "qcom,sdm845-mtp";
+
+ aliases {
+ serial0 = &uart9;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&i2c10 {
+ status = "okay";
+ clock-frequency = <400000>;
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&uart9 {
+ status = "okay";
+};
+
+/* PINCTRL - additions to nodes defined in sdm845.dtsi */
+
+&qup_i2c10_default {
+ pinconf {
+ pins = "gpio55", "gpio56";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&qup_uart9_default {
+ pinconf-tx {
+ pins = "gpio4";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pinconf-rx {
+ pins = "gpio5";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+};
+
+&qup_uart9_sleep {
+ pinconf {
+ pins = "gpio4", "gpio5";
+ bias-pull-down;
+ };
};
--
2.17.1.1185.g55be947832-goog
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: qcom: sdm845: Add I2C, SPI, and UART9 nodes
From: Douglas Anderson @ 2018-06-07 20:46 UTC (permalink / raw)
To: linux-arm-kernel
This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
ports, and UART9. Note that I2C / SPI / UART are a bit strange on
sdm845 because each "serial engine" has 4 pins associated with it and
depending on which firmware has been loaded into the serial engine
(loaded by the BIOS) the serial engine can behave like an I2C port, a
SPI port, or a UART. As per the landed bindings that means that we
need to create one node for each possible mode that the port could be
in. With 16 serial engines that means 16 x 3 = 48 nodes.
We get away with only creating 33 nodes for now because it seems very
likely that SDM845-based boards will actually all use the same UART
(UART 9) for debug purposes. While another UART could be used for
something like Bluetooth communication we can cross that path when we
come to it. Some documentation that I saw implied that using a UART
for "high speed" communications actually needs yet another different
serial engine firmware anyway.
Note that quick measurements adding all these nodes adds ~10k of extra
space per dtb that they're included with. If this becomes a problem
we may need to think of a different way to structure this so that
boards only get the nodes they need (or figure out how to get dtc to
strip 'disabled' nodes). For now it seems OK.
These nodes were programmatically generated with a fairly dumb python
script. See http://crosreview.com/1091631 for the source.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1013 ++++++++++++++++++++++++++
1 file changed, 1013 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb3c995..2dc5c7dcc9aa 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -5,6 +5,7 @@
* Copyright (c) 2018, The Linux Foundation. All rights reserved.
*/
+#include <dt-bindings/clock/qcom,gcc-sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
/ {
@@ -13,6 +14,41 @@
#address-cells = <2>;
#size-cells = <2>;
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ i2c4 = &i2c4;
+ i2c5 = &i2c5;
+ i2c6 = &i2c6;
+ i2c7 = &i2c7;
+ i2c8 = &i2c8;
+ i2c9 = &i2c9;
+ i2c10 = &i2c10;
+ i2c11 = &i2c11;
+ i2c12 = &i2c12;
+ i2c13 = &i2c13;
+ i2c14 = &i2c14;
+ i2c15 = &i2c15;
+ spi0 = &spi0;
+ spi1 = &spi1;
+ spi2 = &spi2;
+ spi3 = &spi3;
+ spi4 = &spi4;
+ spi5 = &spi5;
+ spi6 = &spi6;
+ spi7 = &spi7;
+ spi8 = &spi8;
+ spi9 = &spi9;
+ spi10 = &spi10;
+ spi11 = &spi11;
+ spi12 = &spi12;
+ spi13 = &spi13;
+ spi14 = &spi14;
+ spi15 = &spi15;
+ };
+
chosen { };
memory at 80000000 {
@@ -206,6 +242,489 @@
#power-domain-cells = <1>;
};
+ qupv3_id_0: geniqup at 8c0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0x8c0000 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ i2c0: i2c at 880000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x880000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c0_default>;
+ pinctrl-1 = <&qup_i2c0_sleep>;
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi0: spi at 880000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x880000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi0_default>;
+ pinctrl-1 = <&qup_spi0_sleep>;
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 884000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x884000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c1_default>;
+ pinctrl-1 = <&qup_i2c1_sleep>;
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi1: spi at 884000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x884000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi1_default>;
+ pinctrl-1 = <&qup_spi1_sleep>;
+ interrupts = <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c2: i2c at 888000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x888000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c2_default>;
+ pinctrl-1 = <&qup_i2c2_sleep>;
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi2: spi at 888000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x888000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi2_default>;
+ pinctrl-1 = <&qup_spi2_sleep>;
+ interrupts = <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c3: i2c at 88c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x88c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c3_default>;
+ pinctrl-1 = <&qup_i2c3_sleep>;
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi3: spi at 88c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x88c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi3_default>;
+ pinctrl-1 = <&qup_spi3_sleep>;
+ interrupts = <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c at 890000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x890000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c4_default>;
+ pinctrl-1 = <&qup_i2c4_sleep>;
+ interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi4: spi at 890000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x890000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi4_default>;
+ pinctrl-1 = <&qup_spi4_sleep>;
+ interrupts = <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c at 894000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x894000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c5_default>;
+ pinctrl-1 = <&qup_i2c5_sleep>;
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi5: spi at 894000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x894000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi5_default>;
+ pinctrl-1 = <&qup_spi5_sleep>;
+ interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c6: i2c at 898000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x898000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c6_default>;
+ pinctrl-1 = <&qup_i2c6_sleep>;
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi6: spi at 898000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x898000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi6_default>;
+ pinctrl-1 = <&qup_spi6_sleep>;
+ interrupts = <GIC_SPI 607 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c7: i2c at 89c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0x89c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c7_default>;
+ pinctrl-1 = <&qup_i2c7_sleep>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi7: spi at 89c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0x89c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP0_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi7_default>;
+ pinctrl-1 = <&qup_spi7_sleep>;
+ interrupts = <GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ qupv3_id_1: geniqup at ac0000 {
+ compatible = "qcom,geni-se-qup";
+ reg = <0xac0000 0x6000>;
+ clock-names = "m-ahb", "s-ahb";
+ clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>,
+ <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ status = "disabled";
+
+ i2c8: i2c at a80000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa80000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c8_default>;
+ pinctrl-1 = <&qup_i2c8_sleep>;
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi8: spi at a80000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa80000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S0_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi8_default>;
+ pinctrl-1 = <&qup_spi8_sleep>;
+ interrupts = <GIC_SPI 353 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c9: i2c at a84000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c9_default>;
+ pinctrl-1 = <&qup_i2c9_sleep>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi9: spi at a84000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi9_default>;
+ pinctrl-1 = <&qup_spi9_sleep>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ uart9: serial at a84000 {
+ compatible = "qcom,geni-debug-uart";
+ reg = <0xa84000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S1_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_uart9_default>;
+ pinctrl-1 = <&qup_uart9_sleep>;
+ interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ i2c10: i2c at a88000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c10_default>;
+ pinctrl-1 = <&qup_i2c10_sleep>;
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi10: spi at a88000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa88000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S2_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi10_default>;
+ pinctrl-1 = <&qup_spi10_sleep>;
+ interrupts = <GIC_SPI 355 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c11: i2c at a8c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa8c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c11_default>;
+ pinctrl-1 = <&qup_i2c11_sleep>;
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi11: spi at a8c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa8c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S3_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi11_default>;
+ pinctrl-1 = <&qup_spi11_sleep>;
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c12: i2c at a90000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa90000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c12_default>;
+ pinctrl-1 = <&qup_i2c12_sleep>;
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi12: spi at a90000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa90000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi12_default>;
+ pinctrl-1 = <&qup_spi12_sleep>;
+ interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c13: i2c at a94000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa94000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c13_default>;
+ pinctrl-1 = <&qup_i2c13_sleep>;
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi13: spi at a94000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa94000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S5_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi13_default>;
+ pinctrl-1 = <&qup_spi13_sleep>;
+ interrupts = <GIC_SPI 358 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c14: i2c at a98000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa98000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c14_default>;
+ pinctrl-1 = <&qup_i2c14_sleep>;
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi14: spi at a98000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa98000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S6_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi14_default>;
+ pinctrl-1 = <&qup_spi14_sleep>;
+ interrupts = <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c15: i2c at a9c000 {
+ compatible = "qcom,geni-i2c";
+ reg = <0xa9c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_i2c15_default>;
+ pinctrl-1 = <&qup_i2c15_sleep>;
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ spi15: spi at a9c000 {
+ compatible = "qcom,geni-spi";
+ reg = <0xa9c000 0x4000>;
+ clock-names = "se";
+ clocks = <&gcc GCC_QUPV3_WRAP1_S7_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_spi15_default>;
+ pinctrl-1 = <&qup_spi15_sleep>;
+ interrupts = <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
tcsr_mutex_regs: syscon at 1f40000 {
compatible = "syscon";
reg = <0x1f40000 0x40000>;
@@ -219,6 +738,500 @@
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+
+ qup_i2c0_default: qup-i2c0-default {
+ pinmux {
+ pins = "gpio0", "gpio1";
+ function = "qup0";
+ };
+ };
+
+ qup_i2c0_sleep: qup-i2c0-sleep {
+ pinmux {
+ pins = "gpio0", "gpio1";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c1_default: qup-i2c1-default {
+ pinmux {
+ pins = "gpio17", "gpio18";
+ function = "qup1";
+ };
+ };
+
+ qup_i2c1_sleep: qup-i2c1-sleep {
+ pinmux {
+ pins = "gpio17", "gpio18";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c2_default: qup-i2c2-default {
+ pinmux {
+ pins = "gpio27", "gpio28";
+ function = "qup2";
+ };
+ };
+
+ qup_i2c2_sleep: qup-i2c2-sleep {
+ pinmux {
+ pins = "gpio27", "gpio28";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c3_default: qup-i2c3-default {
+ pinmux {
+ pins = "gpio41", "gpio42";
+ function = "qup3";
+ };
+ };
+
+ qup_i2c3_sleep: qup-i2c3-sleep {
+ pinmux {
+ pins = "gpio41", "gpio42";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c4_default: qup-i2c4-default {
+ pinmux {
+ pins = "gpio89", "gpio90";
+ function = "qup4";
+ };
+ };
+
+ qup_i2c4_sleep: qup-i2c4-sleep {
+ pinmux {
+ pins = "gpio89", "gpio90";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c5_default: qup-i2c5-default {
+ pinmux {
+ pins = "gpio85", "gpio86";
+ function = "qup5";
+ };
+ };
+
+ qup_i2c5_sleep: qup-i2c5-sleep {
+ pinmux {
+ pins = "gpio85", "gpio86";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c6_default: qup-i2c6-default {
+ pinmux {
+ pins = "gpio45", "gpio46";
+ function = "qup6";
+ };
+ };
+
+ qup_i2c6_sleep: qup-i2c6-sleep {
+ pinmux {
+ pins = "gpio45", "gpio46";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c7_default: qup-i2c7-default {
+ pinmux {
+ pins = "gpio93", "gpio94";
+ function = "qup7";
+ };
+ };
+
+ qup_i2c7_sleep: qup-i2c7-sleep {
+ pinmux {
+ pins = "gpio93", "gpio94";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c8_default: qup-i2c8-default {
+ pinmux {
+ pins = "gpio65", "gpio66";
+ function = "qup8";
+ };
+ };
+
+ qup_i2c8_sleep: qup-i2c8-sleep {
+ pinmux {
+ pins = "gpio65", "gpio66";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c9_default: qup-i2c9-default {
+ pinmux {
+ pins = "gpio6", "gpio7";
+ function = "qup9";
+ };
+ };
+
+ qup_i2c9_sleep: qup-i2c9-sleep {
+ pinmux {
+ pins = "gpio6", "gpio7";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c10_default: qup-i2c10-default {
+ pinmux {
+ pins = "gpio55", "gpio56";
+ function = "qup10";
+ };
+ };
+
+ qup_i2c10_sleep: qup-i2c10-sleep {
+ pinmux {
+ pins = "gpio55", "gpio56";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c11_default: qup-i2c11-default {
+ pinmux {
+ pins = "gpio31", "gpio32";
+ function = "qup11";
+ };
+ };
+
+ qup_i2c11_sleep: qup-i2c11-sleep {
+ pinmux {
+ pins = "gpio31", "gpio32";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c12_default: qup-i2c12-default {
+ pinmux {
+ pins = "gpio49", "gpio50";
+ function = "qup12";
+ };
+ };
+
+ qup_i2c12_sleep: qup-i2c12-sleep {
+ pinmux {
+ pins = "gpio49", "gpio50";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c13_default: qup-i2c13-default {
+ pinmux {
+ pins = "gpio105", "gpio106";
+ function = "qup13";
+ };
+ };
+
+ qup_i2c13_sleep: qup-i2c13-sleep {
+ pinmux {
+ pins = "gpio105", "gpio106";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c14_default: qup-i2c14-default {
+ pinmux {
+ pins = "gpio33", "gpio34";
+ function = "qup14";
+ };
+ };
+
+ qup_i2c14_sleep: qup-i2c14-sleep {
+ pinmux {
+ pins = "gpio33", "gpio34";
+ function = "gpio";
+ };
+ };
+
+ qup_i2c15_default: qup-i2c15-default {
+ pinmux {
+ pins = "gpio81", "gpio82";
+ function = "qup15";
+ };
+ };
+
+ qup_i2c15_sleep: qup-i2c15-sleep {
+ pinmux {
+ pins = "gpio81", "gpio82";
+ function = "gpio";
+ };
+ };
+
+ qup_spi0_default: qup-spi0-default {
+ pinmux {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ function = "qup0";
+ };
+ };
+
+ qup_spi0_sleep: qup-spi0-sleep {
+ pinmux {
+ pins = "gpio0", "gpio1",
+ "gpio2", "gpio3";
+ function = "gpio";
+ };
+ };
+
+ qup_spi1_default: qup-spi1-default {
+ pinmux {
+ pins = "gpio17", "gpio18",
+ "gpio19", "gpio20";
+ function = "qup1";
+ };
+ };
+
+ qup_spi1_sleep: qup-spi1-sleep {
+ pinmux {
+ pins = "gpio17", "gpio18",
+ "gpio19", "gpio20";
+ function = "gpio";
+ };
+ };
+
+ qup_spi2_default: qup-spi2-default {
+ pinmux {
+ pins = "gpio27", "gpio28",
+ "gpio29", "gpio30";
+ function = "qup2";
+ };
+ };
+
+ qup_spi2_sleep: qup-spi2-sleep {
+ pinmux {
+ pins = "gpio27", "gpio28",
+ "gpio29", "gpio30";
+ function = "gpio";
+ };
+ };
+
+ qup_spi3_default: qup-spi3-default {
+ pinmux {
+ pins = "gpio41", "gpio42",
+ "gpio43", "gpio44";
+ function = "qup3";
+ };
+ };
+
+ qup_spi3_sleep: qup-spi3-sleep {
+ pinmux {
+ pins = "gpio41", "gpio42",
+ "gpio43", "gpio44";
+ function = "gpio";
+ };
+ };
+
+ qup_spi4_default: qup-spi4-default {
+ pinmux {
+ pins = "gpio89", "gpio90",
+ "gpio91", "gpio92";
+ function = "qup4";
+ };
+ };
+
+ qup_spi4_sleep: qup-spi4-sleep {
+ pinmux {
+ pins = "gpio89", "gpio90",
+ "gpio91", "gpio92";
+ function = "gpio";
+ };
+ };
+
+ qup_spi5_default: qup-spi5-default {
+ pinmux {
+ pins = "gpio85", "gpio86",
+ "gpio87", "gpio88";
+ function = "qup5";
+ };
+ };
+
+ qup_spi5_sleep: qup-spi5-sleep {
+ pinmux {
+ pins = "gpio85", "gpio86",
+ "gpio87", "gpio88";
+ function = "gpio";
+ };
+ };
+
+ qup_spi6_default: qup-spi6-default {
+ pinmux {
+ pins = "gpio45", "gpio46",
+ "gpio47", "gpio48";
+ function = "qup6";
+ };
+ };
+
+ qup_spi6_sleep: qup-spi6-sleep {
+ pinmux {
+ pins = "gpio45", "gpio46",
+ "gpio47", "gpio48";
+ function = "gpio";
+ };
+ };
+
+ qup_spi7_default: qup-spi7-default {
+ pinmux {
+ pins = "gpio93", "gpio94",
+ "gpio95", "gpio96";
+ function = "qup7";
+ };
+ };
+
+ qup_spi7_sleep: qup-spi7-sleep {
+ pinmux {
+ pins = "gpio93", "gpio94",
+ "gpio95", "gpio96";
+ function = "gpio";
+ };
+ };
+
+ qup_spi8_default: qup-spi8-default {
+ pinmux {
+ pins = "gpio65", "gpio66",
+ "gpio67", "gpio68";
+ function = "qup8";
+ };
+ };
+
+ qup_spi8_sleep: qup-spi8-sleep {
+ pinmux {
+ pins = "gpio65", "gpio66",
+ "gpio67", "gpio68";
+ function = "gpio";
+ };
+ };
+
+ qup_spi9_default: qup-spi9-default {
+ pinmux {
+ pins = "gpio6", "gpio7",
+ "gpio4", "gpio5";
+ function = "qup9";
+ };
+ };
+
+ qup_spi9_sleep: qup-spi9-sleep {
+ pinmux {
+ pins = "gpio6", "gpio7",
+ "gpio4", "gpio5";
+ function = "gpio";
+ };
+ };
+
+ qup_spi10_default: qup-spi10-default {
+ pinmux {
+ pins = "gpio55", "gpio56",
+ "gpio53", "gpio54";
+ function = "qup10";
+ };
+ };
+
+ qup_spi10_sleep: qup-spi10-sleep {
+ pinmux {
+ pins = "gpio55", "gpio56",
+ "gpio53", "gpio54";
+ function = "gpio";
+ };
+ };
+
+ qup_spi11_default: qup-spi11-default {
+ pinmux {
+ pins = "gpio31", "gpio32",
+ "gpio33", "gpio34";
+ function = "qup11";
+ };
+ };
+
+ qup_spi11_sleep: qup-spi11-sleep {
+ pinmux {
+ pins = "gpio31", "gpio32",
+ "gpio33", "gpio34";
+ function = "gpio";
+ };
+ };
+
+ qup_spi12_default: qup-spi12-default {
+ pinmux {
+ pins = "gpio49", "gpio50",
+ "gpio51", "gpio52";
+ function = "qup12";
+ };
+ };
+
+ qup_spi12_sleep: qup-spi12-sleep {
+ pinmux {
+ pins = "gpio49", "gpio50",
+ "gpio51", "gpio52";
+ function = "gpio";
+ };
+ };
+
+ qup_spi13_default: qup-spi13-default {
+ pinmux {
+ pins = "gpio105", "gpio106",
+ "gpio107", "gpio108";
+ function = "qup13";
+ };
+ };
+
+ qup_spi13_sleep: qup-spi13-sleep {
+ pinmux {
+ pins = "gpio105", "gpio106",
+ "gpio107", "gpio108";
+ function = "gpio";
+ };
+ };
+
+ qup_spi14_default: qup-spi14-default {
+ pinmux {
+ pins = "gpio33", "gpio34",
+ "gpio31", "gpio32";
+ function = "qup14";
+ };
+ };
+
+ qup_spi14_sleep: qup-spi14-sleep {
+ pinmux {
+ pins = "gpio33", "gpio34",
+ "gpio31", "gpio32";
+ function = "gpio";
+ };
+ };
+
+ qup_spi15_default: qup-spi15-default {
+ pinmux {
+ pins = "gpio81", "gpio82",
+ "gpio83", "gpio84";
+ function = "qup15";
+ };
+ };
+
+ qup_spi15_sleep: qup-spi15-sleep {
+ pinmux {
+ pins = "gpio81", "gpio82",
+ "gpio83", "gpio84";
+ function = "gpio";
+ };
+ };
+
+ qup_uart9_default: qup-uart9-default {
+ pinmux {
+ pins = "gpio4", "gpio5";
+ function = "qup9";
+ };
+ };
+
+ qup_uart9_sleep: qup-uart9-sleep {
+ pinmux {
+ pins = "gpio4", "gpio5";
+ function = "gpio";
+ };
+ };
};
spmi_bus: spmi at c440000 {
--
2.17.1.1185.g55be947832-goog
^ permalink raw reply related
* [PATCH v2 5/5] arm64: dts: renesas: condor/v3hsk: add DU/LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-07 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Define the Condor/V3HSK board dependent parts of the DU and LVDS device
nodes. Also add the device nodes for Thine THC63LVD1024 LVDS decoder and
Analog Devices ADV7511W HDMI transmitter...
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>
---
Changes in version 2:
- added the V3HSK DT update, reworded the description, renamed the patch;
- added a space between the HDMI node name and a brace.
arch/arm64/boot/dts/renesas/r8a77980-condor.dts | 106 +++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts | 120 ++++++++++++++++++++++++
2 files changed, 226 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
@@ -45,6 +45,56 @@
regulator-boot-on;
regulator-always-on;
};
+
+ d1_8v: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "D1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&d3_3v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ x1_clk: x1-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <148500000>;
+ };
};
&avb {
@@ -74,6 +124,13 @@
};
};
+&du {
+ clocks = <&cpg CPG_MOD 724>,
+ <&x1_clk>;
+ clock-names = "du.0", "dclkin.0";
+ status = "okay";
+};
+
&extal_clk {
clock-frequency = <16666666>;
};
@@ -102,6 +159,55 @@
gpio-controller;
#gpio-cells = <2>;
};
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&d1_8v>;
+ dvdd-supply = <&d1_8v>;
+ pvdd-supply = <&d1_8v>;
+ bgvdd-supply = <&d1_8v>;
+ dvdd-3v-supply = <&d3_3v>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
};
&mmc0 {
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980-v3hsk.dts
@@ -27,6 +27,63 @@
/* first 128MB is reserved for secure area. */
reg = <0 0x48000000 0 0x78000000>;
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
+
+ lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+ vcc-supply = <&vcc3v3_d5>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ thc63lvd1024_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port at 2 {
+ reg = <2>;
+ thc63lvd1024_out: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
+ };
+ };
+
+ vcc1v8_d4: regulator-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC1V8_D4";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc3v3_d5: regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC3V3_D5";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&du {
+ status = "okay";
};
&extal_clk {
@@ -53,6 +110,64 @@
};
};
+&lvds0 {
+ status = "okay";
+
+ ports {
+ port at 1 {
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in>;
+ };
+ };
+ };
+};
+
+&i2c0 {
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ #sound-dai-cells = <0>;
+ reg = <0x39>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&vcc1v8_d4>;
+ dvdd-supply = <&vcc1v8_d4>;
+ pvdd-supply = <&vcc1v8_d4>;
+ bgvdd-supply = <&vcc1v8_d4>;
+ dvdd-3v-supply = <&vcc3v3_d5>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&thc63lvd1024_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+};
+
&pfc {
gether_pins: gether {
groups = "gether_mdio_a", "gether_rgmii",
@@ -60,6 +175,11 @@
function = "gether";
};
+ i2c0_pins: i2c0 {
+ groups = "i2c0";
+ function = "i2c0";
+ };
+
scif0_pins: scif0 {
groups = "scif0_data";
function = "scif0";
^ permalink raw reply
* [PATCH v2 4/5] arm64: dts: renesas: r8a77980: add LVDS support
From: Sergei Shtylyov @ 2018-06-07 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Define the generic R8A77980 part of the LVDS device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
arch/arm64/boot/dts/renesas/r8a77980.dtsi | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -696,6 +696,35 @@
port at 1 {
reg = <1>;
du_out_lvds0: endpoint {
+ remote-endpoint = <&lvds0_in>;
+ };
+ };
+ };
+ };
+
+ lvds0: lvds-encoder at feb90000 {
+ compatible = "renesas,r8a77980-lvds";
+ reg = <0 0xfeb90000 0 0x14>;
+ clocks = <&cpg CPG_MOD 727>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 727>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ lvds0_in: endpoint {
+ remote-endpoint =
+ <&du_out_lvds0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ lvds0_out: endpoint {
};
};
};
^ permalink raw reply
* [PATCH v2 3/5] arm64: dts: renesas: r8a77980: add DU support
From: Sergei Shtylyov @ 2018-06-07 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Define the generic R8A77980 part of the DU device node.
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.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -671,6 +671,36 @@
resets = <&cpg 603>;
};
+ du: display at feb00000 {
+ compatible = "renesas,du-r8a77980",
+ "renesas,du-r8a77970";
+ reg = <0 0xfeb00000 0 0x80000>;
+ interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 724>;
+ clock-names = "du.0";
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 724>;
+ vsps = <&vspd0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ du_out_lvds0: endpoint {
+ };
+ };
+ };
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH v2 2/5] arm64: dts: renesas: r8a77980: add VSPD support
From: Sergei Shtylyov @ 2018-06-07 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Describe VSPD0 in the R8A77980 device tree; it will be used by DU in
the next patch...
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.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,16 @@
resets = <&cpg 408>;
};
+ vspd0: vsp at fea20000 {
+ compatible = "renesas,vsp2";
+ reg = <0 0xfea20000 0 0x4000>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 623>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 623>;
+ renesas,fcp = <&fcpvd0>;
+ };
+
fcpvd0: fcp at fea27000 {
compatible = "renesas,fcpv";
reg = <0 0xfea27000 0 0x200>;
^ permalink raw reply
* [PATCH v2 1/5] arm64: dts: renesas: r8a77980: add FCPVD support
From: Sergei Shtylyov @ 2018-06-07 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <390fabf0-4caf-1600-3780-1893207d94f7@cogentembedded.com>
Describe FCPVD0 in the R8A77980 device tree; it will be used by VSPD0 in
the next patch...
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.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
Index: renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
===================================================================
--- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
+++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
@@ -653,6 +653,14 @@
resets = <&cpg 408>;
};
+ fcpvd0: fcp at fea27000 {
+ compatible = "renesas,fcpv";
+ reg = <0 0xfea27000 0 0x200>;
+ clocks = <&cpg CPG_MOD 603>;
+ power-domains = <&sysc R8A77980_PD_ALWAYS_ON>;
+ resets = <&cpg 603>;
+ };
+
prr: chipid at fff00044 {
compatible = "renesas,prr";
reg = <0 0xfff00044 0 4>;
^ permalink raw reply
* [PATCH v2 0/5] Add R8A77980/Condor/V3HSK LVDS/HDMI support
From: Sergei Shtylyov @ 2018-06-07 20:17 UTC (permalink / raw)
To: linux-arm-kernel
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
WBR, Sergei
^ permalink raw reply
* [PATCH v4 2/2] arm/arm64: KVM: Add KVM_GET/SET_VCPU_EVENTS
From: Dongjiu Geng @ 2018-06-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528401833-29963-1-git-send-email-gengdongjiu@huawei.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
---
change since v3:
1. Fix the memset() issue in the kvm_arm_vcpu_get_events()
change since v2:
1. Add kvm_vcpu_events structure definition for arm platform to avoid the build errors.
change since v1:
Address Marc's comments, thanks Marc's review
1. serror_has_esr always true when ARM64_HAS_RAS_EXTN is set
2. remove Spurious blank line in kvm_arm_vcpu_set_events()
3. rename pend_guest_serror() to kvm_set_sei_esr()
4. Make kvm_arm_vcpu_get_events() did all the work rather than having this split responsibility.
5. using sizeof(events) instead of sizeof(struct kvm_vcpu_events)
this series patch is separated from https://www.spinics.net/lists/kvm/msg168917.html
The user space patch is here: https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg06965.html
change since V12:
1. change (vcpu->arch.hcr_el2 & HCR_VSE) to !!(vcpu->arch.hcr_el2 & HCR_VSE) in kvm_arm_vcpu_get_events()
Change since V11:
Address James's comments, thanks James
1. Align the struct of kvm_vcpu_events to 64 bytes
2. Avoid exposing the stale ESR value in the kvm_arm_vcpu_get_events()
3. Change variables 'injected' name to 'serror_pending' in the kvm_arm_vcpu_set_events()
4. Change to sizeof(events) from sizeof(struct kvm_vcpu_events) in kvm_arch_vcpu_ioctl()
Change since V10:
Address James's comments, thanks James
1. Merge the helper function with the user.
2. Move the ISS_MASK into pend_guest_serror() to clear top bits
3. Make kvm_vcpu_events struct align to 4 bytes
4. Add something check in the kvm_arm_vcpu_set_events()
5. Check kvm_arm_vcpu_get/set_events()'s return value.
6. Initialise kvm_vcpu_events to 0 so that padding transferred to user-space doesn't
contain kernel stack.
---
Documentation/virtual/kvm/api.txt | 31 ++++++++++++++++++++++++++++---
arch/arm/include/asm/kvm_host.h | 6 ++++++
arch/arm/include/uapi/asm/kvm.h | 12 ++++++++++++
arch/arm/kvm/guest.c | 12 ++++++++++++
arch/arm64/include/asm/kvm_emulate.h | 5 +++++
arch/arm64/include/asm/kvm_host.h | 7 +++++++
arch/arm64/include/uapi/asm/kvm.h | 13 +++++++++++++
arch/arm64/kvm/guest.c | 36 ++++++++++++++++++++++++++++++++++++
arch/arm64/kvm/inject_fault.c | 6 +++---
arch/arm64/kvm/reset.c | 1 +
virt/kvm/arm/arm.c | 19 +++++++++++++++++++
11 files changed, 142 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index fdac969..8896737 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -835,11 +835,13 @@ struct kvm_clock_data {
Capability: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (out)
Returns: 0 on success, -1 on error
+X86:
+
Gets currently pending exceptions, interrupts, and NMIs as well as related
states of the vcpu.
@@ -881,15 +883,32 @@ Only two fields are defined in the flags field:
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
smi contains a valid state.
+ARM, ARM64:
+
+Gets currently pending SError exceptions as well as related states of the vcpu.
+
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
4.32 KVM_SET_VCPU_EVENTS
-Capability: KVM_CAP_VCPU_EVENTS
+Capebility: KVM_CAP_VCPU_EVENTS
Extended by: KVM_CAP_INTR_SHADOW
-Architectures: x86
+Architectures: x86, arm, arm64
Type: vm ioctl
Parameters: struct kvm_vcpu_event (in)
Returns: 0 on success, -1 on error
+X86:
+
Set pending exceptions, interrupts, and NMIs as well as related states of the
vcpu.
@@ -910,6 +929,12 @@ shall be written into the VCPU.
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
+ARM, ARM64:
+
+Set pending SError exceptions as well as related states of the vcpu.
+
+See KVM_GET_VCPU_EVENTS for the data structure.
+
4.33 KVM_GET_DEBUGREGS
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index c7c28c8..39f9901 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -213,6 +213,12 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
unsigned long kvm_call_hyp(void *hypfn, ...);
void force_vm_exit(const cpumask_t *mask);
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index caae484..c3e6975 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -124,6 +124,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm/kvm/guest.c b/arch/arm/kvm/guest.c
index a18f33e..c685f0e 100644
--- a/arch/arm/kvm/guest.c
+++ b/arch/arm/kvm/guest.c
@@ -261,6 +261,18 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ return -EINVAL;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
switch (read_cpuid_part()) {
diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
index 1dab3a9..18f61ff 100644
--- a/arch/arm64/include/asm/kvm_emulate.h
+++ b/arch/arm64/include/asm/kvm_emulate.h
@@ -81,6 +81,11 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
return (unsigned long *)&vcpu->arch.hcr_el2;
}
+static inline unsigned long vcpu_get_vsesr(struct kvm_vcpu *vcpu)
+{
+ return vcpu->arch.vsesr_el2;
+}
+
static inline void vcpu_set_vsesr(struct kvm_vcpu *vcpu, u64 vsesr)
{
vcpu->arch.vsesr_el2 = vsesr;
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 469de8a..357304a 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -335,6 +335,11 @@ unsigned long kvm_arm_num_regs(struct kvm_vcpu *vcpu);
int kvm_arm_copy_reg_indices(struct kvm_vcpu *vcpu, u64 __user *indices);
int kvm_arm_get_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
int kvm_arm_set_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg);
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events);
#define KVM_ARCH_WANT_MMU_NOTIFIER
int kvm_unmap_hva(struct kvm *kvm, unsigned long hva);
@@ -363,6 +368,8 @@ void handle_exit_early(struct kvm_vcpu *vcpu, struct kvm_run *run,
int kvm_perf_init(void);
int kvm_perf_teardown(void);
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 syndrome);
+
struct kvm_vcpu *kvm_mpidr_to_vcpu(struct kvm *kvm, unsigned long mpidr);
void __kvm_set_tpidr_el2(u64 tpidr_el2);
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index 04b3256..df4faee 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -39,6 +39,7 @@
#define __KVM_HAVE_GUEST_DEBUG
#define __KVM_HAVE_IRQ_LINE
#define __KVM_HAVE_READONLY_MEM
+#define __KVM_HAVE_VCPU_EVENTS
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
@@ -153,6 +154,18 @@ struct kvm_sync_regs {
struct kvm_arch_memory_slot {
};
+/* for KVM_GET/SET_VCPU_EVENTS */
+struct kvm_vcpu_events {
+ struct {
+ __u8 serror_pending;
+ __u8 serror_has_esr;
+ /* Align it to 8 bytes */
+ __u8 pad[6];
+ __u64 serror_esr;
+ } exception;
+ __u32 reserved[12];
+};
+
/* If you need to interpret the index values, here is the key: */
#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
#define KVM_REG_ARM_COPROC_SHIFT 16
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 56a0260..60028f7 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -289,6 +289,42 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
return -EINVAL;
}
+int kvm_arm_vcpu_get_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ memset(events, 0, sizeof(events));
+
+ events->exception.serror_pending = !!(vcpu->arch.hcr_el2 & HCR_VSE);
+ events->exception.serror_has_esr =
+ cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+
+ if (events->exception.serror_pending &&
+ events->exception.serror_has_esr)
+ events->exception.serror_esr = vcpu_get_vsesr(vcpu);
+ else
+ events->exception.serror_esr = 0;
+
+ return 0;
+}
+
+int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
+ struct kvm_vcpu_events *events)
+{
+ bool serror_pending = events->exception.serror_pending;
+ bool has_esr = events->exception.serror_has_esr;
+
+ if (serror_pending && has_esr) {
+ if (!cpus_have_const_cap(ARM64_HAS_RAS_EXTN))
+ return -EINVAL;
+
+ kvm_set_sei_esr(vcpu, events->exception.serror_esr);
+ } else if (serror_pending) {
+ kvm_inject_vabt(vcpu);
+ }
+
+ return 0;
+}
+
int __attribute_const__ kvm_target_cpu(void)
{
unsigned long implementor = read_cpuid_implementor();
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index d8e7165..a55e91d 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -164,9 +164,9 @@ void kvm_inject_undefined(struct kvm_vcpu *vcpu)
inject_undef64(vcpu);
}
-static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
+void kvm_set_sei_esr(struct kvm_vcpu *vcpu, u64 esr)
{
- vcpu_set_vsesr(vcpu, esr);
+ vcpu_set_vsesr(vcpu, esr & ESR_ELx_ISS_MASK);
*vcpu_hcr(vcpu) |= HCR_VSE;
}
@@ -184,5 +184,5 @@ static void pend_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
*/
void kvm_inject_vabt(struct kvm_vcpu *vcpu)
{
- pend_guest_serror(vcpu, ESR_ELx_ISV);
+ kvm_set_sei_esr(vcpu, ESR_ELx_ISV);
}
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 38c8a64..20e919a 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -82,6 +82,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
+ case KVM_CAP_VCPU_EVENTS:
r = 1;
break;
default:
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index a4c1b76..79ecba9 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1107,6 +1107,25 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
r = kvm_arm_vcpu_has_attr(vcpu, &attr);
break;
}
+ case KVM_GET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (kvm_arm_vcpu_get_events(vcpu, &events))
+ return -EINVAL;
+
+ if (copy_to_user(argp, &events, sizeof(events)))
+ return -EFAULT;
+
+ return 0;
+ }
+ case KVM_SET_VCPU_EVENTS: {
+ struct kvm_vcpu_events events;
+
+ if (copy_from_user(&events, argp, sizeof(events)))
+ return -EFAULT;
+
+ return kvm_arm_vcpu_set_events(vcpu, &events);
+ }
default:
r = -EINVAL;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/2] arm64: KVM: export the capability to set guest SError syndrome
From: Dongjiu Geng @ 2018-06-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528401833-29963-1-git-send-email-gengdongjiu@huawei.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
---
Documentation/virtual/kvm/api.txt | 11 +++++++++++
arch/arm64/kvm/reset.c | 3 +++
include/uapi/linux/kvm.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 758bf40..fdac969 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -4603,3 +4603,14 @@ Architectures: s390
This capability indicates that kvm will implement the interfaces to handle
reset, migration and nested KVM for branch prediction blocking. The stfle
facility 82 should not be provided to the guest without this capability.
+
+8.14 KVM_CAP_ARM_SET_SERROR_ESR
+
+Architectures: arm, arm64
+
+This capability indicates that userspace can specify the syndrome value reported
+to the guest OS when guest takes a virtual SError interrupt exception.
+If KVM has this capability, userspace can only specify the ISS field for the ESR
+syndrome, it can not specify the EC field which is not under control by KVM.
+If this virtual SError is taken to EL1 using AArch64, this value will be reported
+in ISS filed of ESR_EL1.
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 3256b92..38c8a64 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -77,6 +77,9 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_ARM_PMU_V3:
r = kvm_arm_support_pmu_v3();
break;
+ case KVM_CAP_ARM_INJECT_SERROR_ESR:
+ r = cpus_have_const_cap(ARM64_HAS_RAS_EXTN);
+ break;
case KVM_CAP_SET_GUEST_DEBUG:
case KVM_CAP_VCPU_ATTRIBUTES:
r = 1;
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index b02c41e..e88f976 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -948,6 +948,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_S390_BPB 152
#define KVM_CAP_GET_MSR_FEATURES 153
#define KVM_CAP_HYPERV_EVENTFD 154
+#define KVM_CAP_ARM_INJECT_SERROR_ESR 155
#ifdef KVM_CAP_IRQ_ROUTING
--
2.7.4
^ 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