mirror of
https://github.com/Dasharo/linux.git
synced 2026-03-06 15:25:10 -08:00
Merge drm/drm-next into drm-misc-next
Paul Cercueil needs some patches in -rc5 to apply new patches for ingenic properly. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
This commit is contained in:
Maxime Ripard
@@ -111,6 +111,7 @@ ForEachMacros:
|
||||
- 'css_for_each_descendant_pre'
|
||||
- 'device_for_each_child_node'
|
||||
- 'dma_fence_chain_for_each'
|
||||
- 'do_for_each_ftrace_op'
|
||||
- 'drm_atomic_crtc_for_each_plane'
|
||||
- 'drm_atomic_crtc_state_for_each_plane'
|
||||
- 'drm_atomic_crtc_state_for_each_plane_state'
|
||||
@@ -136,6 +137,7 @@ ForEachMacros:
|
||||
- 'for_each_active_dev_scope'
|
||||
- 'for_each_active_drhd_unit'
|
||||
- 'for_each_active_iommu'
|
||||
- 'for_each_aggr_pgid'
|
||||
- 'for_each_available_child_of_node'
|
||||
- 'for_each_bio'
|
||||
- 'for_each_board_func_rsrc'
|
||||
@@ -234,6 +236,7 @@ ForEachMacros:
|
||||
- 'for_each_node_state'
|
||||
- 'for_each_node_with_cpus'
|
||||
- 'for_each_node_with_property'
|
||||
- 'for_each_nonreserved_multicast_dest_pgid'
|
||||
- 'for_each_of_allnodes'
|
||||
- 'for_each_of_allnodes_from'
|
||||
- 'for_each_of_cpu_node'
|
||||
@@ -256,6 +259,7 @@ ForEachMacros:
|
||||
- 'for_each_pci_dev'
|
||||
- 'for_each_pci_msi_entry'
|
||||
- 'for_each_pcm_streams'
|
||||
- 'for_each_physmem_range'
|
||||
- 'for_each_populated_zone'
|
||||
- 'for_each_possible_cpu'
|
||||
- 'for_each_present_cpu'
|
||||
@@ -265,6 +269,8 @@ ForEachMacros:
|
||||
- 'for_each_process_thread'
|
||||
- 'for_each_property_of_node'
|
||||
- 'for_each_registered_fb'
|
||||
- 'for_each_requested_gpio'
|
||||
- 'for_each_requested_gpio_in_range'
|
||||
- 'for_each_reserved_mem_region'
|
||||
- 'for_each_rtd_codec_dais'
|
||||
- 'for_each_rtd_codec_dais_rollback'
|
||||
@@ -278,12 +284,17 @@ ForEachMacros:
|
||||
- 'for_each_sg'
|
||||
- 'for_each_sg_dma_page'
|
||||
- 'for_each_sg_page'
|
||||
- 'for_each_sgtable_dma_page'
|
||||
- 'for_each_sgtable_dma_sg'
|
||||
- 'for_each_sgtable_page'
|
||||
- 'for_each_sgtable_sg'
|
||||
- 'for_each_sibling_event'
|
||||
- 'for_each_subelement'
|
||||
- 'for_each_subelement_extid'
|
||||
- 'for_each_subelement_id'
|
||||
- '__for_each_thread'
|
||||
- 'for_each_thread'
|
||||
- 'for_each_unicast_dest_pgid'
|
||||
- 'for_each_wakeup_source'
|
||||
- 'for_each_zone'
|
||||
- 'for_each_zone_zonelist'
|
||||
@@ -464,6 +475,7 @@ ForEachMacros:
|
||||
- 'v4l2_m2m_for_each_src_buf'
|
||||
- 'v4l2_m2m_for_each_src_buf_safe'
|
||||
- 'virtio_device_for_each_vq'
|
||||
- 'while_for_each_ftrace_op'
|
||||
- 'xa_for_each'
|
||||
- 'xa_for_each_marked'
|
||||
- 'xa_for_each_range'
|
||||
|
||||
123
.mailmap
123
.mailmap
@@ -15,30 +15,31 @@
|
||||
Aaron Durbin <adurbin@google.com>
|
||||
Adam Oldham <oldhamca@gmail.com>
|
||||
Adam Radford <aradford@gmail.com>
|
||||
Adrian Bunk <bunk@stusta.de>
|
||||
Adriana Reus <adi.reus@gmail.com> <adriana.reus@intel.com>
|
||||
Adrian Bunk <bunk@stusta.de>
|
||||
Alan Cox <alan@lxorguk.ukuu.org.uk>
|
||||
Alan Cox <root@hraefn.swansea.linux.org.uk>
|
||||
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
||||
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
|
||||
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
|
||||
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
|
||||
Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>
|
||||
Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>
|
||||
Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
|
||||
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
|
||||
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
|
||||
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
|
||||
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
|
||||
Al Viro <viro@ftp.linux.org.uk>
|
||||
Al Viro <viro@zenIV.linux.org.uk>
|
||||
Andi Kleen <ak@linux.intel.com> <ak@suse.de>
|
||||
Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>
|
||||
Andreas Herrmann <aherrman@de.ibm.com>
|
||||
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
|
||||
Andrew Morton <akpm@linux-foundation.org>
|
||||
Andrew Murray <amurray@thegoodpenguin.co.uk> <andrew.murray@arm.com>
|
||||
Andrew Murray <amurray@thegoodpenguin.co.uk> <amurray@embedded-bits.co.uk>
|
||||
Andrew Murray <amurray@thegoodpenguin.co.uk> <andrew.murray@arm.com>
|
||||
Andrew Vasquez <andrew.vasquez@qlogic.com>
|
||||
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
Antoine Tenart <antoine.tenart@free-electrons.com>
|
||||
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
|
||||
@@ -48,40 +49,42 @@ Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Axel Lin <axel.lin@gmail.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon.dev@gmail.com>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <b.brezillon@overkiz.com>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@bootlin.com>
|
||||
Boris Brezillon <bbrezillon@kernel.org> <boris.brezillon@free-electrons.com>
|
||||
Brian Avery <b.avery@hp.com>
|
||||
Brian King <brking@us.ibm.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Christophe Ricard <christophe.ricard@gmail.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
Damian Hobson-Garcia <dhobsong@igel.co.jp>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dborkmann@redhat.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@iogearbox.net>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <daniel.borkmann@tik.ee.ethz.ch>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dborkmann@redhat.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dborkman@redhat.com>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <dxchgb@gmail.com>
|
||||
David Brownell <david-b@pacbell.net>
|
||||
David Woodhouse <dwmw2@shinybook.infradead.org>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dczhu@mips.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@gmail.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@imgtec.com>
|
||||
Dengcheng Zhu <dzhu@wavecomp.com> <dengcheng.zhu@mips.com>
|
||||
<dev.kurt@vandijck-laurijssen.be> <kurt.van.dijck@eia.be>
|
||||
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dima@arista.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <d.safonov@partner.samsung.com>
|
||||
Dmitry Safonov <0x7f454c46@gmail.com> <dsafonov@virtuozzo.com>
|
||||
Domen Puncer <domen@coderock.org>
|
||||
Douglas Gilbert <dougg@torque.net>
|
||||
Ed L. Cashin <ecashin@coraid.com>
|
||||
@@ -92,20 +95,22 @@ Felix Kuhling <fxkuehl@gmx.de>
|
||||
Felix Moeller <felix@derklecks.de>
|
||||
Filipe Lautert <filipe@icewall.org>
|
||||
Franck Bui-Huu <vagabon.xyz@gmail.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@am.sony.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frank.rowand@sonymobile.com>
|
||||
Frank Rowand <frowand.list@gmail.com> <frowand@mvista.com>
|
||||
Frank Zago <fzago@systemfabricworks.com>
|
||||
Gao Xiang <xiang@kernel.org> <gaoxiang25@huawei.com>
|
||||
Gao Xiang <xiang@kernel.org> <hsiangkao@aol.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@de.ibm.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <gerald.schaefer@de.ibm.com>
|
||||
Gerald Schaefer <gerald.schaefer@linux.ibm.com> <geraldsc@linux.vnet.ibm.com>
|
||||
Greg Kroah-Hartman <greg@echidna.(none)>
|
||||
Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Greg Kroah-Hartman <greg@kroah.com>
|
||||
Greg Kurz <groug@kaod.org> <gkurz@linux.vnet.ibm.com>
|
||||
Gregory CLEMENT <gregory.clement@bootlin.com> <gregory.clement@free-electrons.com>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
Gustavo Padovan <padovan@profusion.mobi>
|
||||
Hanjun Guo <guohanjun@huawei.com> <hanjun.guo@linaro.org>
|
||||
Heiko Carstens <hca@linux.ibm.com> <h.carstens@de.ibm.com>
|
||||
Heiko Carstens <hca@linux.ibm.com> <heiko.carstens@de.ibm.com>
|
||||
@@ -115,32 +120,33 @@ Henrik Rydberg <rydberg@bitmath.org>
|
||||
Herbert Xu <herbert@gondor.apana.org.au>
|
||||
Jacob Shin <Jacob.Shin@amd.com>
|
||||
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@google.com>
|
||||
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
|
||||
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk.kim@samsung.com>
|
||||
Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
|
||||
Jakub Kicinski <kuba@kernel.org> <jakub.kicinski@netronome.com>
|
||||
James Bottomley <jejb@mulgrave.(none)>
|
||||
James Bottomley <jejb@titanic.il.steeleye.com>
|
||||
James E Wilson <wilson@specifix.com>
|
||||
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
|
||||
James Hogan <jhogan@kernel.org> <james@albanarts.com>
|
||||
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
|
||||
James Ketrenos <jketreno@io.(none)>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jang@de.ibm.com>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jang@linux.vnet.ibm.com>
|
||||
Jan Glauber <jan.glauber@gmail.com> <jglauber@cavium.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@mellanox.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgg@nvidia.com>
|
||||
Jason Gunthorpe <jgg@ziepe.ca> <jgunthorpe@obsidianresearch.com>
|
||||
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
||||
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
|
||||
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jayachandranc@netlogicmicro.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jchandra@broadcom.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jchandra@digeo.com>
|
||||
Jayachandran C <c.jayachandran@gmail.com> <jnair@caviumnetworks.com>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
<jean-philippe@linaro.org> <jean-philippe.brucker@arm.com>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
|
||||
@@ -164,30 +170,31 @@ Julien Thierry <julien.thierry.kdev@gmail.com> <julien.thierry@arm.com>
|
||||
Kamil Konieczny <k.konieczny@samsung.com> <k.konieczny@partner.samsung.com>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
|
||||
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
|
||||
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
|
||||
Leonardo Bras <leobras.c@gmail.com> <leonardo@linux.ibm.com>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leon@leon.nu>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@mellanox.com>
|
||||
Leon Romanovsky <leon@kernel.org> <leonro@nvidia.com>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
|
||||
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@ascom.ch>
|
||||
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
|
||||
Linus Lüssing <linus.luessing@c0d3.blue> <linus.luessing@web.de>
|
||||
Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
|
||||
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
|
||||
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
|
||||
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
|
||||
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
|
||||
Marcin Nowakowski <marcin.nowakowski@mips.com> <marcin.nowakowski@imgtec.com>
|
||||
Marc Zyngier <maz@kernel.org> <marc.zyngier@arm.com>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@puri.sm>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
|
||||
Mathieu Othacehe <m.othacehe@gmail.com>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>
|
||||
@@ -197,17 +204,17 @@ Matthew Wilcox <willy@infradead.org> <willy@debian.org>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@infradead.org>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
|
||||
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
|
||||
Matt Ranostay <mranostay@gmail.com> Matthew Ranostay <mranostay@embeddedalley.com>
|
||||
Matt Ranostay <mranostay@gmail.com> <matt.ranostay@intel.com>
|
||||
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
|
||||
Matt Redfearn <matt.redfearn@mips.com> <matt.redfearn@imgtec.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@infradead.org>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@osg.samsung.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@redhat.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <m.chehab@samsung.com>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@s-opensource.com>
|
||||
Maxime Ripard <mripard@kernel.org> <maxime.ripard@bootlin.com>
|
||||
Maxime Ripard <mripard@kernel.org> <maxime.ripard@free-electrons.com>
|
||||
Mayuresh Janorkar <mayur@ti.com>
|
||||
@@ -239,13 +246,13 @@ Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
Paul Burton <paulburton@kernel.org> <paul.burton@imgtec.com>
|
||||
Paul Burton <paulburton@kernel.org> <paul.burton@mips.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@linux.vnet.ibm.com>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paul.mckenney@linaro.org>
|
||||
Paul E. McKenney <paulmck@kernel.org> <paulmck@us.ibm.com>
|
||||
Peter A Jonsson <pj@ludd.ltu.se>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
Peter Oruba <peter.oruba@amd.com>
|
||||
Peter Oruba <peter@oruba.de>
|
||||
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
|
||||
@@ -258,23 +265,23 @@ Ralf Baechle <ralf@linux-mips.org>
|
||||
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
|
||||
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
|
||||
Rémi Denis-Courmont <rdenis@simphalempin.com>
|
||||
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
|
||||
Ricardo Ribalda <ribalda@kernel.org> <ricardo@ribalda.com>
|
||||
Ricardo Ribalda <ribalda@kernel.org> Ricardo Ribalda Delgado <ribalda@kernel.org>
|
||||
Ricardo Ribalda <ribalda@kernel.org> <ricardo.ribalda@gmail.com>
|
||||
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
|
||||
Rudolf Marek <R.Marek@sh.cvut.cz>
|
||||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
Sarangdhar Joshi <spjoshi@codeaurora.org>
|
||||
Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
|
||||
Sam Ravnborg <sam@mars.ravnborg.org>
|
||||
Santosh Shilimkar <ssantosh@kernel.org>
|
||||
Santosh Shilimkar <santosh.shilimkar@oracle.org>
|
||||
Santosh Shilimkar <ssantosh@kernel.org>
|
||||
Sarangdhar Joshi <spjoshi@codeaurora.org>
|
||||
Sascha Hauer <s.hauer@pengutronix.de>
|
||||
S.Çağlar Onur <caglar@pardus.org.tr>
|
||||
Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
|
||||
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
|
||||
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
|
||||
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
|
||||
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
|
||||
Sedat Dilek <sedat.dilek@gmail.com> <sedat.dilek@credativ.de>
|
||||
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
|
||||
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
|
||||
@@ -285,19 +292,23 @@ Simon Arlott <simon@octiron.net> <simon@fire.lp0.eu>
|
||||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
Stephen Hemminger <shemminger@osdl.org>
|
||||
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
|
||||
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>
|
||||
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
|
||||
Subhash Jadavani <subhashj@codeaurora.org>
|
||||
Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
|
||||
Sumit Semwal <sumit.semwal@ti.com>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Tejun Heo <htejun@gmail.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Thomas Pedersen <twp@codeaurora.org>
|
||||
Tiezhu Yang <yangtiezhu@loongson.cn> <kernelpatch@126.com>
|
||||
Todor Tomov <todor.too@gmail.com> <todor.tomov@linaro.org>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
|
||||
TripleX Chung <xxx.phy@gmail.com> <triplex@zh-kernel.org>
|
||||
TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>
|
||||
Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>
|
||||
Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
@@ -305,22 +316,16 @@ Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Vinod Koul <vkoul@kernel.org> <vinod.koul@intel.com>
|
||||
Vinod Koul <vkoul@kernel.org> <vinod.koul@linux.intel.com>
|
||||
Vinod Koul <vkoul@kernel.org> <vkoul@infradead.org>
|
||||
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
|
||||
Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
|
||||
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
|
||||
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
|
||||
Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
|
||||
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
|
||||
WeiXiong Liao <gmpy.liaowx@gmail.com> <liaoweixiong@allwinnertech.com>
|
||||
Will Deacon <will@kernel.org> <will.deacon@arm.com>
|
||||
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
|
||||
Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de>
|
||||
Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>
|
||||
Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
Gustavo Padovan <gustavo@las.ic.unicamp.br>
|
||||
Gustavo Padovan <padovan@profusion.mobi>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Steve Wise <larrystevenwise@gmail.com> <swise@chelsio.com>
|
||||
Steve Wise <larrystevenwise@gmail.com> <swise@opengridcomputing.com>
|
||||
|
||||
@@ -43,7 +43,7 @@ Description: read only
|
||||
This sysfs interface exposes the number of cores per chip
|
||||
present in the system.
|
||||
|
||||
What: /sys/devices/hv_24x7/interface/cpumask
|
||||
What: /sys/devices/hv_24x7/cpumask
|
||||
Date: July 2020
|
||||
Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
||||
Description: read only
|
||||
|
||||
@@ -49,7 +49,7 @@ checking of rcu_dereference() primitives:
|
||||
is invoked by both RCU-sched readers and updaters.
|
||||
srcu_dereference_check(p, c):
|
||||
Use explicit check expression "c" along with
|
||||
srcu_read_lock_held()(). This is useful in code that
|
||||
srcu_read_lock_held(). This is useful in code that
|
||||
is invoked by both SRCU readers and updaters.
|
||||
rcu_dereference_raw(p):
|
||||
Don't check. (Use sparingly, if at all.)
|
||||
|
||||
@@ -1662,7 +1662,7 @@
|
||||
|
||||
98 block User-mode virtual block device
|
||||
0 = /dev/ubda First user-mode block device
|
||||
16 = /dev/udbb Second user-mode block device
|
||||
16 = /dev/ubdb Second user-mode block device
|
||||
...
|
||||
|
||||
Partitions are handled in the same way as for IDE
|
||||
|
||||
@@ -156,7 +156,6 @@ against. Possible keywords are:::
|
||||
``line-range`` cannot contain space, e.g.
|
||||
"1-30" is valid range but "1 - 30" is not.
|
||||
|
||||
``module=foo`` combined keyword=value form is interchangably accepted
|
||||
|
||||
The meanings of each keyword are:
|
||||
|
||||
|
||||
@@ -489,6 +489,9 @@ Files in /sys/fs/ext4/<devname>:
|
||||
multiple of this tuning parameter if the stripe size is not set in the
|
||||
ext4 superblock
|
||||
|
||||
mb_max_inode_prealloc
|
||||
The maximum length of per-inode ext4_prealloc_space list.
|
||||
|
||||
mb_max_to_scan
|
||||
The maximum number of extents the multiblock allocator will search to
|
||||
find the best extent.
|
||||
@@ -529,21 +532,21 @@ Files in /sys/fs/ext4/<devname>:
|
||||
Ioctls
|
||||
======
|
||||
|
||||
There is some Ext4 specific functionality which can be accessed by applications
|
||||
through the system call interfaces. The list of all Ext4 specific ioctls are
|
||||
shown in the table below.
|
||||
Ext4 implements various ioctls which can be used by applications to access
|
||||
ext4-specific functionality. An incomplete list of these ioctls is shown in the
|
||||
table below. This list includes truly ext4-specific ioctls (``EXT4_IOC_*``) as
|
||||
well as ioctls that may have been ext4-specific originally but are now supported
|
||||
by some other filesystem(s) too (``FS_IOC_*``).
|
||||
|
||||
Table of Ext4 specific ioctls
|
||||
Table of Ext4 ioctls
|
||||
|
||||
EXT4_IOC_GETFLAGS
|
||||
FS_IOC_GETFLAGS
|
||||
Get additional attributes associated with inode. The ioctl argument is
|
||||
an integer bitfield, with bit values described in ext4.h. This ioctl is
|
||||
an alias for FS_IOC_GETFLAGS.
|
||||
an integer bitfield, with bit values described in ext4.h.
|
||||
|
||||
EXT4_IOC_SETFLAGS
|
||||
FS_IOC_SETFLAGS
|
||||
Set additional attributes associated with inode. The ioctl argument is
|
||||
an integer bitfield, with bit values described in ext4.h. This ioctl is
|
||||
an alias for FS_IOC_SETFLAGS.
|
||||
an integer bitfield, with bit values described in ext4.h.
|
||||
|
||||
EXT4_IOC_GETVERSION, EXT4_IOC_GETVERSION_OLD
|
||||
Get the inode i_generation number stored for each inode. The
|
||||
|
||||
@@ -1233,8 +1233,7 @@
|
||||
efi= [EFI]
|
||||
Format: { "debug", "disable_early_pci_dma",
|
||||
"nochunk", "noruntime", "nosoftreserve",
|
||||
"novamap", "no_disable_early_pci_dma",
|
||||
"old_map" }
|
||||
"novamap", "no_disable_early_pci_dma" }
|
||||
debug: enable misc debug output.
|
||||
disable_early_pci_dma: disable the busmaster bit on all
|
||||
PCI bridges while in the EFI boot stub.
|
||||
@@ -1251,8 +1250,6 @@
|
||||
novamap: do not call SetVirtualAddressMap().
|
||||
no_disable_early_pci_dma: Leave the busmaster bit set
|
||||
on all PCI bridges while in the EFI boot stub
|
||||
old_map [X86-64]: switch to the old ioremap-based EFI
|
||||
runtime services mapping. [Needs CONFIG_X86_UV=y]
|
||||
|
||||
efi_no_storage_paranoia [EFI; X86]
|
||||
Using this parameter you can use more than 50% of
|
||||
|
||||
@@ -1434,7 +1434,7 @@ on the feature, restricting the viewing angles.
|
||||
|
||||
|
||||
DYTC Lapmode sensor
|
||||
------------------
|
||||
-------------------
|
||||
|
||||
sysfs: dytc_lapmode
|
||||
|
||||
|
||||
@@ -123,7 +123,9 @@ Energy-Performance Bias (EPB) knob (otherwise), which means that the processor's
|
||||
internal P-state selection logic is expected to focus entirely on performance.
|
||||
|
||||
This will override the EPP/EPB setting coming from the ``sysfs`` interface
|
||||
(see `Energy vs Performance Hints`_ below).
|
||||
(see `Energy vs Performance Hints`_ below). Moreover, any attempts to change
|
||||
the EPP/EPB to a value different from 0 ("performance") via ``sysfs`` in this
|
||||
configuration will be rejected.
|
||||
|
||||
Also, in this configuration the range of P-states available to the processor's
|
||||
internal P-state selection logic is always restricted to the upper boundary
|
||||
@@ -564,8 +566,8 @@ Energy-Performance Preference (EPP) knob (if supported) or its
|
||||
Energy-Performance Bias (EPB) knob. It is also possible to write a positive
|
||||
integer value between 0 to 255, if the EPP feature is present. If the EPP
|
||||
feature is not present, writing integer value to this attribute is not
|
||||
supported. In this case, user can use
|
||||
"/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface.
|
||||
supported. In this case, user can use the
|
||||
"/sys/devices/system/cpu/cpu*/power/energy_perf_bias" interface.
|
||||
|
||||
[Note that tasks may by migrated from one CPU to another by the scheduler's
|
||||
load-balancing algorithm and if different energy vs performance hints are
|
||||
|
||||
@@ -36,6 +36,12 @@ Two sets of Questions and Answers (Q&A) are maintained.
|
||||
bpf_devel_QA
|
||||
|
||||
|
||||
Helper functions
|
||||
================
|
||||
|
||||
* `bpf-helpers(7)`_ maintains a list of helpers available to eBPF programs.
|
||||
|
||||
|
||||
Program types
|
||||
=============
|
||||
|
||||
@@ -79,4 +85,5 @@ Other
|
||||
.. _networking-filter: ../networking/filter.rst
|
||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||
.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
|
||||
.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
|
||||
.. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/
|
||||
|
||||
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Clock bindings for Freescale i.MX23
|
||||
|
||||
maintainers:
|
||||
- Shawn Guo <shawn.guo@linaro.org>
|
||||
- Shawn Guo <shawnguo@kernel.org>
|
||||
|
||||
description: |
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
|
||||
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Clock bindings for Freescale i.MX28
|
||||
|
||||
maintainers:
|
||||
- Shawn Guo <shawn.guo@linaro.org>
|
||||
- Shawn Guo <shawnguo@kernel.org>
|
||||
|
||||
description: |
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
|
||||
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Freescale MXS GPIO controller
|
||||
|
||||
maintainers:
|
||||
- Shawn Guo <shawn.guo@linaro.org>
|
||||
- Shawn Guo <shawnguo@kernel.org>
|
||||
- Anson Huang <Anson.Huang@nxp.com>
|
||||
|
||||
description: |
|
||||
|
||||
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Freescale MXS Inter IC (I2C) Controller
|
||||
|
||||
maintainers:
|
||||
- Shawn Guo <shawn.guo@linaro.org>
|
||||
- Shawn Guo <shawnguo@kernel.org>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
@@ -1,66 +0,0 @@
|
||||
Texas Instruments K3 Interrupt Aggregator
|
||||
=========================================
|
||||
|
||||
The Interrupt Aggregator (INTA) provides a centralized machine
|
||||
which handles the termination of system events to that they can
|
||||
be coherently processed by the host(s) in the system. A maximum
|
||||
of 64 events can be mapped to a single interrupt.
|
||||
|
||||
|
||||
Interrupt Aggregator
|
||||
+-----------------------------------------+
|
||||
| Intmap VINT |
|
||||
| +--------------+ +------------+ |
|
||||
m ------>| | vint | bit | | 0 |.....|63| vint0 |
|
||||
. | +--------------+ +------------+ | +------+
|
||||
. | . . | | HOST |
|
||||
Globalevents ------>| . . |------>| IRQ |
|
||||
. | . . | | CTRL |
|
||||
. | . . | +------+
|
||||
n ------>| +--------------+ +------------+ |
|
||||
| | vint | bit | | 0 |.....|63| vintx |
|
||||
| +--------------+ +------------+ |
|
||||
| |
|
||||
+-----------------------------------------+
|
||||
|
||||
Configuration of these Intmap registers that maps global events to vint is done
|
||||
by a system controller (like the Device Memory and Security Controller on K3
|
||||
AM654 SoC). Driver should request the system controller to get the range
|
||||
of global events and vints assigned to the requesting host. Management
|
||||
of these requested resources should be handled by driver and requests
|
||||
system controller to map specific global event to vint, bit pair.
|
||||
|
||||
Communication between the host processor running an OS and the system
|
||||
controller happens through a protocol called TI System Control Interface
|
||||
(TISCI protocol). For more details refer:
|
||||
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
|
||||
|
||||
TISCI Interrupt Aggregator Node:
|
||||
-------------------------------
|
||||
- compatible: Must be "ti,sci-inta".
|
||||
- reg: Should contain registers location and length.
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- msi-controller: Identifies the node as an MSI controller.
|
||||
- interrupt-parent: phandle of irq parent.
|
||||
- ti,sci: Phandle to TI-SCI compatible System controller node.
|
||||
- ti,sci-dev-id: TISCI device ID of the Interrupt Aggregator.
|
||||
- ti,sci-rm-range-vint: Array of TISCI subtype ids representing vints(inta
|
||||
outputs) range within this INTA, assigned to the
|
||||
requesting host context.
|
||||
- ti,sci-rm-range-global-event: Array of TISCI subtype ids representing the
|
||||
global events range reaching this IA and are assigned
|
||||
to the requesting host context.
|
||||
|
||||
Example:
|
||||
--------
|
||||
main_udmass_inta: interrupt-controller@33d00000 {
|
||||
compatible = "ti,sci-inta";
|
||||
reg = <0x0 0x33d00000 0x0 0x100000>;
|
||||
interrupt-controller;
|
||||
msi-controller;
|
||||
interrupt-parent = <&main_navss_intr>;
|
||||
ti,sci = <&dmsc>;
|
||||
ti,sci-dev-id = <179>;
|
||||
ti,sci-rm-range-vint = <0x0>;
|
||||
ti,sci-rm-range-global-event = <0x1>;
|
||||
};
|
||||
@@ -0,0 +1,98 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interrupt-controller/ti,sci-inta.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments K3 Interrupt Aggregator
|
||||
|
||||
maintainers:
|
||||
- Lokesh Vutla <lokeshvutla@ti.com>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
|
||||
|
||||
description: |
|
||||
The Interrupt Aggregator (INTA) provides a centralized machine
|
||||
which handles the termination of system events to that they can
|
||||
be coherently processed by the host(s) in the system. A maximum
|
||||
of 64 events can be mapped to a single interrupt.
|
||||
|
||||
Interrupt Aggregator
|
||||
+-----------------------------------------+
|
||||
| Intmap VINT |
|
||||
| +--------------+ +------------+ |
|
||||
m ------>| | vint | bit | | 0 |.....|63| vint0 |
|
||||
. | +--------------+ +------------+ | +------+
|
||||
. | . . | | HOST |
|
||||
Globalevents ------>| . . |----->| IRQ |
|
||||
. | . . | | CTRL |
|
||||
. | . . | +------+
|
||||
n ------>| +--------------+ +------------+ |
|
||||
| | vint | bit | | 0 |.....|63| vintx |
|
||||
| +--------------+ +------------+ |
|
||||
| |
|
||||
+-----------------------------------------+
|
||||
|
||||
Configuration of these Intmap registers that maps global events to vint is
|
||||
done by a system controller (like the Device Memory and Security Controller
|
||||
on AM654 SoC). Driver should request the system controller to get the range
|
||||
of global events and vints assigned to the requesting host. Management
|
||||
of these requested resources should be handled by driver and requests
|
||||
system controller to map specific global event to vint, bit pair.
|
||||
|
||||
Communication between the host processor running an OS and the system
|
||||
controller happens through a protocol called TI System Control Interface
|
||||
(TISCI protocol).
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ti,sci-inta
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
msi-controller: true
|
||||
|
||||
ti,interrupt-ranges:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
description: |
|
||||
Interrupt ranges that converts the INTA output hw irq numbers
|
||||
to parents's input interrupt numbers.
|
||||
items:
|
||||
items:
|
||||
- description: |
|
||||
"output_irq" specifies the base for inta output irq
|
||||
- description: |
|
||||
"parent's input irq" specifies the base for parent irq
|
||||
- description: |
|
||||
"limit" specifies the limit for translation
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupt-controller
|
||||
- msi-controller
|
||||
- ti,sci
|
||||
- ti,sci-dev-id
|
||||
- ti,interrupt-ranges
|
||||
|
||||
examples:
|
||||
- |
|
||||
bus {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
main_udmass_inta: msi-controller@33d00000 {
|
||||
compatible = "ti,sci-inta";
|
||||
reg = <0x0 0x33d00000 0x0 0x100000>;
|
||||
interrupt-controller;
|
||||
msi-controller;
|
||||
interrupt-parent = <&main_navss_intr>;
|
||||
ti,sci = <&dmsc>;
|
||||
ti,sci-dev-id = <179>;
|
||||
ti,interrupt-ranges = <0 0 256>;
|
||||
};
|
||||
};
|
||||
@@ -1,82 +0,0 @@
|
||||
Texas Instruments K3 Interrupt Router
|
||||
=====================================
|
||||
|
||||
The Interrupt Router (INTR) module provides a mechanism to mux M
|
||||
interrupt inputs to N interrupt outputs, where all M inputs are selectable
|
||||
to be driven per N output. An Interrupt Router can either handle edge triggered
|
||||
or level triggered interrupts and that is fixed in hardware.
|
||||
|
||||
Interrupt Router
|
||||
+----------------------+
|
||||
| Inputs Outputs |
|
||||
+-------+ | +------+ +-----+ |
|
||||
| GPIO |----------->| | irq0 | | 0 | | Host IRQ
|
||||
+-------+ | +------+ +-----+ | controller
|
||||
| . . | +-------+
|
||||
+-------+ | . . |----->| IRQ |
|
||||
| INTA |----------->| . . | +-------+
|
||||
+-------+ | . +-----+ |
|
||||
| +------+ | N | |
|
||||
| | irqM | +-----+ |
|
||||
| +------+ |
|
||||
| |
|
||||
+----------------------+
|
||||
|
||||
There is one register per output (MUXCNTL_N) that controls the selection.
|
||||
Configuration of these MUXCNTL_N registers is done by a system controller
|
||||
(like the Device Memory and Security Controller on K3 AM654 SoC). System
|
||||
controller will keep track of the used and unused registers within the Router.
|
||||
Driver should request the system controller to get the range of GIC IRQs
|
||||
assigned to the requesting hosts. It is the drivers responsibility to keep
|
||||
track of Host IRQs.
|
||||
|
||||
Communication between the host processor running an OS and the system
|
||||
controller happens through a protocol called TI System Control Interface
|
||||
(TISCI protocol). For more details refer:
|
||||
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
|
||||
|
||||
TISCI Interrupt Router Node:
|
||||
----------------------------
|
||||
Required Properties:
|
||||
- compatible: Must be "ti,sci-intr".
|
||||
- ti,intr-trigger-type: Should be one of the following:
|
||||
1: If intr supports edge triggered interrupts.
|
||||
4: If intr supports level triggered interrupts.
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source. The value should be 2.
|
||||
First cell should contain the TISCI device ID of source
|
||||
Second cell should contain the interrupt source offset
|
||||
within the device.
|
||||
- ti,sci: Phandle to TI-SCI compatible System controller node.
|
||||
- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
|
||||
- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
|
||||
assigned to this interrupt router. Each subtype id
|
||||
corresponds to a range of host irqs.
|
||||
|
||||
For more details on TISCI IRQ resource management refer:
|
||||
https://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
|
||||
|
||||
Example:
|
||||
--------
|
||||
The following example demonstrates both interrupt router node and the consumer
|
||||
node(main gpio) on the AM654 SoC:
|
||||
|
||||
main_intr: interrupt-controller0 {
|
||||
compatible = "ti,sci-intr";
|
||||
ti,intr-trigger-type = <1>;
|
||||
interrupt-controller;
|
||||
interrupt-parent = <&gic500>;
|
||||
#interrupt-cells = <2>;
|
||||
ti,sci = <&dmsc>;
|
||||
ti,sci-dst-id = <56>;
|
||||
ti,sci-rm-range-girq = <0x1>;
|
||||
};
|
||||
|
||||
main_gpio0: gpio@600000 {
|
||||
...
|
||||
interrupt-parent = <&main_intr>;
|
||||
interrupts = <57 256>, <57 257>, <57 258>,
|
||||
<57 259>, <57 260>, <57 261>;
|
||||
...
|
||||
};
|
||||
@@ -0,0 +1,102 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interrupt-controller/ti,sci-intr.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments K3 Interrupt Router
|
||||
|
||||
maintainers:
|
||||
- Lokesh Vutla <lokeshvutla@ti.com>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
|
||||
|
||||
description: |
|
||||
The Interrupt Router (INTR) module provides a mechanism to mux M
|
||||
interrupt inputs to N interrupt outputs, where all M inputs are selectable
|
||||
to be driven per N output. An Interrupt Router can either handle edge
|
||||
triggered or level triggered interrupts and that is fixed in hardware.
|
||||
|
||||
Interrupt Router
|
||||
+----------------------+
|
||||
| Inputs Outputs |
|
||||
+-------+ | +------+ +-----+ |
|
||||
| GPIO |----------->| | irq0 | | 0 | | Host IRQ
|
||||
+-------+ | +------+ +-----+ | controller
|
||||
| . . | +-------+
|
||||
+-------+ | . . |----->| IRQ |
|
||||
| INTA |----------->| . . | +-------+
|
||||
+-------+ | . +-----+ |
|
||||
| +------+ | N | |
|
||||
| | irqM | +-----+ |
|
||||
| +------+ |
|
||||
| |
|
||||
+----------------------+
|
||||
|
||||
There is one register per output (MUXCNTL_N) that controls the selection.
|
||||
Configuration of these MUXCNTL_N registers is done by a system controller
|
||||
(like the Device Memory and Security Controller on K3 AM654 SoC). System
|
||||
controller will keep track of the used and unused registers within the Router.
|
||||
Driver should request the system controller to get the range of GIC IRQs
|
||||
assigned to the requesting hosts. It is the drivers responsibility to keep
|
||||
track of Host IRQs.
|
||||
|
||||
Communication between the host processor running an OS and the system
|
||||
controller happens through a protocol called TI System Control Interface
|
||||
(TISCI protocol).
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: ti,sci-intr
|
||||
|
||||
ti,intr-trigger-type:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [1, 4]
|
||||
description: |
|
||||
Should be one of the following.
|
||||
1 = If intr supports edge triggered interrupts.
|
||||
4 = If intr supports level triggered interrupts.
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
'#interrupt-cells':
|
||||
const: 1
|
||||
description: |
|
||||
The 1st cell should contain interrupt router input hw number.
|
||||
|
||||
ti,interrupt-ranges:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
description: |
|
||||
Interrupt ranges that converts the INTR output hw irq numbers
|
||||
to parents's input interrupt numbers.
|
||||
items:
|
||||
items:
|
||||
- description: |
|
||||
"output_irq" specifies the base for intr output irq
|
||||
- description: |
|
||||
"parent's input irq" specifies the base for parent irq
|
||||
- description: |
|
||||
"limit" specifies the limit for translation
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- ti,intr-trigger-type
|
||||
- interrupt-controller
|
||||
- '#interrupt-cells'
|
||||
- ti,sci
|
||||
- ti,sci-dev-id
|
||||
- ti,interrupt-ranges
|
||||
|
||||
examples:
|
||||
- |
|
||||
main_gpio_intr: interrupt-controller0 {
|
||||
compatible = "ti,sci-intr";
|
||||
ti,intr-trigger-type = <1>;
|
||||
interrupt-controller;
|
||||
interrupt-parent = <&gic500>;
|
||||
#interrupt-cells = <1>;
|
||||
ti,sci = <&dmsc>;
|
||||
ti,sci-dev-id = <131>;
|
||||
ti,interrupt-ranges = <0 360 32>;
|
||||
};
|
||||
@@ -30,9 +30,13 @@ allOf:
|
||||
then:
|
||||
properties:
|
||||
clock-output-names:
|
||||
items:
|
||||
- const: clk_out_sd0
|
||||
- const: clk_in_sd0
|
||||
oneOf:
|
||||
- items:
|
||||
- const: clk_out_sd0
|
||||
- const: clk_in_sd0
|
||||
- items:
|
||||
- const: clk_out_sd1
|
||||
- const: clk_in_sd1
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user