Merge branch 'for-5.10/core' into for-linus
- nonblocking read semantics fix for hid-debug
This commit is contained in:
commit
62b31a0457
132
.mailmap
132
.mailmap
|
@ -2,38 +2,44 @@
|
|||
# This list is used by git-shortlog to fix a few botched name translations
|
||||
# in the git archive, either because the author's full name was messed up
|
||||
# and/or not always written the same way, making contributions from the
|
||||
# same person appearing not to be so or badly displayed.
|
||||
# same person appearing not to be so or badly displayed. Also allows for
|
||||
# old email addresses to map to new email addresses.
|
||||
#
|
||||
# For format details, see "MAPPING AUTHORS" in "man git-shortlog".
|
||||
#
|
||||
# Please keep this list dictionary sorted.
|
||||
#
|
||||
# This comment is parsed by git-shortlog:
|
||||
# repo-abbrev: /pub/scm/linux/kernel/git/
|
||||
#
|
||||
|
||||
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>
|
||||
|
@ -43,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>
|
||||
|
@ -87,19 +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>
|
||||
|
@ -109,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>
|
||||
|
@ -158,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>
|
||||
|
@ -191,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>
|
||||
|
@ -233,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>
|
||||
|
@ -252,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>
|
||||
|
@ -279,18 +292,21 @@ 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>
|
||||
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
|
@ -299,22 +315,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
|
||||
|
|
|
@ -202,6 +202,25 @@ Description:
|
|||
functions. See the section named 'NVDIMM Root Device _DSMs' in
|
||||
the ACPI specification.
|
||||
|
||||
What: /sys/bus/nd/devices/ndbusX/nfit/firmware_activate_noidle
|
||||
Date: Apr, 2020
|
||||
KernelVersion: v5.8
|
||||
Contact: linux-nvdimm@lists.01.org
|
||||
Description:
|
||||
(RW) The Intel platform implementation of firmware activate
|
||||
support exposes an option let the platform force idle devices in
|
||||
the system over the activation event, or trust that the OS will
|
||||
do it. The safe default is to let the platform force idle
|
||||
devices since the kernel is already in a suspend state, and on
|
||||
the chance that a driver does not properly quiesce bus-mastering
|
||||
after a suspend callback the platform will handle it. However,
|
||||
the activation might abort if, for example, platform firmware
|
||||
determines that the activation time exceeds the max PCI-E
|
||||
completion timeout. Since the platform does not know whether the
|
||||
OS is running the activation from a suspend context it aborts,
|
||||
but if the system owner trusts driver suspend callback to be
|
||||
sufficient then 'firmware_activation_noidle' can be
|
||||
enabled to bypass the activation abort.
|
||||
|
||||
What: /sys/bus/nd/devices/regionX/nfit/range_index
|
||||
Date: Jun, 2015
|
||||
|
|
|
@ -0,0 +1,2 @@
|
|||
The libnvdimm sub-system implements a common sysfs interface for
|
||||
platform nvdimm resources. See Documentation/driver-api/nvdimm/.
|
|
@ -0,0 +1,15 @@
|
|||
What: /sys/bus/i2c/devices/xxx/fw_version
|
||||
Date: Aug 2020
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: Reports the firmware version provided by the touchscreen, for example "00_T6" on a EXC80H60
|
||||
|
||||
Access: Read
|
||||
Valid values: Represented as string
|
||||
|
||||
What: /sys/bus/i2c/devices/xxx/model
|
||||
Date: Aug 2020
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description: Reports the model identification provided by the touchscreen, for example "Orion_1320" on a EXC80H60
|
||||
|
||||
Access: Read
|
||||
Valid values: Represented as string
|
|
@ -229,7 +229,9 @@ Date: August 2017
|
|||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
Description: Do background GC agressively when set. When gc_urgent = 1,
|
||||
background thread starts to do GC by given gc_urgent_sleep_time
|
||||
interval. It is set to 0 by default.
|
||||
interval. When gc_urgent = 2, F2FS will lower the bar of
|
||||
checking idle in order to process outstanding discard commands
|
||||
and GC a little bit aggressively. It is set to 0 by default.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time
|
||||
Date: August 2017
|
||||
|
|
|
@ -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.)
|
||||
|
|
|
@ -1274,6 +1274,10 @@ PAGE_SIZE multiple when read back.
|
|||
Amount of memory used for storing in-kernel data
|
||||
structures.
|
||||
|
||||
percpu
|
||||
Amount of memory used for storing per-cpu kernel
|
||||
data structures.
|
||||
|
||||
sock
|
||||
Amount of memory used in network transmission buffers
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -80,6 +80,10 @@ The possible values in this file are:
|
|||
- The processor is not vulnerable.
|
||||
* - KVM: Mitigation: Split huge pages
|
||||
- Software changes mitigate this issue.
|
||||
* - KVM: Mitigation: VMX unsupported
|
||||
- KVM is not vulnerable because Virtual Machine Extensions (VMX) is not supported.
|
||||
* - KVM: Mitigation: VMX disabled
|
||||
- KVM is not vulnerable because Virtual Machine Extensions (VMX) is disabled.
|
||||
* - KVM: Vulnerable
|
||||
- The processor is vulnerable, but no mitigation enabled
|
||||
|
||||
|
|
|
@ -724,7 +724,7 @@
|
|||
memory region [offset, offset + size] for that kernel
|
||||
image. If '@offset' is omitted, then a suitable offset
|
||||
is selected automatically.
|
||||
[KNL, x86_64] select a region under 4G first, and
|
||||
[KNL, X86-64] Select a region under 4G first, and
|
||||
fall back to reserve region above 4G when '@offset'
|
||||
hasn't been specified.
|
||||
See Documentation/admin-guide/kdump/kdump.rst for further details.
|
||||
|
@ -737,14 +737,14 @@
|
|||
Documentation/admin-guide/kdump/kdump.rst for an example.
|
||||
|
||||
crashkernel=size[KMG],high
|
||||
[KNL, x86_64] range could be above 4G. Allow kernel
|
||||
[KNL, X86-64] range could be above 4G. Allow kernel
|
||||
to allocate physical memory region from top, so could
|
||||
be above 4G if system have more than 4G ram installed.
|
||||
Otherwise memory region will be allocated below 4G, if
|
||||
available.
|
||||
It will be ignored if crashkernel=X is specified.
|
||||
crashkernel=size[KMG],low
|
||||
[KNL, x86_64] range under 4G. When crashkernel=X,high
|
||||
[KNL, X86-64] range under 4G. When crashkernel=X,high
|
||||
is passed, kernel could allocate physical memory region
|
||||
above 4G, that cause second kernel crash on system
|
||||
that require some amount of low memory, e.g. swiotlb
|
||||
|
@ -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
|
||||
|
@ -1427,7 +1424,7 @@
|
|||
|
||||
gamma= [HW,DRM]
|
||||
|
||||
gart_fix_e820= [X86_64] disable the fix e820 for K8 GART
|
||||
gart_fix_e820= [X86-64] disable the fix e820 for K8 GART
|
||||
Format: off | on
|
||||
default: on
|
||||
|
||||
|
@ -1814,7 +1811,7 @@
|
|||
Format: 0 | 1
|
||||
Default set by CONFIG_INIT_ON_FREE_DEFAULT_ON.
|
||||
|
||||
init_pkru= [x86] Specify the default memory protection keys rights
|
||||
init_pkru= [X86] Specify the default memory protection keys rights
|
||||
register contents for all processes. 0x55555554 by
|
||||
default (disallow access to all but pkey 0). Can
|
||||
override in debugfs after boot.
|
||||
|
@ -1822,7 +1819,7 @@
|
|||
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
|
||||
Format: <irq>
|
||||
|
||||
int_pln_enable [x86] Enable power limit notification interrupt
|
||||
int_pln_enable [X86] Enable power limit notification interrupt
|
||||
|
||||
integrity_audit=[IMA]
|
||||
Format: { "0" | "1" }
|
||||
|
@ -1840,7 +1837,7 @@
|
|||
bypassed by not enabling DMAR with this option. In
|
||||
this case, gfx device will use physical address for
|
||||
DMA.
|
||||
forcedac [x86_64]
|
||||
forcedac [X86-64]
|
||||
With this option iommu will not optimize to look
|
||||
for io virtual address below 32-bit forcing dual
|
||||
address cycle on pci bus for cards supporting greater
|
||||
|
@ -1925,7 +1922,7 @@
|
|||
strict regions from userspace.
|
||||
relaxed
|
||||
|
||||
iommu= [x86]
|
||||
iommu= [X86]
|
||||
off
|
||||
force
|
||||
noforce
|
||||
|
@ -1935,8 +1932,8 @@
|
|||
merge
|
||||
nomerge
|
||||
soft
|
||||
pt [x86]
|
||||
nopt [x86]
|
||||
pt [X86]
|
||||
nopt [X86]
|
||||
nobypass [PPC/POWERNV]
|
||||
Disable IOMMU bypass, using IOMMU for PCI devices.
|
||||
|
||||
|
@ -2079,21 +2076,21 @@
|
|||
|
||||
iucv= [HW,NET]
|
||||
|
||||
ivrs_ioapic [HW,X86_64]
|
||||
ivrs_ioapic [HW,X86-64]
|
||||
Provide an override to the IOAPIC-ID<->DEVICE-ID
|
||||
mapping provided in the IVRS ACPI table. For
|
||||
example, to map IOAPIC-ID decimal 10 to
|
||||
PCI device 00:14.0 write the parameter as:
|
||||
ivrs_ioapic[10]=00:14.0
|
||||
|
||||
ivrs_hpet [HW,X86_64]
|
||||
ivrs_hpet [HW,X86-64]
|
||||
Provide an override to the HPET-ID<->DEVICE-ID
|
||||
mapping provided in the IVRS ACPI table. For
|
||||
example, to map HPET-ID decimal 0 to
|
||||
PCI device 00:14.0 write the parameter as:
|
||||
ivrs_hpet[0]=00:14.0
|
||||
|
||||
ivrs_acpihid [HW,X86_64]
|
||||
ivrs_acpihid [HW,X86-64]
|
||||
Provide an override to the ACPI-HID:UID<->DEVICE-ID
|
||||
mapping provided in the IVRS ACPI table. For
|
||||
example, to map UART-HID:UID AMD0020:0 to
|
||||
|
@ -2370,7 +2367,7 @@
|
|||
lapic [X86-32,APIC] Enable the local APIC even if BIOS
|
||||
disabled it.
|
||||
|
||||
lapic= [x86,APIC] "notscdeadline" Do not use TSC deadline
|
||||
lapic= [X86,APIC] "notscdeadline" Do not use TSC deadline
|
||||
value for LAPIC timer one-shot implementation. Default
|
||||
back to the programmable timer unit in the LAPIC.
|
||||
|
||||
|
@ -3188,12 +3185,12 @@
|
|||
register save and restore. The kernel will only save
|
||||
legacy floating-point registers on task switch.
|
||||
|
||||
nohugeiomap [KNL,x86,PPC] Disable kernel huge I/O mappings.
|
||||
nohugeiomap [KNL,X86,PPC] Disable kernel huge I/O mappings.
|
||||
|
||||
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
|
||||
Equivalent to smt=1.
|
||||
|
||||
[KNL,x86] Disable symmetric multithreading (SMT).
|
||||
[KNL,X86] Disable symmetric multithreading (SMT).
|
||||
nosmt=force: Force disable SMT, cannot be undone
|
||||
via the sysfs control file.
|
||||
|
||||
|
@ -3955,7 +3952,7 @@
|
|||
pt. [PARIDE]
|
||||
See Documentation/admin-guide/blockdev/paride.rst.
|
||||
|
||||
pti= [X86_64] Control Page Table Isolation of user and
|
||||
pti= [X86-64] Control Page Table Isolation of user and
|
||||
kernel address spaces. Disabling this feature
|
||||
removes hardening, but improves performance of
|
||||
system calls and interrupts.
|
||||
|
@ -3967,7 +3964,7 @@
|
|||
|
||||
Not specifying this option is equivalent to pti=auto.
|
||||
|
||||
nopti [X86_64]
|
||||
nopti [X86-64]
|
||||
Equivalent to pti=off
|
||||
|
||||
pty.legacy_count=
|
||||
|
|
|
@ -1434,7 +1434,7 @@ on the feature, restricting the viewing angles.
|
|||
|
||||
|
||||
DYTC Lapmode sensor
|
||||
------------------
|
||||
-------------------
|
||||
|
||||
sysfs: dytc_lapmode
|
||||
|
||||
|
|
|
@ -54,10 +54,13 @@ registered (see `below <status_attr_>`_).
|
|||
Operation Modes
|
||||
===============
|
||||
|
||||
``intel_pstate`` can operate in three different modes: in the active mode with
|
||||
or without hardware-managed P-states support and in the passive mode. Which of
|
||||
them will be in effect depends on what kernel command line options are used and
|
||||
on the capabilities of the processor.
|
||||
``intel_pstate`` can operate in two different modes, active or passive. In the
|
||||
active mode, it uses its own internal performance scaling governor algorithm or
|
||||
allows the hardware to do preformance scaling by itself, while in the passive
|
||||
mode it responds to requests made by a generic ``CPUFreq`` governor implementing
|
||||
a certain performance scaling algorithm. Which of them will be in effect
|
||||
depends on what kernel command line options are used and on the capabilities of
|
||||
the processor.
|
||||
|
||||
Active Mode
|
||||
-----------
|
||||
|
@ -194,10 +197,11 @@ This is the default operation mode of ``intel_pstate`` for processors without
|
|||
hardware-managed P-states (HWP) support. It is always used if the
|
||||
``intel_pstate=passive`` argument is passed to the kernel in the command line
|
||||
regardless of whether or not the given processor supports HWP. [Note that the
|
||||
``intel_pstate=no_hwp`` setting implies ``intel_pstate=passive`` if it is used
|
||||
without ``intel_pstate=active``.] Like in the active mode without HWP support,
|
||||
in this mode ``intel_pstate`` may refuse to work with processors that are not
|
||||
recognized by it.
|
||||
``intel_pstate=no_hwp`` setting causes the driver to start in the passive mode
|
||||
if it is not combined with ``intel_pstate=active``.] Like in the active mode
|
||||
without HWP support, in this mode ``intel_pstate`` may refuse to work with
|
||||
processors that are not recognized by it if HWP is prevented from being enabled
|
||||
through the kernel command line.
|
||||
|
||||
If the driver works in this mode, the ``scaling_driver`` policy attribute in
|
||||
``sysfs`` for all ``CPUFreq`` policies contains the string "intel_cpufreq".
|
||||
|
@ -318,10 +322,9 @@ manuals need to be consulted to get to it too.
|
|||
|
||||
For this reason, there is a list of supported processors in ``intel_pstate`` and
|
||||
the driver initialization will fail if the detected processor is not in that
|
||||
list, unless it supports the `HWP feature <Active Mode_>`_. [The interface to
|
||||
obtain all of the information listed above is the same for all of the processors
|
||||
supporting the HWP feature, which is why they all are supported by
|
||||
``intel_pstate``.]
|
||||
list, unless it supports the HWP feature. [The interface to obtain all of the
|
||||
information listed above is the same for all of the processors supporting the
|
||||
HWP feature, which is why ``intel_pstate`` works with all of them.]
|
||||
|
||||
|
||||
User Space Interface in ``sysfs``
|
||||
|
@ -425,22 +428,16 @@ argument is passed to the kernel in the command line.
|
|||
as well as the per-policy ones) are then reset to their default
|
||||
values, possibly depending on the target operation mode.]
|
||||
|
||||
That only is supported in some configurations, though (for example, if
|
||||
the `HWP feature is enabled in the processor <Active Mode With HWP_>`_,
|
||||
the operation mode of the driver cannot be changed), and if it is not
|
||||
supported in the current configuration, writes to this attribute will
|
||||
fail with an appropriate error.
|
||||
|
||||
``energy_efficiency``
|
||||
This attribute is only present on platforms, which have CPUs matching
|
||||
Kaby Lake or Coffee Lake desktop CPU model. By default
|
||||
energy efficiency optimizations are disabled on these CPU models in HWP
|
||||
mode by this driver. Enabling energy efficiency may limit maximum
|
||||
operating frequency in both HWP and non HWP mode. In non HWP mode,
|
||||
optimizations are done only in the turbo frequency range. In HWP mode,
|
||||
optimizations are done in the entire frequency range. Setting this
|
||||
attribute to "1" enables energy efficiency optimizations and setting
|
||||
to "0" disables energy efficiency optimizations.
|
||||
This attribute is only present on platforms with CPUs matching the Kaby
|
||||
Lake or Coffee Lake desktop CPU model. By default, energy-efficiency
|
||||
optimizations are disabled on these CPU models if HWP is enabled.
|
||||
Enabling energy-efficiency optimizations may limit maximum operating
|
||||
frequency with or without the HWP feature. With HWP enabled, the
|
||||
optimizations are done only in the turbo frequency range. Without it,
|
||||
they are done in the entire available frequency range. Setting this
|
||||
attribute to "1" enables the energy-efficiency optimizations and setting
|
||||
to "0" disables them.
|
||||
|
||||
Interpretation of Policy Attributes
|
||||
-----------------------------------
|
||||
|
@ -484,8 +481,8 @@ Next, the following policy attributes have special meaning if
|
|||
policy for the time interval between the last two invocations of the
|
||||
driver's utilization update callback by the CPU scheduler for that CPU.
|
||||
|
||||
One more policy attribute is present if the `HWP feature is enabled in the
|
||||
processor <Active Mode With HWP_>`_:
|
||||
One more policy attribute is present if the HWP feature is enabled in the
|
||||
processor:
|
||||
|
||||
``base_frequency``
|
||||
Shows the base frequency of the CPU. Any frequency above this will be
|
||||
|
@ -526,11 +523,11 @@ on the following rules, regardless of the current operation mode of the driver:
|
|||
|
||||
3. The global and per-policy limits can be set independently.
|
||||
|
||||
If the `HWP feature is enabled in the processor <Active Mode With HWP_>`_, the
|
||||
resulting effective values are written into its registers whenever the limits
|
||||
change in order to request its internal P-state selection logic to always set
|
||||
P-states within these limits. Otherwise, the limits are taken into account by
|
||||
scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
|
||||
In the `active mode with the HWP feature enabled <Active Mode With HWP_>`_, the
|
||||
resulting effective values are written into hardware registers whenever the
|
||||
limits change in order to request its internal P-state selection logic to always
|
||||
set P-states within these limits. Otherwise, the limits are taken into account
|
||||
by scaling governors (in the `passive mode <Passive Mode_>`_) and by the driver
|
||||
every time before setting a new P-state for a CPU.
|
||||
|
||||
Additionally, if the ``intel_pstate=per_cpu_perf_limits`` command line argument
|
||||
|
@ -541,12 +538,11 @@ at all and the only way to set the limits is by using the policy attributes.
|
|||
Energy vs Performance Hints
|
||||
---------------------------
|
||||
|
||||
If ``intel_pstate`` works in the `active mode with the HWP feature enabled
|
||||
<Active Mode With HWP_>`_ in the processor, additional attributes are present
|
||||
in every ``CPUFreq`` policy directory in ``sysfs``. They are intended to allow
|
||||
user space to help ``intel_pstate`` to adjust the processor's internal P-state
|
||||
selection logic by focusing it on performance or on energy-efficiency, or
|
||||
somewhere between the two extremes:
|
||||
If the hardware-managed P-states (HWP) is enabled in the processor, additional
|
||||
attributes, intended to allow user space to help ``intel_pstate`` to adjust the
|
||||
processor's internal P-state selection logic by focusing it on performance or on
|
||||
energy-efficiency, or somewhere between the two extremes, are present in every
|
||||
``CPUFreq`` policy directory in ``sysfs``. They are :
|
||||
|
||||
``energy_performance_preference``
|
||||
Current value of the energy vs performance hint for the given policy
|
||||
|
@ -568,8 +564,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
|
||||
|
@ -650,12 +646,14 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
|
|||
Do not register ``intel_pstate`` as the scaling driver even if the
|
||||
processor is supported by it.
|
||||
|
||||
``active``
|
||||
Register ``intel_pstate`` in the `active mode <Active Mode_>`_ to start
|
||||
with.
|
||||
|
||||
``passive``
|
||||
Register ``intel_pstate`` in the `passive mode <Passive Mode_>`_ to
|
||||
start with.
|
||||
|
||||
This option implies the ``no_hwp`` one described below.
|
||||
|
||||
``force``
|
||||
Register ``intel_pstate`` as the scaling driver instead of
|
||||
``acpi-cpufreq`` even if the latter is preferred on the given system.
|
||||
|
@ -670,13 +668,12 @@ of them have to be prepended with the ``intel_pstate=`` prefix.
|
|||
driver is used instead of ``acpi-cpufreq``.
|
||||
|
||||
``no_hwp``
|
||||
Do not enable the `hardware-managed P-states (HWP) feature
|
||||
<Active Mode With HWP_>`_ even if it is supported by the processor.
|
||||
Do not enable the hardware-managed P-states (HWP) feature even if it is
|
||||
supported by the processor.
|
||||
|
||||
``hwp_only``
|
||||
Register ``intel_pstate`` as the scaling driver only if the
|
||||
`hardware-managed P-states (HWP) feature <Active Mode With HWP_>`_ is
|
||||
supported by the processor.
|
||||
hardware-managed P-states (HWP) feature is supported by the processor.
|
||||
|
||||
``support_acpi_ppc``
|
||||
Take ACPI ``_PPC`` performance limits into account.
|
||||
|
|
|
@ -164,7 +164,8 @@ core_pattern
|
|||
%s signal number
|
||||
%t UNIX time of dump
|
||||
%h hostname
|
||||
%e executable filename (may be shortened)
|
||||
%e executable filename (may be shortened, could be changed by prctl etc)
|
||||
%f executable filename
|
||||
%E executable path
|
||||
%c maximum size of core file by resource limit RLIMIT_CORE
|
||||
%<OTHER> both are dropped
|
||||
|
|
|
@ -119,6 +119,21 @@ all zones are compacted such that free memory is available in contiguous
|
|||
blocks where possible. This can be important for example in the allocation of
|
||||
huge pages although processes will also directly compact memory as required.
|
||||
|
||||
compaction_proactiveness
|
||||
========================
|
||||
|
||||
This tunable takes a value in the range [0, 100] with a default value of
|
||||
20. This tunable determines how aggressively compaction is done in the
|
||||
background. Setting it to 0 disables proactive compaction.
|
||||
|
||||
Note that compaction has a non-trivial system-wide impact as pages
|
||||
belonging to different processes are moved around, which could also lead
|
||||
to latency spikes in unsuspecting applications. The kernel employs
|
||||
various heuristics to avoid wasting CPU cycles if it detects that
|
||||
proactive compaction is not being effective.
|
||||
|
||||
Be careful when setting it to extreme values like 100, as that may
|
||||
cause excessive background compaction activity.
|
||||
|
||||
compact_unevictable_allowed
|
||||
===========================
|
||||
|
|
|
@ -125,6 +125,9 @@ stable kernels.
|
|||
| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Marvell | ARM-MMU-500 | #582743 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
|
@ -246,17 +246,6 @@ program is loaded the kernel will print warning message, so
|
|||
this helper is only useful for experiments and prototypes.
|
||||
Tracing BPF programs are root only.
|
||||
|
||||
Q: bpf_trace_printk() helper warning
|
||||
------------------------------------
|
||||
Q: When bpf_trace_printk() helper is used the kernel prints nasty
|
||||
warning message. Why is that?
|
||||
|
||||
A: This is done to nudge program authors into better interfaces when
|
||||
programs need to pass data to user space. Like bpf_perf_event_output()
|
||||
can be used to efficiently stream data via perf ring buffer.
|
||||
BPF maps can be used for asynchronous data sharing between kernel
|
||||
and user space. bpf_trace_printk() should only be used for debugging.
|
||||
|
||||
Q: New functionality via kernel modules?
|
||||
----------------------------------------
|
||||
Q: Can BPF functionality such as new program or map types, new
|
||||
|
|
|
@ -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/
|
||||
|
|
|
@ -557,7 +557,7 @@ phase. Currently, the capabilities are any of::
|
|||
CDC_DRIVE_STATUS /* driver implements drive status */
|
||||
|
||||
The capability flag is declared *const*, to prevent drivers from
|
||||
accidentally tampering with the contents. The capability fags actually
|
||||
accidentally tampering with the contents. The capability flags actually
|
||||
inform `cdrom.c` of what the driver can do. If the drive found
|
||||
by the driver does not have the capability, is can be masked out by
|
||||
the *cdrom_device_info* variable *mask*. For instance, the SCSI CD-ROM
|
||||
|
@ -736,7 +736,7 @@ Description of routines in `cdrom.c`
|
|||
|
||||
Only a few routines in `cdrom.c` are exported to the drivers. In this
|
||||
new section we will discuss these, as well as the functions that `take
|
||||
over' the CD-ROM interface to the kernel. The header file belonging
|
||||
over` the CD-ROM interface to the kernel. The header file belonging
|
||||
to `cdrom.c` is called `cdrom.h`. Formerly, some of the contents of this
|
||||
file were placed in the file `ucdrom.h`, but this file has now been
|
||||
merged back into `cdrom.h`.
|
||||
|
|
|
@ -20,48 +20,48 @@ only ID allocation, and as a result is much more memory-efficient.
|
|||
IDR usage
|
||||
=========
|
||||
|
||||
Start by initialising an IDR, either with :c:func:`DEFINE_IDR`
|
||||
for statically allocated IDRs or :c:func:`idr_init` for dynamically
|
||||
Start by initialising an IDR, either with DEFINE_IDR()
|
||||
for statically allocated IDRs or idr_init() for dynamically
|
||||
allocated IDRs.
|
||||
|
||||
You can call :c:func:`idr_alloc` to allocate an unused ID. Look up
|
||||
the pointer you associated with the ID by calling :c:func:`idr_find`
|
||||
and free the ID by calling :c:func:`idr_remove`.
|
||||
You can call idr_alloc() to allocate an unused ID. Look up
|
||||
the pointer you associated with the ID by calling idr_find()
|
||||
and free the ID by calling idr_remove().
|
||||
|
||||
If you need to change the pointer associated with an ID, you can call
|
||||
:c:func:`idr_replace`. One common reason to do this is to reserve an
|
||||
idr_replace(). One common reason to do this is to reserve an
|
||||
ID by passing a ``NULL`` pointer to the allocation function; initialise the
|
||||
object with the reserved ID and finally insert the initialised object
|
||||
into the IDR.
|
||||
|
||||
Some users need to allocate IDs larger than ``INT_MAX``. So far all of
|
||||
these users have been content with a ``UINT_MAX`` limit, and they use
|
||||
:c:func:`idr_alloc_u32`. If you need IDs that will not fit in a u32,
|
||||
idr_alloc_u32(). If you need IDs that will not fit in a u32,
|
||||
we will work with you to address your needs.
|
||||
|
||||
If you need to allocate IDs sequentially, you can use
|
||||
:c:func:`idr_alloc_cyclic`. The IDR becomes less efficient when dealing
|
||||
idr_alloc_cyclic(). The IDR becomes less efficient when dealing
|
||||
with larger IDs, so using this function comes at a slight cost.
|
||||
|
||||
To perform an action on all pointers used by the IDR, you can
|
||||
either use the callback-based :c:func:`idr_for_each` or the
|
||||
iterator-style :c:func:`idr_for_each_entry`. You may need to use
|
||||
:c:func:`idr_for_each_entry_continue` to continue an iteration. You can
|
||||
also use :c:func:`idr_get_next` if the iterator doesn't fit your needs.
|
||||
either use the callback-based idr_for_each() or the
|
||||
iterator-style idr_for_each_entry(). You may need to use
|
||||
idr_for_each_entry_continue() to continue an iteration. You can
|
||||
also use idr_get_next() if the iterator doesn't fit your needs.
|
||||
|
||||
When you have finished using an IDR, you can call :c:func:`idr_destroy`
|
||||
When you have finished using an IDR, you can call idr_destroy()
|
||||
to release the memory used by the IDR. This will not free the objects
|
||||
pointed to from the IDR; if you want to do that, use one of the iterators
|
||||
to do it.
|
||||
|
||||
You can use :c:func:`idr_is_empty` to find out whether there are any
|
||||
You can use idr_is_empty() to find out whether there are any
|
||||
IDs currently allocated.
|
||||
|
||||
If you need to take a lock while allocating a new ID from the IDR,
|
||||
you may need to pass a restrictive set of GFP flags, which can lead
|
||||
to the IDR being unable to allocate memory. To work around this,
|
||||
you can call :c:func:`idr_preload` before taking the lock, and then
|
||||
:c:func:`idr_preload_end` after the allocation.
|
||||
you can call idr_preload() before taking the lock, and then
|
||||
idr_preload_end() after the allocation.
|
||||
|
||||
.. kernel-doc:: include/linux/idr.h
|
||||
:doc: idr sync
|
||||
|
|
|
@ -175,13 +175,20 @@ For example, to check drivers/net/wireless/ one may write::
|
|||
make coccicheck M=drivers/net/wireless/
|
||||
|
||||
To apply Coccinelle on a file basis, instead of a directory basis, the
|
||||
following command may be used::
|
||||
C variable is used by the makefile to select which files to work with.
|
||||
This variable can be used to run scripts for the entire kernel, a
|
||||
specific directory, or for a single file.
|
||||
|
||||
make C=1 CHECK="scripts/coccicheck"
|
||||
For example, to check drivers/bluetooth/bfusb.c, the value 1 is
|
||||
passed to the C variable to check files that make considers
|
||||
need to be compiled.::
|
||||
|
||||
To check only newly edited code, use the value 2 for the C flag, i.e.::
|
||||
make C=1 CHECK=scripts/coccicheck drivers/bluetooth/bfusb.o
|
||||
|
||||
make C=2 CHECK="scripts/coccicheck"
|
||||
The value 2 is passed to the C variable to check files regardless of
|
||||
whether they need to be compiled or not.::
|
||||
|
||||
make C=2 CHECK=scripts/coccicheck drivers/bluetooth/bfusb.o
|
||||
|
||||
In these modes, which work on a file basis, there is no information
|
||||
about semantic patches displayed, and no commit message proposed.
|
||||
|
|
|
@ -316,7 +316,7 @@ driver as a loadable kernel module kgdbwait will not do anything.
|
|||
Kernel parameter: ``kgdbcon``
|
||||
-----------------------------
|
||||
|
||||
The ``kgdbcon`` feature allows you to see :c:func:`printk` messages inside gdb
|
||||
The ``kgdbcon`` feature allows you to see printk() messages inside gdb
|
||||
while gdb is connected to the kernel. Kdb does not make use of the kgdbcon
|
||||
feature.
|
||||
|
||||
|
@ -432,7 +432,7 @@ This is a quick example of how to use kdb.
|
|||
``ps`` Displays only the active processes
|
||||
``ps A`` Shows all the processes
|
||||
``summary`` Shows kernel version info and memory usage
|
||||
``bt`` Get a backtrace of the current process using :c:func:`dump_stack`
|
||||
``bt`` Get a backtrace of the current process using dump_stack()
|
||||
``dmesg`` View the kernel syslog buffer
|
||||
``go`` Continue the system
|
||||
=========== =================================================================
|
||||
|
@ -724,7 +724,7 @@ The kernel debugger is organized into a number of components:
|
|||
The arch-specific portion implements:
|
||||
|
||||
- contains an arch-specific trap catcher which invokes
|
||||
:c:func:`kgdb_handle_exception` to start kgdb about doing its work
|
||||
kgdb_handle_exception() to start kgdb about doing its work
|
||||
|
||||
- translation to and from gdb specific packet format to :c:type:`pt_regs`
|
||||
|
||||
|
@ -769,7 +769,7 @@ The kernel debugger is organized into a number of components:
|
|||
config. Later run ``modprobe kdb_hello`` and the next time you
|
||||
enter the kdb shell, you can run the ``hello`` command.
|
||||
|
||||
- The implementation for :c:func:`kdb_printf` which emits messages directly
|
||||
- The implementation for kdb_printf() which emits messages directly
|
||||
to I/O drivers, bypassing the kernel log.
|
||||
|
||||
- SW / HW breakpoint management for the kdb shell
|
||||
|
@ -875,7 +875,7 @@ kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration.
|
|||
The core polled keyboard driver for PS/2 type keyboards is in
|
||||
``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core
|
||||
when kgdboc populates the callback in the array called
|
||||
:c:type:`kdb_poll_funcs[]`. The :c:func:`kdb_get_kbd_char` is the top-level
|
||||
:c:type:`kdb_poll_funcs[]`. The kdb_get_kbd_char() is the top-level
|
||||
function which polls hardware for single character input.
|
||||
|
||||
kgdboc and kms
|
||||
|
@ -887,10 +887,10 @@ that you have a video driver which has a frame buffer console and atomic
|
|||
kernel mode setting support.
|
||||
|
||||
Every time the kernel debugger is entered it calls
|
||||
:c:func:`kgdboc_pre_exp_handler` which in turn calls :c:func:`con_debug_enter`
|
||||
kgdboc_pre_exp_handler() which in turn calls con_debug_enter()
|
||||
in the virtual console layer. On resuming kernel execution, the kernel
|
||||
debugger calls :c:func:`kgdboc_post_exp_handler` which in turn calls
|
||||
:c:func:`con_debug_leave`.
|
||||
debugger calls kgdboc_post_exp_handler() which in turn calls
|
||||
con_debug_leave().
|
||||
|
||||
Any video driver that wants to be compatible with the kernel debugger
|
||||
and the atomic kms callbacks must implement the ``mode_set_base_atomic``,
|
||||
|
|
|
@ -67,9 +67,9 @@ patternProperties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- arm,integrator-ap-syscon
|
||||
- arm,integrator-cp-syscon
|
||||
- arm,integrator-sp-syscon
|
||||
- arm,integrator-ap-syscon
|
||||
- arm,integrator-cp-syscon
|
||||
- arm,integrator-sp-syscon
|
||||
- const: syscon
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -55,20 +55,20 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: arm,realview-eb-soc
|
||||
- const: simple-bus
|
||||
- const: arm,realview-eb-soc
|
||||
- const: simple-bus
|
||||
- items:
|
||||
- const: arm,realview-pb1176-soc
|
||||
- const: simple-bus
|
||||
- const: arm,realview-pb1176-soc
|
||||
- const: simple-bus
|
||||
- items:
|
||||
- const: arm,realview-pb11mp-soc
|
||||
- const: simple-bus
|
||||
- const: arm,realview-pb11mp-soc
|
||||
- const: simple-bus
|
||||
- items:
|
||||
- const: arm,realview-pba8-soc
|
||||
- const: simple-bus
|
||||
- const: arm,realview-pba8-soc
|
||||
- const: simple-bus
|
||||
- items:
|
||||
- const: arm,realview-pbx-soc
|
||||
- const: simple-bus
|
||||
- const: arm,realview-pbx-soc
|
||||
- const: simple-bus
|
||||
|
||||
patternProperties:
|
||||
"^.*syscon@[0-9a-f]+$":
|
||||
|
@ -79,35 +79,35 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: arm,realview-eb11mp-revb-syscon
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- const: arm,realview-eb11mp-revb-syscon
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-eb11mp-revc-syscon
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- const: arm,realview-eb11mp-revc-syscon
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pb1176-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- const: arm,realview-pb1176-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pb11mp-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- const: arm,realview-pb11mp-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pba8-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- const: arm,realview-pba8-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pbx-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- const: arm,realview-pbx-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -165,10 +165,10 @@ patternProperties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- arm,vexpress,v2m-p1
|
||||
- arm,vexpress,v2p-p1
|
||||
- const: simple-bus
|
||||
- enum:
|
||||
- arm,vexpress,v2m-p1
|
||||
- arm,vexpress,v2p-p1
|
||||
- const: simple-bus
|
||||
- const: simple-bus
|
||||
motherboard:
|
||||
type: object
|
||||
|
@ -186,8 +186,8 @@ patternProperties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- arm,vexpress,v2m-p1
|
||||
- arm,vexpress,v2p-p1
|
||||
- arm,vexpress,v2m-p1
|
||||
- arm,vexpress,v2p-p1
|
||||
- const: simple-bus
|
||||
arm,v2m-memory-map:
|
||||
description: This describes the memory map type.
|
||||
|
|
|
@ -15,7 +15,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm28155-ap
|
||||
- brcm,bcm28155-ap
|
||||
- const: brcm,bcm11351
|
||||
|
||||
...
|
||||
|
|
|
@ -15,7 +15,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm21664-garnet
|
||||
- brcm,bcm21664-garnet
|
||||
- const: brcm,bcm21664
|
||||
|
||||
...
|
||||
|
|
|
@ -15,7 +15,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm23550-sparrow
|
||||
- brcm,bcm23550-sparrow
|
||||
- const: brcm,bcm23550
|
||||
|
||||
...
|
||||
|
|
|
@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Broadcom Cygnus device tree bindings
|
||||
|
||||
maintainers:
|
||||
- Ray Jui <rjui@broadcom.com>
|
||||
- Scott Branden <sbranden@broadcom.com>
|
||||
- Ray Jui <rjui@broadcom.com>
|
||||
- Scott Branden <sbranden@broadcom.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
@ -16,14 +16,14 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm11300
|
||||
- brcm,bcm11320
|
||||
- brcm,bcm11350
|
||||
- brcm,bcm11360
|
||||
- brcm,bcm58300
|
||||
- brcm,bcm58302
|
||||
- brcm,bcm58303
|
||||
- brcm,bcm58305
|
||||
- brcm,bcm11300
|
||||
- brcm,bcm11320
|
||||
- brcm,bcm11350
|
||||
- brcm,bcm11360
|
||||
- brcm,bcm58300
|
||||
- brcm,bcm58302
|
||||
- brcm,bcm58303
|
||||
- brcm,bcm58305
|
||||
- const: brcm,cygnus
|
||||
|
||||
...
|
||||
|
|
|
@ -21,7 +21,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- ubnt,unifi-switch8
|
||||
- ubnt,unifi-switch8
|
||||
- const: brcm,bcm53342
|
||||
- const: brcm,hr2
|
||||
|
||||
|
|
|
@ -16,8 +16,8 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,ns2-svk
|
||||
- brcm,ns2-xmc
|
||||
- brcm,ns2-svk
|
||||
- brcm,ns2-xmc
|
||||
- const: brcm,ns2
|
||||
|
||||
...
|
||||
|
|
|
@ -24,13 +24,13 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm58522
|
||||
- brcm,bcm58525
|
||||
- brcm,bcm58535
|
||||
- brcm,bcm58622
|
||||
- brcm,bcm58623
|
||||
- brcm,bcm58625
|
||||
- brcm,bcm88312
|
||||
- brcm,bcm58522
|
||||
- brcm,bcm58525
|
||||
- brcm,bcm58535
|
||||
- brcm,bcm58622
|
||||
- brcm,bcm58623
|
||||
- brcm,bcm58625
|
||||
- brcm,bcm88312
|
||||
- const: brcm,nsp
|
||||
|
||||
...
|
||||
|
|
|
@ -16,9 +16,9 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,bcm958742k
|
||||
- brcm,bcm958742t
|
||||
- brcm,bcm958802a802x
|
||||
- brcm,bcm958742k
|
||||
- brcm,bcm958742t
|
||||
- brcm,bcm958802a802x
|
||||
- const: brcm,stingray
|
||||
|
||||
...
|
||||
|
|
|
@ -15,8 +15,8 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- brcm,vulcan-eval
|
||||
- cavium,thunderx2-cn9900
|
||||
- brcm,vulcan-eval
|
||||
- cavium,thunderx2-cn9900
|
||||
- const: brcm,vulcan-soc
|
||||
|
||||
...
|
||||
|
|
|
@ -10,6 +10,15 @@ maintainers:
|
|||
- Eric Anholt <eric@anholt.net>
|
||||
- Stefan Wahren <wahrenst@gmx.net>
|
||||
|
||||
select:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: raspberrypi,bcm2835-firmware
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
|
|
|
@ -82,12 +82,12 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: arm,coresight-cti
|
||||
- const: arm,primecell
|
||||
- const: arm,coresight-cti
|
||||
- const: arm,primecell
|
||||
- items:
|
||||
- const: arm,coresight-cti-v8-arch
|
||||
- const: arm,coresight-cti
|
||||
- const: arm,primecell
|
||||
- const: arm,coresight-cti-v8-arch
|
||||
- const: arm,coresight-cti
|
||||
- const: arm,primecell
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
@ -191,16 +191,16 @@ patternProperties:
|
|||
|
||||
anyOf:
|
||||
- required:
|
||||
- arm,trig-in-sigs
|
||||
- arm,trig-in-sigs
|
||||
- required:
|
||||
- arm,trig-out-sigs
|
||||
- arm,trig-out-sigs
|
||||
oneOf:
|
||||
- required:
|
||||
- arm,trig-conn-name
|
||||
- arm,trig-conn-name
|
||||
- required:
|
||||
- cpu
|
||||
- cpu
|
||||
- required:
|
||||
- arm,cs-dev-assoc
|
||||
- arm,cs-dev-assoc
|
||||
required:
|
||||
- reg
|
||||
|
||||
|
|
|
@ -330,8 +330,8 @@ if:
|
|||
- enable-method
|
||||
|
||||
then:
|
||||
required:
|
||||
- secondary-boot-reg
|
||||
required:
|
||||
- secondary-boot-reg
|
||||
|
||||
required:
|
||||
- device_type
|
||||
|
|
|
@ -273,8 +273,8 @@ properties:
|
|||
- fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board
|
||||
- kontron,imx6ull-n6411-som # Kontron N6411 SOM
|
||||
- myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board
|
||||
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board
|
||||
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / Bluetooth Module on Colibri Evaluation Board
|
||||
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Eval Board
|
||||
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: Kontron N6411 S Board
|
||||
|
@ -312,9 +312,12 @@ properties:
|
|||
- toradex,colibri-imx7d # Colibri iMX7 Dual Module
|
||||
- toradex,colibri-imx7d-aster # Colibri iMX7 Dual Module on Aster Carrier Board
|
||||
- toradex,colibri-imx7d-emmc # Colibri iMX7 Dual 1GB (eMMC) Module
|
||||
- toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on Aster Carrier Board
|
||||
- toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on Colibri Evaluation Board V3
|
||||
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on Colibri Evaluation Board V3
|
||||
- toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on
|
||||
# Aster Carrier Board
|
||||
- toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on
|
||||
# Colibri Evaluation Board V3
|
||||
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on
|
||||
# Colibri Evaluation Board V3
|
||||
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
|
||||
- zii,imx7d-rmu2 # ZII RMU2 Board
|
||||
- zii,imx7d-rpu2 # ZII RPU2 Board
|
||||
|
|
|
@ -14,6 +14,6 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- intel,keembay-evm
|
||||
- intel,keembay-evm
|
||||
- const: intel,keembay
|
||||
...
|
||||
|
|
|
@ -0,0 +1,44 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/keystone/ti,k3-sci-common.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Common K3 TI-SCI bindings
|
||||
|
||||
maintainers:
|
||||
- Nishanth Menon <nm@ti.com>
|
||||
|
||||
description: |
|
||||
The TI K3 family of SoCs usually have a central System Controller Processor
|
||||
that is responsible for managing various SoC-level resources like clocks,
|
||||
resets, interrupts etc. The communication with that processor is performed
|
||||
through the TI-SCI protocol.
|
||||
|
||||
Each specific device management node like a clock controller node, a reset
|
||||
controller node or an interrupt-controller node should define a common set
|
||||
of properties that enables them to implement the corresponding functionality
|
||||
over the TI-SCI protocol. The following are some of the common properties
|
||||
needed by such individual nodes. The required properties for each device
|
||||
management node is defined in the respective binding.
|
||||
|
||||
properties:
|
||||
ti,sci:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description:
|
||||
Should be a phandle to the TI-SCI System Controller node
|
||||
|
||||
ti,sci-dev-id:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
Should contain the TI-SCI device id corresponding to the device. Please
|
||||
refer to the corresponding System Controller documentation for valid
|
||||
values for the desired device.
|
||||
|
||||
ti,sci-proc-ids:
|
||||
description: Should contain a single tuple of <proc_id host_id>.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
items:
|
||||
- description: TI-SCI processor id for the remote processor device
|
||||
- description: TI-SCI host id to which processor control ownership
|
||||
should be transferred to
|
|
@ -17,22 +17,22 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- mediatek,mt2701-pericfg
|
||||
- mediatek,mt2712-pericfg
|
||||
- mediatek,mt6765-pericfg
|
||||
- mediatek,mt7622-pericfg
|
||||
- mediatek,mt7629-pericfg
|
||||
- mediatek,mt8135-pericfg
|
||||
- mediatek,mt8173-pericfg
|
||||
- mediatek,mt8183-pericfg
|
||||
- mediatek,mt8516-pericfg
|
||||
- const: syscon
|
||||
- enum:
|
||||
- mediatek,mt2701-pericfg
|
||||
- mediatek,mt2712-pericfg
|
||||
- mediatek,mt6765-pericfg
|
||||
- mediatek,mt7622-pericfg
|
||||
- mediatek,mt7629-pericfg
|
||||
- mediatek,mt8135-pericfg
|
||||
- mediatek,mt8173-pericfg
|
||||
- mediatek,mt8183-pericfg
|
||||
- mediatek,mt8516-pericfg
|
||||
- const: syscon
|
||||
- items:
|
||||
# Special case for mt7623 for backward compatibility
|
||||
- const: mediatek,mt7623-pericfg
|
||||
- const: mediatek,mt2701-pericfg
|
||||
- const: syscon
|
||||
# Special case for mt7623 for backward compatibility
|
||||
- const: mediatek,mt7623-pericfg
|
||||
- const: mediatek,mt2701-pericfg
|
||||
- const: syscon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -19,7 +19,7 @@ description: |
|
|||
reported to the APB terminator (APB Errors Handler Block).
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/simple-bus.yaml#
|
||||
- $ref: /schemas/simple-bus.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -23,7 +23,7 @@ description: |
|
|||
accessible by means of the Baikal-T1 System Controller.
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/simple-bus.yaml#
|
||||
- $ref: /schemas/simple-bus.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -1,125 +0,0 @@
|
|||
Binding for IDT VersaClock 5,6 programmable i2c clock generators.
|
||||
|
||||
The IDT VersaClock 5 and VersaClock 6 are programmable i2c clock
|
||||
generators providing from 3 to 12 output clocks.
|
||||
|
||||
==I2C device node==
|
||||
|
||||
Required properties:
|
||||
- compatible: shall be one of
|
||||
"idt,5p49v5923"
|
||||
"idt,5p49v5925"
|
||||
"idt,5p49v5933"
|
||||
"idt,5p49v5935"
|
||||
"idt,5p49v6901"
|
||||
"idt,5p49v6965"
|
||||
- reg: i2c device address, shall be 0x68 or 0x6a.
|
||||
- #clock-cells: from common clock binding; shall be set to 1.
|
||||
- clocks: from common clock binding; list of parent clock handles,
|
||||
- 5p49v5923 and
|
||||
5p49v5925 and
|
||||
5p49v6901: (required) either or both of XTAL or CLKIN
|
||||
reference clock.
|
||||
- 5p49v5933 and
|
||||
- 5p49v5935: (optional) property not present (internal
|
||||
Xtal used) or CLKIN reference
|
||||
clock.
|
||||
- clock-names: from common clock binding; clock input names, can be
|
||||
- 5p49v5923 and
|
||||
5p49v5925 and
|
||||
5p49v6901: (required) either or both of "xin", "clkin".
|
||||
- 5p49v5933 and
|
||||
- 5p49v5935: (optional) property not present or "clkin".
|
||||
|
||||
For all output ports, a corresponding, optional child node named OUT1,
|
||||
OUT2, etc. can represent a each output, and the node can be used to
|
||||
specify the following:
|
||||
|
||||
- itd,mode: can be one of the following:
|
||||
- VC5_LVPECL
|
||||
- VC5_CMOS
|
||||
- VC5_HCSL33
|
||||
- VC5_LVDS
|
||||
- VC5_CMOS2
|
||||
- VC5_CMOSD
|
||||
- VC5_HCSL25
|
||||
|
||||
- idt,voltage-microvolts: can be one of the following
|
||||
- 1800000
|
||||
- 2500000
|
||||
- 3300000
|
||||
- idt,slew-percent: Percent of normal, can be one of
|
||||
- 80
|
||||
- 85
|
||||
- 90
|
||||
- 100
|
||||
|
||||
==Mapping between clock specifier and physical pins==
|
||||
|
||||
When referencing the provided clock in the DT using phandle and
|
||||
clock specifier, the following mapping applies:
|
||||
|
||||
5P49V5923:
|
||||
0 -- OUT0_SEL_I2CB
|
||||
1 -- OUT1
|
||||
2 -- OUT2
|
||||
|
||||
5P49V5933:
|
||||
0 -- OUT0_SEL_I2CB
|
||||
1 -- OUT1
|
||||
2 -- OUT4
|
||||
|
||||
5P49V5925 and
|
||||
5P49V5935:
|
||||
0 -- OUT0_SEL_I2CB
|
||||
1 -- OUT1
|
||||
2 -- OUT2
|
||||
3 -- OUT3
|
||||
4 -- OUT4
|
||||
|
||||
5P49V6901:
|
||||
0 -- OUT0_SEL_I2CB
|
||||
1 -- OUT1
|
||||
2 -- OUT2
|
||||
3 -- OUT3
|
||||
4 -- OUT4
|
||||
|
||||
==Example==
|
||||
|
||||
/* 25MHz reference crystal */
|
||||
ref25: ref25m {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <25000000>;
|
||||
};
|
||||
|
||||
i2c-master-node {
|
||||
|
||||
/* IDT 5P49V5923 i2c clock generator */
|
||||
vc5: clock-generator@6a {
|
||||
compatible = "idt,5p49v5923";
|
||||
reg = <0x6a>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
/* Connect XIN input to 25MHz reference */
|
||||
clocks = <&ref25m>;
|
||||
clock-names = "xin";
|
||||
|
||||
OUT1 {
|
||||
itd,mode = <VC5_CMOS>;
|
||||
idt,voltage-microvolts = <1800000>;
|
||||
idt,slew-percent = <80>;
|
||||
};
|
||||
OUT2 {
|
||||
...
|
||||
};
|
||||
...
|
||||
};
|
||||
};
|
||||
|
||||
/* Consumer referencing the 5P49V5923 pin OUT1 */
|
||||
consumer {
|
||||
...
|
||||
clocks = <&vc5 1>;
|
||||
...
|
||||
}
|
|
@ -0,0 +1,154 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/idt,versaclock5.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Binding for IDT VersaClock 5 and 6 programmable I2C clock generators
|
||||
|
||||
description: |
|
||||
The IDT VersaClock 5 and VersaClock 6 are programmable I2C
|
||||
clock generators providing from 3 to 12 output clocks.
|
||||
|
||||
When referencing the provided clock in the DT using phandle and clock
|
||||
specifier, the following mapping applies:
|
||||
|
||||
- 5P49V5923:
|
||||
0 -- OUT0_SEL_I2CB
|
||||
1 -- OUT1
|
||||
2 -- OUT2
|
||||
|
||||
- 5P49V5933:
|
||||
0 -- OUT0_SEL_I2CB
|
||||
1 -- OUT1
|
||||
2 -- OUT4
|
||||
|
||||
- other parts:
|
||||
0 -- OUT0_SEL_I2CB
|
||||
1 -- OUT1
|
||||
2 -- OUT2
|
||||
3 -- OUT3
|
||||
4 -- OUT4
|
||||
|
||||
maintainers:
|
||||
- Luca Ceresoli <luca@lucaceresoli.net>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- idt,5p49v5923
|
||||
- idt,5p49v5925
|
||||
- idt,5p49v5933
|
||||
- idt,5p49v5935
|
||||
- idt,5p49v6901
|
||||
- idt,5p49v6965
|
||||
|
||||
reg:
|
||||
description: I2C device address
|
||||
enum: [ 0x68, 0x6a ]
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
patternProperties:
|
||||
"^OUT[1-4]$":
|
||||
type: object
|
||||
description:
|
||||
Description of one of the outputs (OUT1..OUT4). See "Clock1 Output
|
||||
Configuration" in the Versaclock 5/6/6E Family Register Description
|
||||
and Programming Guide.
|
||||
properties:
|
||||
idt,mode:
|
||||
description:
|
||||
The output drive mode. Values defined in dt-bindings/clk/versaclock.h
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 0
|
||||
maximum: 6
|
||||
idt,voltage-microvolt:
|
||||
description: The output drive voltage.
|
||||
enum: [ 1800000, 2500000, 3300000 ]
|
||||
idt,slew-percent:
|
||||
description: The Slew rate control for CMOS single-ended.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [ 80, 85, 90, 100 ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- idt,5p49v5933
|
||||
- idt,5p49v5935
|
||||
then:
|
||||
# Devices with builtin crystal + optional external input
|
||||
properties:
|
||||
clock-names:
|
||||
const: clkin
|
||||
clocks:
|
||||
maxItems: 1
|
||||
else:
|
||||
# Devices without builtin crystal
|
||||
properties:
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
items:
|
||||
enum: [ xin, clkin ]
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
required:
|
||||
- clock-names
|
||||
- clocks
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clk/versaclock.h>
|
||||
|
||||
/* 25MHz reference crystal */
|
||||
ref25: ref25m {
|
||||
compatible = "fixed-clock";
|
||||
#clock-cells = <0>;
|
||||
clock-frequency = <25000000>;
|
||||
};
|
||||
|
||||
i2c@0 {
|
||||
reg = <0x0 0x100>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* IDT 5P49V5923 I2C clock generator */
|
||||
vc5: clock-generator@6a {
|
||||
compatible = "idt,5p49v5923";
|
||||
reg = <0x6a>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
/* Connect XIN input to 25MHz reference */
|
||||
clocks = <&ref25m>;
|
||||
clock-names = "xin";
|
||||
|
||||
OUT1 {
|
||||
idt,drive-mode = <VC5_CMOSD>;
|
||||
idt,voltage-microvolts = <1800000>;
|
||||
idt,slew-percent = <80>;
|
||||
};
|
||||
|
||||
OUT4 {
|
||||
idt,drive-mode = <VC5_LVDS>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* Consumer referencing the 5P49V5923 pin OUT1 */
|
||||
consumer {
|
||||
/* ... */
|
||||
clocks = <&vc5 1>;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
...
|
|
@ -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
|
||||
|
|
|
@ -47,12 +47,12 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- ingenic,jz4740-cgu
|
||||
- ingenic,jz4725b-cgu
|
||||
- ingenic,jz4770-cgu
|
||||
- ingenic,jz4780-cgu
|
||||
- ingenic,x1000-cgu
|
||||
- ingenic,x1830-cgu
|
||||
- ingenic,jz4740-cgu
|
||||
- ingenic,jz4725b-cgu
|
||||
- ingenic,jz4770-cgu
|
||||
- ingenic,jz4780-cgu
|
||||
- ingenic,x1000-cgu
|
||||
- ingenic,x1830-cgu
|
||||
- const: simple-mfd
|
||||
minItems: 1
|
||||
|
||||
|
@ -68,8 +68,8 @@ properties:
|
|||
items:
|
||||
- const: ext
|
||||
- enum:
|
||||
- rtc
|
||||
- osc32k # Different name, same clock
|
||||
- rtc
|
||||
- osc32k # Different name, same clock
|
||||
|
||||
assigned-clocks:
|
||||
minItems: 1
|
||||
|
|
|
@ -1,23 +1,31 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sdm845-gpucc.yaml#
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gpucc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Graphics Clock & Reset Controller Binding for SDM845
|
||||
title: Qualcomm Graphics Clock & Reset Controller Binding
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <tdas@codeaurora.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module which supports the clocks, resets and
|
||||
power domains on SDM845.
|
||||
power domains on SDM845/SC7180/SM8150/SM8250.
|
||||
|
||||
See also dt-bindings/clock/qcom,gpucc-sdm845.h.
|
||||
See also:
|
||||
dt-bindings/clock/qcom,gpucc-sdm845.h
|
||||
dt-bindings/clock/qcom,gpucc-sc7180.h
|
||||
dt-bindings/clock/qcom,gpucc-sm8150.h
|
||||
dt-bindings/clock/qcom,gpucc-sm8250.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sdm845-gpucc
|
||||
enum:
|
||||
- qcom,sdm845-gpucc
|
||||
- qcom,sc7180-gpucc
|
||||
- qcom,sm8150-gpucc
|
||||
- qcom,sm8250-gpucc
|
||||
|
||||
clocks:
|
||||
items:
|
|
@ -65,7 +65,7 @@ properties:
|
|||
|
||||
protected-clocks:
|
||||
description:
|
||||
Protected clock specifier list as per common clock binding
|
||||
Protected clock specifier list as per common clock binding
|
||||
|
||||
vdd-gfx-supply:
|
||||
description:
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,kryocc.yaml#
|
||||
$id: http://devicetree.org/schemas/clock/qcom,msm8996-apcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm clock controller for MSM8996 CPUs
|
||||
|
@ -46,11 +46,9 @@ required:
|
|||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
# Example for msm8996
|
||||
- |
|
||||
kryocc: clock-controller@6400000 {
|
||||
compatible = "qcom,msm8996-apcc";
|
||||
reg = <0x6400000 0x90000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
|
@ -1,74 +0,0 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sc7180-gpucc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Graphics Clock & Reset Controller Binding for SC7180
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <tdas@codeaurora.org>
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module which supports the clocks, resets and
|
||||
power domains on SC7180.
|
||||
|
||||
See also dt-bindings/clock/qcom,gpucc-sc7180.h.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sc7180-gpucc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: GPLL0 main branch source
|
||||
- description: GPLL0 div branch source
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
- const: gcc_gpu_gpll0_clk_src
|
||||
- const: gcc_gpu_gpll0_div_clk_src
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-sc7180.h>
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@5090000 {
|
||||
compatible = "qcom,sc7180-gpucc";
|
||||
reg = <0x05090000 0x9000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&gcc GCC_GPU_GPLL0_CLK_SRC>,
|
||||
<&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
|
||||
clock-names = "bi_tcxo",
|
||||
"gcc_gpu_gpll0_clk_src",
|
||||
"gcc_gpu_gpll0_div_clk_src";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -0,0 +1,108 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sc7180-lpasscorecc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm LPASS Core Clock Controller Binding for SC7180
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <tdas@codeaurora.org>
|
||||
|
||||
description: |
|
||||
Qualcomm LPASS core clock control module which supports the clocks and
|
||||
power domains on SC7180.
|
||||
|
||||
See also:
|
||||
- dt-bindings/clock/qcom,lpasscorecc-sc7180.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sc7180-lpasshm
|
||||
- qcom,sc7180-lpasscorecc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: gcc_lpass_sway clock from GCC
|
||||
- description: Board XO source
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: iface
|
||||
- const: bi_tcxo
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
items:
|
||||
- description: lpass core cc register
|
||||
- description: lpass audio cc register
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: lpass_core_cc
|
||||
- const: lpass_audio_cc
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,sc7180-lpasshm
|
||||
then:
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
else:
|
||||
properties:
|
||||
reg:
|
||||
minItems: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#clock-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/clock/qcom,gcc-sc7180.h>
|
||||
#include <dt-bindings/clock/qcom,lpasscorecc-sc7180.h>
|
||||
clock-controller@63000000 {
|
||||
compatible = "qcom,sc7180-lpasshm";
|
||||
reg = <0x63000000 0x28>;
|
||||
clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>, <&rpmhcc RPMH_CXO_CLK>;
|
||||
clock-names = "iface", "bi_tcxo";
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
#include <dt-bindings/clock/qcom,gcc-sc7180.h>
|
||||
#include <dt-bindings/clock/qcom,lpasscorecc-sc7180.h>
|
||||
clock-controller@62d00000 {
|
||||
compatible = "qcom,sc7180-lpasscorecc";
|
||||
reg = <0x62d00000 0x50000>, <0x62780000 0x30000>;
|
||||
reg-names = "lpass_core_cc", "lpass_audio_cc";
|
||||
clocks = <&gcc GCC_LPASS_CFG_NOC_SWAY_CLK>, <&rpmhcc RPMH_CXO_CLK>;
|
||||
clock-names = "iface", "bi_tcxo";
|
||||
power-domains = <&lpass_hm LPASS_CORE_HM_GDSCR>;
|
||||
#clock-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -19,15 +19,15 @@ description:
|
|||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: renesas,r8a73a4-cpg-clocks # R-Mobile APE6
|
||||
- const: renesas,r8a7740-cpg-clocks # R-Mobile A1
|
||||
- const: renesas,r8a7778-cpg-clocks # R-Car M1
|
||||
- const: renesas,r8a7779-cpg-clocks # R-Car H1
|
||||
- const: renesas,r8a73a4-cpg-clocks # R-Mobile APE6
|
||||
- const: renesas,r8a7740-cpg-clocks # R-Mobile A1
|
||||
- const: renesas,r8a7778-cpg-clocks # R-Car M1
|
||||
- const: renesas,r8a7779-cpg-clocks # R-Car H1
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,r7s72100-cpg-clocks # RZ/A1H
|
||||
- const: renesas,rz-cpg-clocks # RZ/A1
|
||||
- const: renesas,sh73a0-cpg-clocks # SH-Mobile AG5
|
||||
- enum:
|
||||
- renesas,r7s72100-cpg-clocks # RZ/A1H
|
||||
- const: renesas,rz-cpg-clocks # RZ/A1
|
||||
- const: renesas,sh73a0-cpg-clocks # SH-Mobile AG5
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -4,9 +4,15 @@ The RK3288 clock controller generates and supplies clock to various
|
|||
controllers within the SoC and also implements a reset controller for SoC
|
||||
peripherals.
|
||||
|
||||
A revision of this SoC is available: rk3288w. The clock tree is a bit
|
||||
different so another dt-compatible is available. Noticed that it is only
|
||||
setting the difference but there is no automatic revision detection. This
|
||||
should be performed by bootloaders.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be "rockchip,rk3288-cru"
|
||||
- compatible: should be "rockchip,rk3288-cru" or "rockchip,rk3288w-cru" in
|
||||
case of this revision of Rockchip rk3288.
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- #clock-cells: should be 1.
|
||||
|
|
|
@ -16,7 +16,7 @@ properties:
|
|||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
compatible :
|
||||
compatible:
|
||||
enum:
|
||||
- sprd,sc9863a-ap-clk
|
||||
- sprd,sc9863a-aon-clk
|
||||
|
|
|
@ -32,8 +32,7 @@ properties:
|
|||
- const: hdmi
|
||||
|
||||
ddc:
|
||||
allOf:
|
||||
- $ref: /schemas/types.yaml#/definitions/phandle
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: >
|
||||
Phandle of the I2C controller used for DDC EDID probing
|
||||
|
||||
|
|
|
@ -162,14 +162,13 @@ required:
|
|||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
- |
|
||||
#include <dt-bindings/clock/imx8mq-clock.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/reset/imx8mq-reset.h>
|
||||
|
||||
#include <dt-bindings/clock/imx8mq-clock.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/reset/imx8mq-reset.h>
|
||||
|
||||
mipi_dsi: mipi_dsi@30a00000 {
|
||||
mipi_dsi: mipi_dsi@30a00000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "fsl,imx8mq-nwl-dsi";
|
||||
|
@ -224,4 +223,4 @@ examples:
|
|||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
@ -119,17 +119,17 @@ then:
|
|||
# The LVDS encoder can use the EXTAL or DU_DOTCLKINx clocks.
|
||||
# These clocks are optional.
|
||||
- enum:
|
||||
- extal
|
||||
- dclkin.0
|
||||
- dclkin.1
|
||||
- extal
|
||||
- dclkin.0
|
||||
- dclkin.1
|
||||
- enum:
|
||||
- extal
|
||||
- dclkin.0
|
||||
- dclkin.1
|
||||
- extal
|
||||
- dclkin.0
|
||||
- dclkin.1
|
||||
- enum:
|
||||
- extal
|
||||
- dclkin.0
|
||||
- dclkin.1
|
||||
- extal
|
||||
- dclkin.0
|
||||
- dclkin.1
|
||||
|
||||
required:
|
||||
- clock-names
|
||||
|
|
|
@ -18,16 +18,16 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- ti,ths8134a
|
||||
- ti,ths8134b
|
||||
- const: ti,ths8134
|
||||
- enum:
|
||||
- ti,ths8134a
|
||||
- ti,ths8134b
|
||||
- const: ti,ths8134
|
||||
- enum:
|
||||
- adi,adv7123
|
||||
- dumb-vga-dac
|
||||
- ti,opa362
|
||||
- ti,ths8134
|
||||
- ti,ths8135
|
||||
- adi,adv7123
|
||||
- dumb-vga-dac
|
||||
- ti,opa362
|
||||
- ti,ths8134
|
||||
- ti,ths8135
|
||||
|
||||
ports:
|
||||
type: object
|
||||
|
|
|
@ -55,11 +55,11 @@ patternProperties:
|
|||
clock-master:
|
||||
type: boolean
|
||||
description:
|
||||
Should be enabled if the host is being used in conjunction with
|
||||
another DSI host to drive the same peripheral. Hardware supporting
|
||||
such a configuration generally requires the data on both the busses
|
||||
to be driven by the same clock. Only the DSI host instance
|
||||
controlling this clock should contain this property.
|
||||
Should be enabled if the host is being used in conjunction with
|
||||
another DSI host to drive the same peripheral. Hardware supporting
|
||||
such a configuration generally requires the data on both the busses
|
||||
to be driven by the same clock. Only the DSI host instance
|
||||
controlling this clock should contain this property.
|
||||
|
||||
enforce-video-mode:
|
||||
type: boolean
|
||||
|
|
|
@ -21,9 +21,9 @@ properties:
|
|||
items:
|
||||
- enum:
|
||||
# Waveshare 3.5" 320x480 Color TFT LCD
|
||||
- waveshare,rpi-lcd-35
|
||||
- waveshare,rpi-lcd-35
|
||||
# Ozzmaker 3.5" 320x480 Color TFT LCD
|
||||
- ozzmaker,piscreen
|
||||
- ozzmaker,piscreen
|
||||
- const: ilitek,ili9486
|
||||
|
||||
spi-max-frequency:
|
||||
|
|
|
@ -13,11 +13,11 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- enum:
|
||||
- ingenic,jz4725b-ipu
|
||||
- ingenic,jz4760-ipu
|
||||
- ingenic,jz4725b-ipu
|
||||
- ingenic,jz4760-ipu
|
||||
- items:
|
||||
- const: ingenic,jz4770-ipu
|
||||
- const: ingenic,jz4760-ipu
|
||||
- const: ingenic,jz4770-ipu
|
||||
- const: ingenic,jz4760-ipu
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -58,11 +58,11 @@ properties:
|
|||
- port@0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
if:
|
||||
properties:
|
||||
|
|
|
@ -38,10 +38,10 @@ properties:
|
|||
|
||||
clocks:
|
||||
items:
|
||||
- description: GMU clock
|
||||
- description: GPU CX clock
|
||||
- description: GPU AXI clock
|
||||
- description: GPU MEMNOC clock
|
||||
- description: GMU clock
|
||||
- description: GPU CX clock
|
||||
- description: GPU AXI clock
|
||||
- description: GPU MEMNOC clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
|
@ -52,8 +52,8 @@ properties:
|
|||
|
||||
interrupts:
|
||||
items:
|
||||
- description: GMU HFI interrupt
|
||||
- description: GMU interrupt
|
||||
- description: GMU HFI interrupt
|
||||
- description: GMU interrupt
|
||||
|
||||
|
||||
interrupt-names:
|
||||
|
@ -62,14 +62,14 @@ properties:
|
|||
- const: gmu
|
||||
|
||||
power-domains:
|
||||
items:
|
||||
- description: CX power domain
|
||||
- description: GX power domain
|
||||
items:
|
||||
- description: CX power domain
|
||||
- description: GX power domain
|
||||
|
||||
power-domain-names:
|
||||
items:
|
||||
- const: cx
|
||||
- const: gx
|
||||
items:
|
||||
- const: cx
|
||||
- const: gx
|
||||
|
||||
iommus:
|
||||
maxItems: 1
|
||||
|
@ -90,13 +90,13 @@ required:
|
|||
- operating-points-v2
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gpucc-sdm845.h>
|
||||
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gpucc-sdm845.h>
|
||||
#include <dt-bindings/clock/qcom,gcc-sdm845.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
gmu: gmu@506a000 {
|
||||
gmu: gmu@506a000 {
|
||||
compatible="qcom,adreno-gmu-630.2", "qcom,adreno-gmu";
|
||||
|
||||
reg = <0x506a000 0x30000>,
|
||||
|
@ -120,4 +120,4 @@ examples:
|
|||
|
||||
iommus = <&adreno_smmu 5>;
|
||||
operating-points-v2 = <&gmu_opp_table>;
|
||||
};
|
||||
};
|
||||
|
|
|
@ -24,9 +24,9 @@ properties:
|
|||
reg: true
|
||||
reset-gpios: true
|
||||
vdd-supply:
|
||||
description: core voltage supply
|
||||
description: core voltage supply
|
||||
vddio-supply:
|
||||
description: vddio supply
|
||||
description: vddio supply
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -48,12 +48,12 @@ properties:
|
|||
port: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- enable-gpios
|
||||
- pp1800-supply
|
||||
- avdd-supply
|
||||
- avee-supply
|
||||
- compatible
|
||||
- reg
|
||||
- enable-gpios
|
||||
- pp1800-supply
|
||||
- avdd-supply
|
||||
- avee-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
@ -19,9 +19,9 @@ properties:
|
|||
backlight: true
|
||||
reset-gpios: true
|
||||
iovcc-supply:
|
||||
description: regulator that supplies the iovcc voltage
|
||||
description: regulator that supplies the iovcc voltage
|
||||
vdd-supply:
|
||||
description: regulator that supplies the vdd voltage
|
||||
description: regulator that supplies the vdd voltage
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -19,11 +19,11 @@ properties:
|
|||
backlight: true
|
||||
reset-gpios: true
|
||||
avdd-supply:
|
||||
description: regulator that supplies the AVDD voltage
|
||||
description: regulator that supplies the AVDD voltage
|
||||
dvdd-supply:
|
||||
description: regulator that supplies the DVDD voltage
|
||||
description: regulator that supplies the DVDD voltage
|
||||
cvdd-supply:
|
||||
description: regulator that supplies the CVDD voltage
|
||||
description: regulator that supplies the CVDD voltage
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -25,8 +25,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- dlink,dir-685-panel
|
||||
|
||||
- dlink,dir-685-panel
|
||||
- const: ilitek,ili9322
|
||||
|
||||
reset-gpios: true
|
||||
|
|
|
@ -13,8 +13,7 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- bananapi,lhr050h41
|
||||
|
||||
- bananapi,lhr050h41
|
||||
- const: ilitek,ili9881c
|
||||
|
||||
backlight: true
|
||||
|
|
|
@ -21,9 +21,9 @@ properties:
|
|||
backlight: true
|
||||
reset-gpios: true
|
||||
iovcc-supply:
|
||||
description: regulator that supplies the iovcc voltage
|
||||
description: regulator that supplies the iovcc voltage
|
||||
vci-supply:
|
||||
description: regulator that supplies the vci voltage
|
||||
description: regulator that supplies the vci voltage
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -19,9 +19,9 @@ properties:
|
|||
backlight: true
|
||||
reset-gpios: true
|
||||
iovcc-supply:
|
||||
description: regulator that supplies the iovcc voltage
|
||||
description: regulator that supplies the iovcc voltage
|
||||
vcc-supply:
|
||||
description: regulator that supplies the vcc voltage
|
||||
description: regulator that supplies the vcc voltage
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -25,9 +25,9 @@ properties:
|
|||
reg: true
|
||||
reset-gpios: true
|
||||
vdd-supply:
|
||||
description: regulator that supplies the vdd voltage
|
||||
description: regulator that supplies the vdd voltage
|
||||
vddi-supply:
|
||||
description: regulator that supplies the vddi voltage
|
||||
description: regulator that supplies the vddi voltage
|
||||
backlight: true
|
||||
|
||||
required:
|
||||
|
|
|
@ -27,10 +27,10 @@ properties:
|
|||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- motorola,droid4-panel # Panel from Motorola Droid4 phone
|
||||
- nokia,himalaya # Panel from Nokia N950 phone
|
||||
- tpo,taal # Panel from OMAP4 SDP board
|
||||
- const: panel-dsi-cm # Generic DSI command mode panel compatible fallback
|
||||
- motorola,droid4-panel # Panel from Motorola Droid4 phone
|
||||
- nokia,himalaya # Panel from Nokia N950 phone
|
||||
- tpo,taal # Panel from OMAP4 SDP board
|
||||
- const: panel-dsi-cm # Generic DSI command mode panel compatible fallback
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -59,7 +59,7 @@ description: |
|
|||
properties:
|
||||
|
||||
clock-frequency:
|
||||
description: Panel clock in Hz
|
||||
description: Panel clock in Hz
|
||||
|
||||
hactive:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
@ -200,15 +200,15 @@ properties:
|
|||
description: Enable double clock mode
|
||||
|
||||
required:
|
||||
- clock-frequency
|
||||
- hactive
|
||||
- vactive
|
||||
- hfront-porch
|
||||
- hback-porch
|
||||
- hsync-len
|
||||
- vfront-porch
|
||||
- vback-porch
|
||||
- vsync-len
|
||||
- clock-frequency
|
||||
- hactive
|
||||
- vactive
|
||||
- hfront-porch
|
||||
- hback-porch
|
||||
- hsync-len
|
||||
- vfront-porch
|
||||
- vback-porch
|
||||
- vsync-len
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
|
@ -10,8 +10,8 @@ maintainers:
|
|||
- Philippe CORNU <philippe.cornu@st.com>
|
||||
|
||||
description: |
|
||||
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
|
||||
panel connected using a MIPI-DSI video interface.
|
||||
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
|
||||
panel connected using a MIPI-DSI video interface.
|
||||
|
||||
allOf:
|
||||
- $ref: panel-common.yaml#
|
||||
|
|
|
@ -18,9 +18,9 @@ properties:
|
|||
reg: true
|
||||
reset-gpios: true
|
||||
vdd3-supply:
|
||||
description: core voltage supply
|
||||
description: core voltage supply
|
||||
vci-supply:
|
||||
description: voltage supply for analog circuits
|
||||
description: voltage supply for analog circuits
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Visionox model RM69299 Panels Device Tree Bindings.
|
||||
|
||||
maintainers:
|
||||
- Harigovindan P <harigovi@codeaurora.org>
|
||||
- Harigovindan P <harigovi@codeaurora.org>
|
||||
|
||||
description: |
|
||||
This binding is for display panels using a Visionox RM692999 panel.
|
||||
|
|
|
@ -45,7 +45,7 @@ properties:
|
|||
|
||||
phy-dsi-supply:
|
||||
description:
|
||||
Phandle of the regulator that provides the supply voltage.
|
||||
Phandle of the regulator that provides the supply voltage.
|
||||
|
||||
ports:
|
||||
type: object
|
||||
|
@ -147,4 +147,3 @@ examples:
|
|||
|
||||
...
|
||||
|
||||
|
||||
|
|
|
@ -78,7 +78,7 @@ properties:
|
|||
- const: vp4
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
items:
|
||||
- description: common_m DSS Master common
|
||||
- description: common_s0 DSS Shared common 0
|
||||
- description: common_s1 DSS Shared common 1
|
||||
|
|
|
@ -56,8 +56,8 @@ properties:
|
|||
|
||||
memory-region:
|
||||
description:
|
||||
phandle to a node describing reserved memory (System RAM memory)
|
||||
used by DSP (see bindings/reserved-memory/reserved-memory.txt)
|
||||
phandle to a node describing reserved memory (System RAM memory)
|
||||
used by DSP (see bindings/reserved-memory/reserved-memory.txt)
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
|
|
|
@ -177,10 +177,10 @@ properties:
|
|||
dependencies:
|
||||
# 'vendor,bool-property' is only allowed when 'vendor,string-array-property'
|
||||
# is present
|
||||
vendor,bool-property: [ vendor,string-array-property ]
|
||||
vendor,bool-property: [ 'vendor,string-array-property' ]
|
||||
# Expressing 2 properties in both orders means all of the set of properties
|
||||
# must be present or none of them.
|
||||
vendor,string-array-property: [ vendor,bool-property ]
|
||||
vendor,string-array-property: [ 'vendor,bool-property' ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: IBM FSI-attached SPI controllers
|
||||
|
||||
maintainers:
|
||||
- Eddie James <eajames@linux.ibm.com>
|
||||
- Eddie James <eajames@linux.ibm.com>
|
||||
|
||||
description: |
|
||||
This binding describes an FSI CFAM engine called the FSI2SPI. Therefore this
|
||||
|
|
|
@ -19,10 +19,8 @@ properties:
|
|||
|
||||
reg:
|
||||
items:
|
||||
- description: the I/O address containing the GPIO controller
|
||||
registers.
|
||||
- description: the I/O address containing the Chip Common A interrupt
|
||||
registers.
|
||||
- description: the I/O address containing the GPIO controller registers.
|
||||
- description: the I/O address containing the Chip Common A interrupt registers.
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
|
|
|
@ -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: |
|
||||
|
|
|
@ -13,39 +13,39 @@ properties:
|
|||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,gpio-r8a7778 # R-Car M1
|
||||
- renesas,gpio-r8a7779 # R-Car H1
|
||||
- const: renesas,rcar-gen1-gpio # R-Car Gen1
|
||||
- enum:
|
||||
- renesas,gpio-r8a7778 # R-Car M1
|
||||
- renesas,gpio-r8a7779 # R-Car H1
|
||||
- const: renesas,rcar-gen1-gpio # R-Car Gen1
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,gpio-r8a7742 # RZ/G1H
|
||||
- renesas,gpio-r8a7743 # RZ/G1M
|
||||
- renesas,gpio-r8a7744 # RZ/G1N
|
||||
- renesas,gpio-r8a7745 # RZ/G1E
|
||||
- renesas,gpio-r8a77470 # RZ/G1C
|
||||
- renesas,gpio-r8a7790 # R-Car H2
|
||||
- renesas,gpio-r8a7791 # R-Car M2-W
|
||||
- renesas,gpio-r8a7792 # R-Car V2H
|
||||
- renesas,gpio-r8a7793 # R-Car M2-N
|
||||
- renesas,gpio-r8a7794 # R-Car E2
|
||||
- const: renesas,rcar-gen2-gpio # R-Car Gen2 or RZ/G1
|
||||
- enum:
|
||||
- renesas,gpio-r8a7742 # RZ/G1H
|
||||
- renesas,gpio-r8a7743 # RZ/G1M
|
||||
- renesas,gpio-r8a7744 # RZ/G1N
|
||||
- renesas,gpio-r8a7745 # RZ/G1E
|
||||
- renesas,gpio-r8a77470 # RZ/G1C
|
||||
- renesas,gpio-r8a7790 # R-Car H2
|
||||
- renesas,gpio-r8a7791 # R-Car M2-W
|
||||
- renesas,gpio-r8a7792 # R-Car V2H
|
||||
- renesas,gpio-r8a7793 # R-Car M2-N
|
||||
- renesas,gpio-r8a7794 # R-Car E2
|
||||
- const: renesas,rcar-gen2-gpio # R-Car Gen2 or RZ/G1
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- renesas,gpio-r8a774a1 # RZ/G2M
|
||||
- renesas,gpio-r8a774b1 # RZ/G2N
|
||||
- renesas,gpio-r8a774c0 # RZ/G2E
|
||||
- renesas,gpio-r8a7795 # R-Car H3
|
||||
- renesas,gpio-r8a7796 # R-Car M3-W
|
||||
- renesas,gpio-r8a77961 # R-Car M3-W+
|
||||
- renesas,gpio-r8a77965 # R-Car M3-N
|
||||
- renesas,gpio-r8a77970 # R-Car V3M
|
||||
- renesas,gpio-r8a77980 # R-Car V3H
|
||||
- renesas,gpio-r8a77990 # R-Car E3
|
||||
- renesas,gpio-r8a77995 # R-Car D3
|
||||
- const: renesas,rcar-gen3-gpio # R-Car Gen3 or RZ/G2
|
||||
- enum:
|
||||
- renesas,gpio-r8a774a1 # RZ/G2M
|
||||
- renesas,gpio-r8a774b1 # RZ/G2N
|
||||
- renesas,gpio-r8a774c0 # RZ/G2E
|
||||
- renesas,gpio-r8a7795 # R-Car H3
|
||||
- renesas,gpio-r8a7796 # R-Car M3-W
|
||||
- renesas,gpio-r8a77961 # R-Car M3-W+
|
||||
- renesas,gpio-r8a77965 # R-Car M3-N
|
||||
- renesas,gpio-r8a77970 # R-Car V3M
|
||||
- renesas,gpio-r8a77980 # R-Car V3H
|
||||
- renesas,gpio-r8a77990 # R-Car E3
|
||||
- renesas,gpio-r8a77995 # R-Car D3
|
||||
- const: renesas,rcar-gen3-gpio # R-Car Gen3 or RZ/G2
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -26,7 +26,8 @@ properties:
|
|||
- description: AXI/master interface clock
|
||||
- description: GPU core clock
|
||||
- description: Shader clock (only required if GPU has feature PIPE_3D)
|
||||
- description: AHB/slave interface clock (only required if GPU can gate slave interface independently)
|
||||
- description: AHB/slave interface clock (only required if GPU can gate
|
||||
slave interface independently)
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
|
|
|
@ -1,39 +0,0 @@
|
|||
Qualcomm Hardware Mutex Block:
|
||||
|
||||
The hardware block provides mutexes utilized between different processors on
|
||||
the SoC as part of the communication protocol used by these processors.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be one of:
|
||||
"qcom,sfpb-mutex",
|
||||
"qcom,tcsr-mutex"
|
||||
|
||||
- syscon:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: one cell containing:
|
||||
syscon phandle
|
||||
offset of the hwmutex block within the syscon
|
||||
stride of the hwmutex registers
|
||||
|
||||
- #hwlock-cells:
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: must be 1, the specified cell represent the lock id
|
||||
(hwlock standard property, see hwlock.txt)
|
||||
|
||||
Example:
|
||||
|
||||
tcsr_mutex_block: syscon@fd484000 {
|
||||
compatible = "syscon";
|
||||
reg = <0xfd484000 0x2000>;
|
||||
};
|
||||
|
||||
hwlock@fd484000 {
|
||||
compatible = "qcom,tcsr-mutex";
|
||||
syscon = <&tcsr_mutex_block 0 0x80>;
|
||||
|
||||
#hwlock-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,42 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/hwlock/qcom-hwspinlock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Hardware Mutex Block
|
||||
|
||||
maintainers:
|
||||
- Bjorn Andersson <bjorn.andersson@linaro.org>
|
||||
|
||||
description:
|
||||
The hardware block provides mutexes utilized between different processors on
|
||||
the SoC as part of the communication protocol used by these processors.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sfpb-mutex
|
||||
- qcom,tcsr-mutex
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#hwlock-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#hwlock-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
tcsr_mutex: hwlock@1f40000 {
|
||||
compatible = "qcom,tcsr-mutex";
|
||||
reg = <0x01f40000 0x40000>;
|
||||
#hwlock-cells = <1>;
|
||||
};
|
||||
...
|
|
@ -19,7 +19,7 @@ description: |+
|
|||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,axi-fan-control-1.00.a
|
||||
- adi,axi-fan-control-1.00.a
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
@ -20,22 +20,22 @@ properties:
|
|||
- const: fsl,imx1-i2c
|
||||
- items:
|
||||
- enum:
|
||||
- fsl,imx25-i2c
|
||||
- fsl,imx27-i2c
|
||||
- fsl,imx31-i2c
|
||||
- fsl,imx50-i2c
|
||||
- fsl,imx51-i2c
|
||||
- fsl,imx53-i2c
|
||||
- fsl,imx6q-i2c
|
||||
- fsl,imx6sl-i2c
|
||||
- fsl,imx6sx-i2c
|
||||
- fsl,imx6sll-i2c
|
||||
- fsl,imx6ul-i2c
|
||||
- fsl,imx7s-i2c
|
||||
- fsl,imx8mq-i2c
|
||||
- fsl,imx8mm-i2c
|
||||
- fsl,imx8mn-i2c
|
||||
- fsl,imx8mp-i2c
|
||||
- fsl,imx25-i2c
|
||||
- fsl,imx27-i2c
|
||||
- fsl,imx31-i2c
|
||||
- fsl,imx50-i2c
|
||||
- fsl,imx51-i2c
|
||||
- fsl,imx53-i2c
|
||||
- fsl,imx6q-i2c
|
||||
- fsl,imx6sl-i2c
|
||||
- fsl,imx6sx-i2c
|
||||
- fsl,imx6sll-i2c
|
||||
- fsl,imx6ul-i2c
|
||||
- fsl,imx7s-i2c
|
||||
- fsl,imx8mq-i2c
|
||||
- fsl,imx8mm-i2c
|
||||
- fsl,imx8mn-i2c
|
||||
- fsl,imx8mp-i2c
|
||||
- const: fsl,imx21-i2c
|
||||
|
||||
reg:
|
||||
|
|
|
@ -14,6 +14,7 @@ Required properties:
|
|||
"mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629
|
||||
"mediatek,mt8173-i2c": for MediaTek MT8173
|
||||
"mediatek,mt8183-i2c": for MediaTek MT8183
|
||||
"mediatek,mt8192-i2c": for MediaTek MT8192
|
||||
"mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516
|
||||
- reg: physical base address of the controller and dma base, length of memory
|
||||
mapped region.
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -16,8 +16,8 @@ allOf:
|
|||
required:
|
||||
- mrvl,i2c-polling
|
||||
then:
|
||||
required:
|
||||
- interrupts
|
||||
required:
|
||||
- interrupts
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
@ -72,6 +72,16 @@ wants to support one of the below features, it should adapt these bindings.
|
|||
this information to adapt power management to keep the arbitration awake
|
||||
all the time, for example. Can not be combined with 'single-master'.
|
||||
|
||||
- pinctrl
|
||||
add extra pinctrl to configure SCL/SDA pins to GPIO function for bus
|
||||
recovery, call it "gpio" or "recovery" (deprecated) state
|
||||
|
||||
- scl-gpios
|
||||
specify the gpio related to SCL pin. Used for GPIO bus recovery.
|
||||
|
||||
- sda-gpios
|
||||
specify the gpio related to SDA pin. Optional for GPIO bus recovery.
|
||||
|
||||
- single-master
|
||||
states that there is no other master active on this bus. The OS can use
|
||||
this information to detect a stalled bus more reliably, for example.
|
||||
|
|
|
@ -26,6 +26,9 @@ properties:
|
|||
- items:
|
||||
- const: allwinner,sun50i-a64-i2c
|
||||
- const: allwinner,sun6i-a31-i2c
|
||||
- items:
|
||||
- const: allwinner,sun50i-a100-i2c
|
||||
- const: allwinner,sun6i-a31-i2c
|
||||
- items:
|
||||
- const: allwinner,sun50i-h6-i2c
|
||||
- const: allwinner,sun6i-a31-i2c
|
||||
|
|
|
@ -10,6 +10,7 @@ Required properties:
|
|||
"renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC.
|
||||
"renesas,i2c-r8a774b1" if the device is a part of a R8A774B1 SoC.
|
||||
"renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC.
|
||||
"renesas,i2c-r8a774e1" if the device is a part of a R8A774E1 SoC.
|
||||
"renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
|
||||
"renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
|
||||
"renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC.
|
||||
|
|
|
@ -11,6 +11,7 @@ Required properties:
|
|||
- "renesas,iic-r8a774a1" (RZ/G2M)
|
||||
- "renesas,iic-r8a774b1" (RZ/G2N)
|
||||
- "renesas,iic-r8a774c0" (RZ/G2E)
|
||||
- "renesas,iic-r8a774e1" (RZ/G2H)
|
||||
- "renesas,iic-r8a7790" (R-Car H2)
|
||||
- "renesas,iic-r8a7791" (R-Car M2-W)
|
||||
- "renesas,iic-r8a7792" (R-Car V2H)
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue