* [PATCH 2/2] Documentation/arm/sa1100/assabet: Fix 'make assabet_defconfig' command
From: Jonathan Neuschäfer @ 2019-08-08 16:58 UTC (permalink / raw)
To: linux-doc
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Neuschäfer,
linux-arm-kernel, Jonathan Corbet
In-Reply-To: <20190808165929.16946-1-j.neuschaefer@gmx.net>
"make assabet_config" doesn't work.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/arm/sa1100/assabet.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/arm/sa1100/assabet.rst b/Documentation/arm/sa1100/assabet.rst
index 3e704831c311..a761e128fb08 100644
--- a/Documentation/arm/sa1100/assabet.rst
+++ b/Documentation/arm/sa1100/assabet.rst
@@ -14,7 +14,7 @@ Building the kernel
To build the kernel with current defaults::
- make assabet_config
+ make assabet_defconfig
make oldconfig
make zImage
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/2] Documentation/arm/sa1100: Remove some obsolete documentation
From: Jonathan Neuschäfer @ 2019-08-08 16:58 UTC (permalink / raw)
To: linux-doc
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Neuschäfer,
linux-arm-kernel, Jonathan Corbet
The support for the following boards, among others, was removed in 2004
with commit "[ARM] Remove broken SA1100 machine support.":
- ADS Bitsy
- Brutus
- Freebird
- ADS GraphicsClient Plus
- ADS GraphicsMaster
- Höft & Wessel Webpanel
- Compaq Itsy
- nanoEngine
- Pangolin
- PLEB
- Yopy
Tifon support has been removed in 2.4.3.3.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/arm/sa1100/adsbitsy.rst | 51 ----------
Documentation/arm/sa1100/brutus.rst | 69 -------------
Documentation/arm/sa1100/freebird.rst | 25 -----
Documentation/arm/sa1100/graphicsclient.rst | 102 --------------------
Documentation/arm/sa1100/graphicsmaster.rst | 60 ------------
Documentation/arm/sa1100/huw_webpanel.rst | 21 ----
Documentation/arm/sa1100/index.rst | 12 ---
Documentation/arm/sa1100/itsy.rst | 47 ---------
Documentation/arm/sa1100/nanoengine.rst | 11 ---
Documentation/arm/sa1100/pangolin.rst | 29 ------
Documentation/arm/sa1100/pleb.rst | 13 ---
Documentation/arm/sa1100/tifon.rst | 7 --
Documentation/arm/sa1100/yopy.rst | 5 -
13 files changed, 452 deletions(-)
delete mode 100644 Documentation/arm/sa1100/adsbitsy.rst
delete mode 100644 Documentation/arm/sa1100/brutus.rst
delete mode 100644 Documentation/arm/sa1100/freebird.rst
delete mode 100644 Documentation/arm/sa1100/graphicsclient.rst
delete mode 100644 Documentation/arm/sa1100/graphicsmaster.rst
delete mode 100644 Documentation/arm/sa1100/huw_webpanel.rst
delete mode 100644 Documentation/arm/sa1100/itsy.rst
delete mode 100644 Documentation/arm/sa1100/nanoengine.rst
delete mode 100644 Documentation/arm/sa1100/pangolin.rst
delete mode 100644 Documentation/arm/sa1100/pleb.rst
delete mode 100644 Documentation/arm/sa1100/tifon.rst
delete mode 100644 Documentation/arm/sa1100/yopy.rst
diff --git a/Documentation/arm/sa1100/adsbitsy.rst b/Documentation/arm/sa1100/adsbitsy.rst
deleted file mode 100644
index c179cb26b682..000000000000
--- a/Documentation/arm/sa1100/adsbitsy.rst
+++ /dev/null
@@ -1,51 +0,0 @@
-===============================
-ADS Bitsy Single Board Computer
-===============================
-
-(It is different from Bitsy(iPAQ) of Compaq)
-
-For more details, contact Applied Data Systems or see
-http://www.applieddata.net/products.html
-
-The Linux support for this product has been provided by
-Woojung Huh <whuh@applieddata.net>
-
-Use 'make adsbitsy_config' before any 'make config'.
-This will set up defaults for ADS Bitsy support.
-
-The kernel zImage is linked to be loaded and executed at 0xc0400000.
-
-Linux can be used with the ADS BootLoader that ships with the
-newer rev boards. See their documentation on how to load Linux.
-
-Supported peripherals
-=====================
-
-- SA1100 LCD frame buffer (8/16bpp...sort of)
-- SA1111 USB Master
-- SA1100 serial port
-- pcmcia, compact flash
-- touchscreen(ucb1200)
-- console on LCD screen
-- serial ports (ttyS[0-2])
- - ttyS0 is default for serial console
-
-To do
-=====
-
-- everything else! :-)
-
-Notes
-=====
-
-- The flash on board is divided into 3 partitions.
- You should be careful to use flash on board.
- Its partition is different from GraphicsClient Plus and GraphicsMaster
-
-- 16bpp mode requires a different cable than what ships with the board.
- Contact ADS or look through the manual to wire your own. Currently,
- if you compile with 16bit mode support and switch into a lower bpp
- mode, the timing is off so the image is corrupted. This will be
- fixed soon.
-
-Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!
diff --git a/Documentation/arm/sa1100/brutus.rst b/Documentation/arm/sa1100/brutus.rst
deleted file mode 100644
index e1a23bee6d44..000000000000
--- a/Documentation/arm/sa1100/brutus.rst
+++ /dev/null
@@ -1,69 +0,0 @@
-======
-Brutus
-======
-
-Brutus is an evaluation platform for the SA1100 manufactured by Intel.
-For more details, see:
-
-http://developer.intel.com
-
-To compile for Brutus, you must issue the following commands::
-
- make brutus_config
- make config
- [accept all the defaults]
- make zImage
-
-The resulting kernel will end up in linux/arch/arm/boot/zImage. This file
-must be loaded at 0xc0008000 in Brutus's memory and execution started at
-0xc0008000 as well with the value of registers r0 = 0 and r1 = 16 upon
-entry.
-
-But prior to execute the kernel, a ramdisk image must also be loaded in
-memory. Use memory address 0xd8000000 for this. Note that the file
-containing the (compressed) ramdisk image must not exceed 4 MB.
-
-Typically, you'll need angelboot to load the kernel.
-The following angelboot.opt file should be used::
-
- base 0xc0008000
- entry 0xc0008000
- r0 0x00000000
- r1 0x00000010
- device /dev/ttyS0
- options "9600 8N1"
- baud 115200
- otherfile ramdisk_img.gz
- otherbase 0xd8000000
-
-Then load the kernel and ramdisk with::
-
- angelboot -f angelboot.opt zImage
-
-The first Brutus serial port (assumed to be linked to /dev/ttyS0 on your
-host PC) is used by angel to load the kernel and ramdisk image. The serial
-console is provided through the second Brutus serial port. To access it,
-you may use minicom configured with /dev/ttyS1, 9600 baud, 8N1, no flow
-control.
-
-Currently supported
-===================
-
- - RS232 serial ports
- - audio output
- - LCD screen
- - keyboard
-
-The actual Brutus support may not be complete without extra patches.
-If such patches exist, they should be found from
-ftp.netwinder.org/users/n/nico.
-
-A full PCMCIA support is still missing, although it's possible to hack
-some drivers in order to drive already inserted cards at boot time with
-little modifications.
-
-Any contribution is welcome.
-
-Please send patches to nico@fluxnic.net
-
-Have Fun !
diff --git a/Documentation/arm/sa1100/freebird.rst b/Documentation/arm/sa1100/freebird.rst
deleted file mode 100644
index 81043d0c6d64..000000000000
--- a/Documentation/arm/sa1100/freebird.rst
+++ /dev/null
@@ -1,25 +0,0 @@
-========
-Freebird
-========
-
-Freebird-1.1 is produced by Legend(C), Inc.
-`http://web.archive.org/web/*/http://www.legend.com.cn`
-and software/linux maintained by Coventive(C), Inc.
-(http://www.coventive.com)
-
-Based on the Nicolas's strongarm kernel tree.
-
-Maintainer:
-
-Chester Kuo
- - <chester@coventive.com>
- - <chester@linux.org.tw>
-
-Author:
-
-- Tim wu <timwu@coventive.com>
-- CIH <cih@coventive.com>
-- Eric Peng <ericpeng@coventive.com>
-- Jeff Lee <jeff_lee@coventive.com>
-- Allen Cheng
-- Tony Liu <tonyliu@coventive.com>
diff --git a/Documentation/arm/sa1100/graphicsclient.rst b/Documentation/arm/sa1100/graphicsclient.rst
deleted file mode 100644
index a73d61c3ce91..000000000000
--- a/Documentation/arm/sa1100/graphicsclient.rst
+++ /dev/null
@@ -1,102 +0,0 @@
-=============================================
-ADS GraphicsClient Plus Single Board Computer
-=============================================
-
-For more details, contact Applied Data Systems or see
-http://www.applieddata.net/products.html
-
-The original Linux support for this product has been provided by
-Nicolas Pitre <nico@fluxnic.net>. Continued development work by
-Woojung Huh <whuh@applieddata.net>
-
-It's currently possible to mount a root filesystem via NFS providing a
-complete Linux environment. Otherwise a ramdisk image may be used. The
-board supports MTD/JFFS, so you could also mount something on there.
-
-Use 'make graphicsclient_config' before any 'make config'. This will set up
-defaults for GraphicsClient Plus support.
-
-The kernel zImage is linked to be loaded and executed at 0xc0200000.
-Also the following registers should have the specified values upon entry::
-
- r0 = 0
- r1 = 29 (this is the GraphicsClient architecture number)
-
-Linux can be used with the ADS BootLoader that ships with the
-newer rev boards. See their documentation on how to load Linux.
-Angel is not available for the GraphicsClient Plus AFAIK.
-
-There is a board known as just the GraphicsClient that ADS used to
-produce but has end of lifed. This code will not work on the older
-board with the ADS bootloader, but should still work with Angel,
-as outlined below. In any case, if you're planning on deploying
-something en masse, you should probably get the newer board.
-
-If using Angel on the older boards, here is a typical angel.opt option file
-if the kernel is loaded through the Angel Debug Monitor::
-
- base 0xc0200000
- entry 0xc0200000
- r0 0x00000000
- r1 0x0000001d
- device /dev/ttyS1
- options "38400 8N1"
- baud 115200
- #otherfile ramdisk.gz
- #otherbase 0xc0800000
- exec minicom
-
-Then the kernel (and ramdisk if otherfile/otherbase lines above are
-uncommented) would be loaded with::
-
- angelboot -f angelboot.opt zImage
-
-Here it is assumed that the board is connected to ttyS1 on your PC
-and that minicom is preconfigured with /dev/ttyS1, 38400 baud, 8N1, no flow
-control by default.
-
-If any other bootloader is used, ensure it accomplish the same, especially
-for r0/r1 register values before jumping into the kernel.
-
-
-Supported peripherals
-=====================
-
-- SA1100 LCD frame buffer (8/16bpp...sort of)
-- on-board SMC 92C96 ethernet NIC
-- SA1100 serial port
-- flash memory access (MTD/JFFS)
-- pcmcia
-- touchscreen(ucb1200)
-- ps/2 keyboard
-- console on LCD screen
-- serial ports (ttyS[0-2])
- - ttyS0 is default for serial console
-- Smart I/O (ADC, keypad, digital inputs, etc)
- See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
- and example user space code. ps/2 keybd is multiplexed through this driver
-
-To do
-=====
-
-- UCB1200 audio with new ucb_generic layer
-- everything else! :-)
-
-Notes
-=====
-
-- The flash on board is divided into 3 partitions. mtd0 is where
- the ADS boot ROM and zImage is stored. It's been marked as
- read-only to keep you from blasting over the bootloader. :) mtd1 is
- for the ramdisk.gz image. mtd2 is user flash space and can be
- utilized for either JFFS or if you're feeling crazy, running ext2
- on top of it. If you're not using the ADS bootloader, you're
- welcome to blast over the mtd1 partition also.
-
-- 16bpp mode requires a different cable than what ships with the board.
- Contact ADS or look through the manual to wire your own. Currently,
- if you compile with 16bit mode support and switch into a lower bpp
- mode, the timing is off so the image is corrupted. This will be
- fixed soon.
-
-Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!
diff --git a/Documentation/arm/sa1100/graphicsmaster.rst b/Documentation/arm/sa1100/graphicsmaster.rst
deleted file mode 100644
index e39892514f0c..000000000000
--- a/Documentation/arm/sa1100/graphicsmaster.rst
+++ /dev/null
@@ -1,60 +0,0 @@
-========================================
-ADS GraphicsMaster Single Board Computer
-========================================
-
-For more details, contact Applied Data Systems or see
-http://www.applieddata.net/products.html
-
-The original Linux support for this product has been provided by
-Nicolas Pitre <nico@fluxnic.net>. Continued development work by
-Woojung Huh <whuh@applieddata.net>
-
-Use 'make graphicsmaster_config' before any 'make config'.
-This will set up defaults for GraphicsMaster support.
-
-The kernel zImage is linked to be loaded and executed at 0xc0400000.
-
-Linux can be used with the ADS BootLoader that ships with the
-newer rev boards. See their documentation on how to load Linux.
-
-Supported peripherals
-=====================
-
-- SA1100 LCD frame buffer (8/16bpp...sort of)
-- SA1111 USB Master
-- on-board SMC 92C96 ethernet NIC
-- SA1100 serial port
-- flash memory access (MTD/JFFS)
-- pcmcia, compact flash
-- touchscreen(ucb1200)
-- ps/2 keyboard
-- console on LCD screen
-- serial ports (ttyS[0-2])
- - ttyS0 is default for serial console
-- Smart I/O (ADC, keypad, digital inputs, etc)
- See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
- and example user space code. ps/2 keybd is multiplexed through this driver
-
-To do
-=====
-
-- everything else! :-)
-
-Notes
-=====
-
-- The flash on board is divided into 3 partitions. mtd0 is where
- the zImage is stored. It's been marked as read-only to keep you
- from blasting over the bootloader. :) mtd1 is
- for the ramdisk.gz image. mtd2 is user flash space and can be
- utilized for either JFFS or if you're feeling crazy, running ext2
- on top of it. If you're not using the ADS bootloader, you're
- welcome to blast over the mtd1 partition also.
-
-- 16bpp mode requires a different cable than what ships with the board.
- Contact ADS or look through the manual to wire your own. Currently,
- if you compile with 16bit mode support and switch into a lower bpp
- mode, the timing is off so the image is corrupted. This will be
- fixed soon.
-
-Any contribution can be sent to nico@fluxnic.net and will be greatly welcome!
diff --git a/Documentation/arm/sa1100/huw_webpanel.rst b/Documentation/arm/sa1100/huw_webpanel.rst
deleted file mode 100644
index 1dc7ccb165f0..000000000000
--- a/Documentation/arm/sa1100/huw_webpanel.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-=======================
-Hoeft & Wessel Webpanel
-=======================
-
-The HUW_WEBPANEL is a product of the german company Hoeft & Wessel AG
-
-If you want more information, please visit
-http://www.hoeft-wessel.de
-
-To build the kernel::
-
- make huw_webpanel_config
- make oldconfig
- [accept all defaults]
- make zImage
-
-Mostly of the work is done by:
-Roman Jordan jor@hoeft-wessel.de
-Christoph Schulz schu@hoeft-wessel.de
-
-2000/12/18/
diff --git a/Documentation/arm/sa1100/index.rst b/Documentation/arm/sa1100/index.rst
index 68c2a280a745..c9aed43280ff 100644
--- a/Documentation/arm/sa1100/index.rst
+++ b/Documentation/arm/sa1100/index.rst
@@ -7,19 +7,7 @@ Intel StrongARM 1100
.. toctree::
:maxdepth: 1
- adsbitsy
assabet
- brutus
cerf
- freebird
- graphicsclient
- graphicsmaster
- huw_webpanel
- itsy
lart
- nanoengine
- pangolin
- pleb
serial_uart
- tifon
- yopy
diff --git a/Documentation/arm/sa1100/itsy.rst b/Documentation/arm/sa1100/itsy.rst
deleted file mode 100644
index f49896ba3ef1..000000000000
--- a/Documentation/arm/sa1100/itsy.rst
+++ /dev/null
@@ -1,47 +0,0 @@
-====
-Itsy
-====
-
-Itsy is a research project done by the Western Research Lab, and Systems
-Research Center in Palo Alto, CA. The Itsy project is one of several
-research projects at Compaq that are related to pocket computing.
-
-For more information, see:
-
- http://www.hpl.hp.com/downloads/crl/itsy/
-
-Notes on initial 2.4 Itsy support (8/27/2000) :
-
-The port was done on an Itsy version 1.5 machine with a daughtercard with
-64 Meg of DRAM and 32 Meg of Flash. The initial work includes support for
-serial console (to see what you're doing). No other devices have been
-enabled.
-
-To build, do a "make menuconfig" (or xmenuconfig) and select Itsy support.
-Disable Flash and LCD support. and then do a make zImage.
-Finally, you will need to cd to arch/arm/boot/tools and execute a make there
-to build the params-itsy program used to boot the kernel.
-
-In order to install the port of 2.4 to the itsy, You will need to set the
-configuration parameters in the monitor as follows::
-
- Arg 1:0x08340000, Arg2: 0xC0000000, Arg3:18 (0x12), Arg4:0
-
-Make sure the start-routine address is set to 0x00060000.
-
-Next, flash the params-itsy program to 0x00060000 ("p 1 0x00060000" in the
-flash menu) Flash the kernel in arch/arm/boot/zImage into 0x08340000
-("p 1 0x00340000"). Finally flash an initial ramdisk into 0xC8000000
-("p 2 0x0") We used ramdisk-2-30.gz from the 0.11 version directory on
-handhelds.org.
-
-The serial connection we established was at:
-
-8-bit data, no parity, 1 stop bit(s), 115200.00 b/s. in the monitor, in the
-params-itsy program, and in the kernel itself. This can be changed, but
-not easily. The monitor parameters are easily changed, the params program
-setup is assembly outl's, and the kernel is a configuration item specific to
-the itsy. (i.e. grep for CONFIG_SA1100_ITSY and you'll find where it is.)
-
-
-This should get you a properly booting 2.4 kernel on the itsy.
diff --git a/Documentation/arm/sa1100/nanoengine.rst b/Documentation/arm/sa1100/nanoengine.rst
deleted file mode 100644
index 47f1a14cf98a..000000000000
--- a/Documentation/arm/sa1100/nanoengine.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-==========
-nanoEngine
-==========
-
-"nanoEngine" is a SA1110 based single board computer from
-Bright Star Engineering Inc. See www.brightstareng.com/arm
-for more info.
-(Ref: Stuart Adams <sja@brightstareng.com>)
-
-Also visit Larry Doolittle's "Linux for the nanoEngine" site:
-http://www.brightstareng.com/arm/nanoeng.htm
diff --git a/Documentation/arm/sa1100/pangolin.rst b/Documentation/arm/sa1100/pangolin.rst
deleted file mode 100644
index f0c5c1618553..000000000000
--- a/Documentation/arm/sa1100/pangolin.rst
+++ /dev/null
@@ -1,29 +0,0 @@
-========
-Pangolin
-========
-
-Pangolin is a StrongARM 1110-based evaluation platform produced
-by Dialogue Technology (http://www.dialogue.com.tw/).
-It has EISA slots for ease of configuration with SDRAM/Flash
-memory card, USB/Serial/Audio card, Compact Flash card,
-PCMCIA/IDE card and TFT-LCD card.
-
-To compile for Pangolin, you must issue the following commands::
-
- make pangolin_config
- make oldconfig
- make zImage
-
-Supported peripherals
-=====================
-
-- SA1110 serial port (UART1/UART2/UART3)
-- flash memory access
-- compact flash driver
-- UDA1341 sound driver
-- SA1100 LCD controller for 800x600 16bpp TFT-LCD
-- MQ-200 driver for 800x600 16bpp TFT-LCD
-- Penmount(touch panel) driver
-- PCMCIA driver
-- SMC91C94 LAN driver
-- IDE driver (experimental)
diff --git a/Documentation/arm/sa1100/pleb.rst b/Documentation/arm/sa1100/pleb.rst
deleted file mode 100644
index d5b732967aa3..000000000000
--- a/Documentation/arm/sa1100/pleb.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-====
-PLEB
-====
-
-The PLEB project was started as a student initiative at the School of
-Computer Science and Engineering, University of New South Wales to make a
-pocket computer capable of running the Linux Kernel.
-
-PLEB support has yet to be fully integrated.
-
-For more information, see:
-
- http://www.cse.unsw.edu.au
diff --git a/Documentation/arm/sa1100/tifon.rst b/Documentation/arm/sa1100/tifon.rst
deleted file mode 100644
index c26e910b9ea7..000000000000
--- a/Documentation/arm/sa1100/tifon.rst
+++ /dev/null
@@ -1,7 +0,0 @@
-=====
-Tifon
-=====
-
-More info has to come...
-
-Contact: Peter Danielsson <peter.danielsson@era-t.ericsson.se>
diff --git a/Documentation/arm/sa1100/yopy.rst b/Documentation/arm/sa1100/yopy.rst
deleted file mode 100644
index 5b35a5f61a44..000000000000
--- a/Documentation/arm/sa1100/yopy.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-====
-Yopy
-====
-
-See http://www.yopydeveloper.org for more.
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: usb zero copy dma handling
From: Russell King - ARM Linux admin @ 2019-08-08 16:57 UTC (permalink / raw)
To: Christoph Hellwig
Cc: yvahkhfo.1df7f8c2, linux-usb, security, linux-arm-kernel
In-Reply-To: <20190808161015.GA8470@infradead.org>
On Thu, Aug 08, 2019 at 09:10:15AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f8c2@hashmail.org wrote:
> > --- a/drivers/usb/core/devio.c
> > +++ b/drivers/usb/core/devio.c
> > @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
> > usbm->vma_use_count = 1;
> > INIT_LIST_HEAD(&usbm->memlist);
> >
> > +#ifdef CONFIG_X86
> > if (remap_pfn_range(vma, vma->vm_start,
> > virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> > size, vma->vm_page_prot) < 0) {
> > +#else /* !CONFIG_X86 */
> > + if (dma_mmap_coherent(ps->dev->bus->sysdev,
> > + vma, mem, dma_handle, size) < 0) {
> > +#endif /* !CONFIG_X86 */
>
> Doing the dma_mmap_coherent unconditionally is the right thing here.
So what if usbm->mem is from kmalloc because the host doesn't support DMA?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V1, 1/2] media: dt-bindings: media: i2c: Add bindings for ov8856
From: Sakari Ailus @ 2019-08-08 16:54 UTC (permalink / raw)
To: dongchun.zhu
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, shengnan.wang,
Ben Kao, tfiga, louis.kuo, sj.huang, robh+dt, linux-mediatek,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190808092215.5608-2-dongchun.zhu@mediatek.com>
Hi Dongchun,
(Cc'ing Ben, too.)
On Thu, Aug 08, 2019 at 05:22:14PM +0800, dongchun.zhu@mediatek.com wrote:
> From: Dongchun Zhu <dongchun.zhu@mediatek.com>
>
> Add device tree binding documentation for the ov8856 camera sensor.
>
> Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> ---
> .../devicetree/bindings/media/i2c/ov8856.txt | 41 ++++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 42 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov8856.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.txt b/Documentation/devicetree/bindings/media/i2c/ov8856.txt
> new file mode 100644
> index 0000000..96b10e0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov8856.txt
> @@ -0,0 +1,41 @@
> +* Omnivision OV8856 MIPI CSI-2 sensor
> +
> +Required Properties:
> +- compatible: shall be "ovti,ov8856"
> +- clocks: reference to the xvclk input clock
> +- clock-names: shall be "xvclk"
Could you add "clock-frequency" property here, please, and specify the
upper and lower limits?
> +- avdd-supply: Analog voltage supply, 2.8 volts
> +- dovdd-supply: Digital I/O voltage supply, 1.8 volts
> +- dvdd-supply: Digital core voltage supply, 1.2 volts
> +- reset-gpios: Low active reset gpio
> +
> +The device node shall contain one 'port' child node with an
> +'endpoint' subnode for its digital output video port,
> +in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +The endpoint optional property 'data-lanes' shall be "<0 1 3 4>".
If you don't support lane reordering, then monotonically incrementing lane
numbers from 1 onwards are recommended.
Please also make the property mandatory.
> +
> +Example:
> +&i2c7 {
> + ov8856: camera-sensor@10 {
> + compatible = "ovti,ov8856";
> + reg = <0x10>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&clk_24m_cam>;
> +
> + clocks = <&cru SCLK_TESTCLKOUT1>;
> + clock-names = "xvclk";
> +
> + avdd-supply = <&mt6358_vcama2_reg>;
> + dvdd-supply = <&mt6358_vcamd_reg>;
> + dovdd-supply = <&mt6358_vcamio_reg>;
> + reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
> +
> + port {
> + wcam_out: endpoint {
> + remote-endpoint = <&mipi_in_wcam>;
> + data-lanes = <0 1 3 4>;
> + };
> + };
> + };
> +};
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 783569e..7746c6b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11889,6 +11889,7 @@ L: linux-media@vger.kernel.org
> T: git git://linuxtv.org/media_tree.git
> S: Maintained
> F: drivers/media/i2c/ov8856.c
> +F: Documentation/devicetree/bindings/media/i2c/ov8856.txt
>
> OMNIVISION OV9650 SENSOR DRIVER
> M: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Regards,
Sakari Ailus
sakari.ailus@linux.intel.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] PM / devfreq: passive: Use non-devm notifiers
From: Leonard Crestez @ 2019-08-08 16:54 UTC (permalink / raw)
To: MyungJoo Ham, Kyungmin Park, Chanwoo Choi
Cc: Artur Świgoń, Geert Uytterhoeven, Saravana Kannan,
Rafael J. Wysocki, Greg Kroah-Hartman, Bartosz Golaszewski,
linux-pm, Krzysztof Kozlowski, Lukasz Luba, Alexandre Bailon,
Bjorn Andersson, linux-arm-kernel
The devfreq passive governor registers and unregisters devfreq
transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers.
If devfreq itself is registered with devm then a warning is triggered on
rmmod from devm_devfreq_unregister_notifier. Call stack looks like this:
devm_devfreq_unregister_notifier+0x30/0x40
devfreq_passive_event_handler+0x4c/0x88
devfreq_remove_device.part.8+0x6c/0x9c
devm_devfreq_dev_release+0x18/0x20
release_nodes+0x1b0/0x220
devres_release_all+0x78/0x84
device_release_driver_internal+0x100/0x1c0
driver_detach+0x4c/0x90
bus_remove_driver+0x7c/0xd0
driver_unregister+0x2c/0x58
platform_driver_unregister+0x10/0x18
imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq]
This happens because devres_release_all will first remove all the nodes
into a separate todo list so the nested devres_release from
devm_devfreq_unregister_notifier won't find anything.
Fix the warning by calling the non-devm APIS for frequency notification.
Using devm wrappers is not actually useful for a governor anyway: it
relies on the devfreq core to correctly match the GOV_START/GOV_STOP
notifications.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
drivers/devfreq/governor_passive.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
The only current user of passive governor is exynos-bus; does rmmod work
for you? Maybe I'm missing something.
It also seems that no attempt is made to increase the ref count of
the passive "parent" so in theory devices can be removed while still
referenced. However that would be a separate issue.
diff --git a/drivers/devfreq/governor_passive.c b/drivers/devfreq/governor_passive.c
index 58308948b863..da485477065c 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -163,16 +163,16 @@ static int devfreq_passive_event_handler(struct devfreq *devfreq,
case DEVFREQ_GOV_START:
if (!p_data->this)
p_data->this = devfreq;
nb->notifier_call = devfreq_passive_notifier_call;
- ret = devm_devfreq_register_notifier(dev, parent, nb,
+ ret = devfreq_register_notifier(parent, nb,
DEVFREQ_TRANSITION_NOTIFIER);
break;
case DEVFREQ_GOV_STOP:
- devm_devfreq_unregister_notifier(dev, parent, nb,
- DEVFREQ_TRANSITION_NOTIFIER);
+ WARN_ON(devfreq_unregister_notifier(parent, nb,
+ DEVFREQ_TRANSITION_NOTIFIER));
break;
default:
break;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] Documentation/arm/samsung-s3c24xx: Remove stray U+FEFF character to fix title
From: Jonathan Neuschäfer @ 2019-08-08 16:48 UTC (permalink / raw)
To: linux-doc
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Neuschäfer,
linux-arm-kernel, Jonathan Corbet
It seems a UTF-8 byte order mark (the least useful kind of BOM...) snuck
into the file and broke Sphinx's detection of the title line.
Besides making arm/samsung-s3c24xx/index.html look a little better, this
patch also confines the non-index pages in arm/samsung-s3c24xx to their
own table of contents.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
Documentation/arm/samsung-s3c24xx/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/arm/samsung-s3c24xx/index.rst b/Documentation/arm/samsung-s3c24xx/index.rst
index 5b8a7f9398d8..ccb951a0bedb 100644
--- a/Documentation/arm/samsung-s3c24xx/index.rst
+++ b/Documentation/arm/samsung-s3c24xx/index.rst
@@ -1,6 +1,6 @@
.. SPDX-License-Identifier: GPL-2.0
-==========================
+==========================
Samsung S3C24XX SoC Family
==========================
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 1/2] clk: Add clk_min/max_rate entries in debugfs
From: Leonard Crestez @ 2019-08-08 16:46 UTC (permalink / raw)
To: Stephen Boyd, Geert Uytterhoeven
Cc: Michael Turquette, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190808150028.0BC1F217D7@mail.kernel.org>
On 8/8/2019 6:00 PM, Stephen Boyd wrote:
> Quoting Leonard Crestez (2019-07-02 06:27:09)
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> static void clk_dump_one(struct seq_file *s, struct clk_core *c, int level)
>> {
>> + clk_core_get_boundaries(c, &min_rate, &max_rate);
>> + if (min_rate != 0)
>> + seq_printf(s, "\"min_rate\": %lu,", min_rate);
>> + if (max_rate != ULONG_MAX)
>> + seq_printf(s, "\"max_rate\": %lu,", max_rate);
>
> What are the if conditions about? We always output the values in the
> individual files, but for some reason we don't want to do that in the
> json output?
These if conditions are an easy way to avoid spamming "min_rate": 0,
"max_rate": 18446744073709551615 in json. If you object to the
inconsistency a nice solution would to be show "null" in both debugfs
and json.
Outright hiding min/max files from debugfs is impractical, it would
require filesystem calls from clk_set_min_rate
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Rob Clark @ 2019-08-08 16:44 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Mark Rutland, Maxime Ripard, Catalin Marinas, David Airlie,
Maarten Lankhorst, LKML, dri-devel, Sean Paul, Rob Clark,
linux-arm-kernel, Daniel Vetter, Greg Kroah-Hartman,
Thomas Gleixner, Will Deacon, Allison Randal
In-Reply-To: <20190808075947.GE30308@lst.de>
On Thu, Aug 8, 2019 at 12:59 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Aug 07, 2019 at 10:30:04AM -0700, Rob Clark wrote:
> > So, we do end up using GFP_HIGHUSER, which appears to get passed thru
> > when shmem gets to the point of actually allocating pages.. not sure
> > if that just ends up being a hint, or if it guarantees that we don't
> > get something in the linear map.
> >
> > (Bear with me while I "page" this all back in.. last time I dug thru
> > the shmem code was probably pre-armv8, or at least before I had any
> > armv8 hw)
>
> GFP_HIGHUSER basically just means that this is an allocation that could
> dip into highmem, in which case it would not have a kernel mapping.
> This can happen on arm + LPAE, but not on arm64.
Just a dumb question, but why is *all* memory in the linear map on
arm64? It would seem useful to have a source of pages that is not in
the linear map.
I guess it is mapped as huge pages (or something larger than 4k pages)?
Any recommended reading to understand how/why the kernel address space
is setup the way it is (so I can ask fewer dumb questions)?
BR,
-R
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2 v2] tracing/arm64: Have max stack tracer handle the case of return address after data
From: Steven Rostedt @ 2019-08-08 16:36 UTC (permalink / raw)
To: Will Deacon
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel, mingo,
Joel Fernandes, linux-arm-kernel
In-Reply-To: <20190808162825.7klpu3ffza5zxwrt@willie-the-truck>
On Thu, 8 Aug 2019 17:28:26 +0100
Will Deacon <will@kernel.org> wrote:
> > + * Note, this may change in the future, and we will need to deal with that
> > + * if it were to happen.
> > + */
> > +#define ARCH_RET_ADDR_AFTER_LOCAL_VARS 1
>
> I know it's long already, but prefixing this with FTRACE_ would be good so
> that other code doesn't use it for anything. It's not the end of the world
> if the ftrace stack usage statistics are wonky, but if people tried to use
> this for crazy things like livepatching then we'd be in trouble.
>
> Maybe FTRACE_ARCH_FRAME_AFTER_LOCALS, which is the same length as what
> you currently have?
Note, it would still need to be prefixed with "ARCH_" as that's the way
of showing arch specific defines.
We could make it more descriptive of what it will do and not the reason
for why it is done...
ARCH_FTRACE_SHIFT_STACK_TRACER
?
-- Steve
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] drm: add cache support for arm64
From: Rob Clark @ 2019-08-08 16:32 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Sean Paul, Maxime Ripard, Catalin Marinas, Maarten Lankhorst,
LKML, dri-devel, David Airlie, Rob Clark, linux-arm-kernel,
Daniel Vetter, Greg Kroah-Hartman, Thomas Gleixner, Will Deacon,
Allison Randal
In-Reply-To: <20190808100031.GA32658@lst.de>
On Thu, Aug 8, 2019 at 3:00 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Aug 07, 2019 at 09:09:53AM -0700, Rob Clark wrote:
> > > > (Eventually I'd like to support pages passed in from userspace.. but
> > > > that is down the road.)
> > >
> > > Eww. Please talk to the iommu list before starting on that.
> >
> > This is more of a long term goal, we can't do it until we have
> > per-context/process pagetables, ofc.
> >
> > Getting a bit off topic, but I'm curious about what problems you are
> > concerned about. Userspace can shoot it's own foot, but if it is not
> > sharing GPU pagetables with other processes, it can't shoot other's
> > feet. (I'm guessing you are concerned about non-page-aligned
> > mappings?)
>
> Maybe I misunderstood what you mean above, I though you mean messing
> with page cachability attributes for userspace pages. If what you are
> looking into is just "standard" SVM I only hope that our APIs for that
> which currently are a mess are in shape by then, as all users currently
> have their own crufty and at least slightly buggy versions of that. But
> at least it is an issue that is being worked on.
ahh, ok.. and no, we wouldn't be remapping 'malloc' memory as
writecombine. We'd have to wire up better support for cached buffers.
Currently we use WC for basically all GEM buffers allocated from
kernel, since that is a good choice for most GPU workloads.. ie. CPU
isn't reading back from GPU buffers in most cases. I'm told cached
buffers are useful for compute workloads where there is more back and
forth between GPU and CPU, but we haven't really crossed that bridge
yet. Compute workloads is also were the SVM interest is.
> > > So back to the question, I'd like to understand your use case (and
> > > maybe hear from the other drm folks if that is common):
> > >
> > > - you allocate pages from shmem (why shmem, btw? if this is done by
> > > other drm drivers how do they guarantee addressability without an
> > > iommu?)
> >
> > shmem for swappable pages. I don't unpin and let things get swapped
> > out yet, but I'm told it starts to become important when you have 50
> > browser tabs open ;-)
>
> Yes, but at that point the swapping can use the kernel linear mapping
> and we are going into aliasing problems that can disturb the cache. So
> as-is this is going to problematic without new hooks into shmemfs.
>
My expectation is that we'd treat the pages as cached when handing
them back to shmemfs, and wb+inv when we take them back again from
shmemfs and re-pin. I think this works out to be basically the same
scenario as having to wb+inv when we first get the pages from shmemfs.
> > > - then the memory is either mapped to userspace or vmapped (or even
> > > both, althrough the lack of aliasing you mentioned would speak
> > > against it) as writecombine (aka arm v6+ normal uncached). Does
> > > the mapping live on until the memory is freed?
> >
> > (side note, *most* of the drm/msm supported devices are armv8, the
> > exceptions are 8060 and 8064 which are armv7.. I don't think drm/msm
> > will ever have to deal w/ armv6)
>
> Well, the point was that starting from v6 the kernels dma uncached
> really is write combine. So that applied to v7 and v8 as well.
ahh, gotcha
BR,
-R
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Szabolcs Nagy @ 2019-08-08 16:30 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org, Vincenzo Frascino,
linux-doc@vger.kernel.org, Andrey Konovalov, Kevin Brodsky,
Will Deacon, Dave Hansen, nd
In-Reply-To: <20190807155321.9648-2-catalin.marinas@arm.com>
On 07/08/2019 16:53, Catalin Marinas wrote:
> From: Vincenzo Frascino <vincenzo.frascino@arm.com>
>
> On arm64 the TCR_EL1.TBI0 bit has been always enabled hence
> the userspace (EL0) is allowed to set a non-zero value in the
> top byte but the resulting pointers are not allowed at the
> user-kernel syscall ABI boundary.
>
> With the relaxed ABI proposed through this document, it is now possible
> to pass tagged pointers to the syscalls, when these pointers are in
> memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
description needs to be updated not to restrict tags
to anon mmap.
> +3. AArch64 Tagged Address ABI Exceptions
> +-----------------------------------------
> +
> +The behaviour described in section 2, with particular reference to the
> +acceptance by the syscalls of any valid tagged pointer, is not applicable
> +to the following cases:
> +
> +- mmap() addr parameter.
> +
> +- mremap() new_address parameter.
> +
> +- prctl(PR_SET_MM, ``*``, ...) other than arg2 PR_SET_MM_MAP and
> + PR_SET_MM_MAP_SIZE.
> +
> +- prctl(PR_SET_MM, PR_SET_MM_MAP{,_SIZE}, ...) struct prctl_mm_map fields.
> +
> +Any attempt to use non-zero tagged pointers will lead to undefined
> +behaviour.
i think that brk may be affected too by whatever that's
causing problems in mmap.
otherwise the text looks good to me.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2 v2] tracing/arm64: Have max stack tracer handle the case of return address after data
From: Will Deacon @ 2019-08-08 16:28 UTC (permalink / raw)
To: Steven Rostedt
Cc: Jiping Ma, catalin.marinas, will.deacon, linux-kernel, mingo,
Joel Fernandes, linux-arm-kernel
In-Reply-To: <20190807172907.155165959@goodmis.org>
Hi Steve,
On Wed, Aug 07, 2019 at 01:28:27PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
>
> Most archs (well at least x86) store the function call return address on the
> stack before storing the local variables for the function. The max stack
> tracer depends on this in its algorithm to display the stack size of each
> function it finds in the back trace.
>
> Some archs (arm64), may store the return address (from its link register)
> just before calling a nested function. There's no reason to save the link
> register on leaf functions, as it wont be updated. This breaks the algorithm
> of the max stack tracer.
>
> Add a new define ARCH_RET_ADDR_AFTER_LOCAL_VARS that an architecture may set
> if it stores the return address (link register) after it stores the
> function's local variables, and have the stack trace shift the values of the
> mapped stack size to the appropriate functions.
>
> Link: 20190802094103.163576-1-jiping.ma2@windriver.com
>
> Reported-by: Jiping Ma <jiping.ma2@windriver.com>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> ---
> arch/arm64/include/asm/ftrace.h | 13 +++++++++++++
> kernel/trace/trace_stack.c | 14 ++++++++++++++
> 2 files changed, 27 insertions(+)
I agree with your later comment that this should NOT go to stable.
> diff --git a/arch/arm64/include/asm/ftrace.h b/arch/arm64/include/asm/ftrace.h
> index 5ab5200b2bdc..961e98618db4 100644
> --- a/arch/arm64/include/asm/ftrace.h
> +++ b/arch/arm64/include/asm/ftrace.h
> @@ -14,6 +14,19 @@
> #define MCOUNT_ADDR ((unsigned long)_mcount)
> #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE
>
> +/*
> + * Currently, gcc tends to save the link register after the local variables
> + * on the stack. This causes the max stack tracer to report the function
> + * frame sizes for the wrong functions. By defining
> + * ARCH_RET_ADDR_AFTER_LOCAL_VARS, it will tell the stack tracer to expect
> + * to find the return address on the stack after the local variables have
> + * been set up.
> + *
> + * Note, this may change in the future, and we will need to deal with that
> + * if it were to happen.
> + */
> +#define ARCH_RET_ADDR_AFTER_LOCAL_VARS 1
I know it's long already, but prefixing this with FTRACE_ would be good so
that other code doesn't use it for anything. It's not the end of the world
if the ftrace stack usage statistics are wonky, but if people tried to use
this for crazy things like livepatching then we'd be in trouble.
Maybe FTRACE_ARCH_FRAME_AFTER_LOCALS, which is the same length as what
you currently have?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Dave Martin @ 2019-08-08 16:27 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-arch, linux-doc, Szabolcs Nagy, Catalin Marinas,
Kevin Brodsky, Will Deacon, Andrey Konovalov, Vincenzo Frascino,
linux-arm-kernel
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>
On Wed, Aug 07, 2019 at 01:38:16PM -0700, Dave Hansen wrote:
[Random comments below on a couple of points]
> On 8/7/19 8:53 AM, Catalin Marinas wrote:
> > +- mmap() done by the process itself (or its parent), where either:
> > +
> > + - flags have the **MAP_ANONYMOUS** bit set
> > + - the file descriptor refers to a regular file (including those returned
> > + by memfd_create()) or **/dev/zero**
>
> What's a "regular file"? ;)
A file, as distinct from device nodes, sockets, symlinks etc.
I think this is fairly standard UNIX terminology, even though it sounds
vague:
From glibc's <bits/stat.h>:
#define __S_IFREG 0100000 /* Regular file. */
Or for POSIX test (a.k.a. "[")
-f file
True if file exists and is a regular file.
Using memfd_create() or opening /dev/zero doesn't yield a regular file
though, so perhaps those should be a separate bullet.
[...]
> > +The AArch64 Tagged Address ABI is an opt-in feature and an application can
> > +control it via **prctl()** as follows:
> > +
> > +- **PR_SET_TAGGED_ADDR_CTRL**: enable or disable the AArch64 Tagged Address
> > + ABI for the calling process.
> > +
> > + The (unsigned int) arg2 argument is a bit mask describing the control mode
> > + used:
> > +
> > + - **PR_TAGGED_ADDR_ENABLE**: enable AArch64 Tagged Address ABI. Default
> > + status is disabled.
> > +
> > + The arguments arg3, arg4, and arg5 are ignored.
>
> For previous prctl()'s, we've found that it's best to require that the
> unused arguments be 0. Without that, apps are free to put garbage
> there, which makes extending the prctl to use other arguments impossible
> in the future.
Because arg2 is already a mask of flags with some flags unallocated,
we can add a new flag for ABI extensions.
If arg3 is used someday, it may or may not be natural for 0 to mean
"default". Enabling this argument with an explicit flag in arg2 may
be cleaner than mangling the semantics of arg3 so that 0 can have
the right meaning.
Avoiding redundant 0 arguments also allows userspace to take advantage
of the glibc's variadic prototype for prctl() for example.
Not a huge deal, but that was my rationale anyway.
> Also, shouldn't this be converted over to an arch_prctl()?
Most arch-specific prctls seem to use prctl(), and arm64 already has a
few there.
arch_prctl() is x86-specific. I don't know the history.
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Maxime Ripard @ 2019-08-08 16:26 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, devicetree, Jared D . McNeill, Chen-Yu Tsai,
Rob Herring, Harald Geyer, Robin Murphy, arm-linux
In-Reply-To: <CA+E=qVdh3MHMsEC9XKe5-7O8fGTHFh76WLOgVf+PZPv7c4JE9w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2652 bytes --]
On Wed, Aug 07, 2019 at 10:36:08AM -0700, Vasily Khoruzhick wrote:
> On Wed, Aug 7, 2019 at 4:56 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Tue, Aug 06, 2019 at 07:39:26PM -0700, Vasily Khoruzhick wrote:
> > > On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > >
> > > > On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > > > > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> > > > >>
> > > > >> Vasily Khoruzhick writes:
> > > > >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > >>>>
> > > > >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > > > >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> > > > >>>>> as result 'perf top' shows no events.
> > > > >>>>
> > > > >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> > > > >>>> It could well just be that the interrupt numbers are wrong...
> > > > >>>
> > > > >>> Looks like it does, at least result looks plausible:
> > > > >>
> > > > >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> > > > >>
> > > > >> Unfortunately I wasn't aware that perf stat is a poor test for
> > > > >> the interrupts part of the node, when I added it. So I'm not too
> > > > >> surprised I got it wrong.
> > > > >>
> > > > >> However, it would be unfortunate if the node got removed completely,
> > > > >> because perf stat would not work anymore. Maybe we can only remove
> > > > >> the interrupts or just fix them even if the HW doesn't work?
> > > > >
> > > > > I'm not familiar with PMU driver. Is it possible to get it working
> > > > > without interrupts?
> > > >
> > > > Yup - you get a grumpy message from the driver, it will refuse sampling
> > > > events (the ones which weren't working anyway), and if you measure
> > > > anything for long enough that a counter overflows you'll get wonky
> > > > results. But for counting hardware events over relatively short periods
> > > > it'll still do the job.
> > >
> > > I tried to drop interrupts completely from the node but 'perf top' is
> > > still broken. Though now in different way: it complains "cycles: PMU
> > > Hardware doesn't support sampling/overflow-interrupts. Try 'perf
> > > stat'"
> >
> > I have no idea if that's the culprit, but what is the state of the
> > 0x09010000 register?
>
> What register is that and how do I check it?
It's in the CPUX Configuration block, and the bits are labelled as CPU
Debug Reset.
And if you have busybox, you can use devmem.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 00/34] put_user_pages(): miscellaneous call sites
From: Weiny, Ira @ 2019-08-08 16:25 UTC (permalink / raw)
To: John Hubbard, Michal Hocko
Cc: linux-fbdev@vger.kernel.org, Jan Kara, kvm@vger.kernel.org,
Dave Hansen, Dave Chinner, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, amd-gfx@lists.freedesktop.org,
sparclinux@vger.kernel.org, Williams, Dan J,
devel@driverdev.osuosl.org, rds-devel@oss.oracle.com,
linux-rdma@vger.kernel.org, x86@kernel.org, Matthew Wilcox,
Christoph Hellwig, Jason Gunthorpe,
xen-devel@lists.xenproject.org, devel@lists.orangefs.org,
linux-media@vger.kernel.org, intel-gfx@lists.freedesktop.org,
linux-block@vger.kernel.org, Jérôme Glisse,
linux-rpi-kernel@lists.infradead.org, ceph-devel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, LKML, linux-xfs@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Andrew Morton
In-Reply-To: <e648a7f3-6a1b-c9ea-1121-7ab69b6b173d@nvidia.com>
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> >>>> On 8/2/19 7:52 AM, Jan Kara wrote:
> >>>>> On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> >>>>>> On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> >>>>>>> On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> >>>>>>>> On Thu 01-08-19 19:19:31, john.hubbard@gmail.com wrote:
> [...]
> > Before I go on, I would like to say that the "imbalance" of
> > get_user_pages() and put_page() bothers me from a purist standpoint...
> > However, since this discussion cropped up I went ahead and ported my
> > work to Linus' current master
> > (5.3-rc3+) and in doing so I only had to steal a bit of Johns code...
> > Sorry John... :-(
> >
> > I don't have the commit messages all cleaned up and I know there may
> > be some discussion on these new interfaces but I wanted to throw this
> > series out there because I think it may be what Jan and Michal are
> > driving at (or at least in that direction.
> >
> > Right now only RDMA and DAX FS's are supported. Other users of GUP
> > will still fail on a DAX file and regular files will still be at
> > risk.[2]
> >
> > I've pushed this work (based 5.3-rc3+ (33920f1ec5bf)) here[3]:
> >
> > https://github.com/weiny2/linux-kernel/tree/linus-rdmafsdax-b0-v3
> >
> > I think the most relevant patch to this conversation is:
> >
> > https://github.com/weiny2/linux-
> kernel/commit/5d377653ba5cf11c3b716f90
> > 4b057bee6641aaf6
> >
>
> ohhh...can you please avoid using the old __put_user_pages_dirty()
> function?
Agreed... I did not like that. Part of the reason I did not post this is I'm still trying to figure out what has landed and what I can and can't depend on.
For example, Christoph H. was proposing changes to some of the GUP calls which may conflict. But I'm not sure his changes are moving forward. So rather than waiting for the dust to settle I decided to see how hard it would be to get this rebased against mainline and working. Turns out it was not too hard.
I think that is because, as time has moved on it seems that, for some users such as RDMA, a simple put_user_page() is not going to be sufficient. We need something else to allow GUP to keep track of the file pins as we discussed. So I'm starting to think some of this could go in at the same time.
> I thought I'd caught things early enough to get away with the
> rename and deletion of that. You could either:
>
> a) open code an implementation of vaddr_put_pages_dirty_lock() that
> doesn't call any of the *put_user_pages_dirty*() variants, or
>
> b) include my first patch ("") are part of your series, or
>
> c) base this on Andrews's tree, which already has merged in my first patch.
>
Yep I can do this. I did not realize that Andrew had accepted any of this work. I'll check out his tree. But I don't think he is going to accept this series through his tree. So what is the ETA on that landing in Linus' tree?
To that point I'm still not sure who would take all this as I am now touching mm, procfs, rdma, ext4, and xfs.
I just thought I would chime in with my progress because I'm to a point where things are working and so I can submit the code but I'm not sure what I can/should depend on landing... Also, now that 0day has run overnight it has found issues with this rebase so I need to clean those up... Perhaps I will base on Andrew's tree prior to doing that...
Thanks,
Ira
>
> thanks,
> --
> John Hubbard
> NVIDIA
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: fix devm_platform_ioremap_resource.cocci warnings
From: Julia Lawall @ 2019-08-08 16:10 UTC (permalink / raw)
To: Jonas Gorski
Cc: Florian Fainelli, Stephen Boyd, Michael Turquette,
Philippe Mathieu-Daud??, linux-kernel, bcm-kernel-feedback-list,
kbuild-all, linux-clk, linux-arm-kernel
From: kbuild test robot <lkp@intel.com>
drivers/clk/bcm/clk-bcm63xx-gate.c:174:1-9: WARNING: Use devm_platform_ioremap_resource for hw -> regs
Use devm_platform_ioremap_resource helper which wraps
platform_get_resource() and devm_ioremap_resource() together.
Generated by: scripts/coccinelle/api/devm_platform_ioremap_resource.cocci
Fixes: 1c099779c1e2 ("clk: add BCM63XX gated clock controller driver")
CC: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
---
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git master
head: ecb095bff5d4b8711a81968625b3b4a235d3e477
commit: 1c099779c1e2e8e0e10cdb2aecd4b35f428e9f00 clk: add BCM63XX gated clock controller driver
:::::: branch date: 15 hours ago
:::::: commit date: 6 weeks ago
clk-bcm63xx-gate.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/clk/bcm/clk-bcm63xx-gate.c
+++ b/drivers/clk/bcm/clk-bcm63xx-gate.c
@@ -146,7 +146,6 @@ static int clk_bcm63xx_probe(struct plat
{
const struct clk_bcm63xx_table_entry *entry, *table;
struct clk_bcm63xx_hw *hw;
- struct resource *r;
u8 maxbit = 0;
int i, ret;
@@ -170,8 +169,7 @@ static int clk_bcm63xx_probe(struct plat
for (i = 0; i < maxbit; i++)
hw->data.hws[i] = ERR_PTR(-ENODEV);
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hw->regs = devm_ioremap_resource(&pdev->dev, r);
+ hw->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(hw->regs))
return PTR_ERR(hw->regs);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Szabolcs Nagy @ 2019-08-08 16:20 UTC (permalink / raw)
To: Dave Hansen, Catalin Marinas,
linux-arm-kernel@lists.infradead.org
Cc: linux-arch@vger.kernel.org, Vincenzo Frascino,
linux-doc@vger.kernel.org, Andrey Konovalov, Kevin Brodsky,
Will Deacon, nd
In-Reply-To: <826a9ace-feac-c019-843e-07e23c9fd46c@intel.com>
On 07/08/2019 21:38, Dave Hansen wrote:
> On 8/7/19 8:53 AM, Catalin Marinas wrote:
>> +- mmap() done by the process itself (or its parent), where either:
>> +
>> + - flags have the **MAP_ANONYMOUS** bit set
>> + - the file descriptor refers to a regular file (including those returned
>> + by memfd_create()) or **/dev/zero**
>
> What's a "regular file"? ;)
i'd expect the posix definition.
in posix "File types include regular file, character
special file, block special file, FIFO special file,
symbolic link, socket, and directory. Other types of
files may be supported by the implementation."
where regular file is "A file that is a randomly
accessible sequence of bytes, with no further
structure imposed by the system."
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_323
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: defconfig: lpc32xx: enable lpc32xx GPIO driver
From: Sylvain Lemieux @ 2019-08-08 16:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Sylvain Lemieux, Linux ARM, Vladimir Zapolskiy
In-Reply-To: <CAK8P3a0BiOoCg4y-buu=vpPGp56w7HKUVu8gA2jyeOph11U-Kg@mail.gmail.com>
On 8/8/19 11:06 AM, Arnd Bergmann wrote:
> On Wed, Aug 7, 2019 at 4:06 PM Sylvain Lemieux <slemieux.tyco@gmail.com> wrote:
>>
>> From: Sylvain Lemieux <slemieux@tycoint.com>
>>
>> The change that allow the multiplatform build for the lpc32xx
>> platform add a new kernel config for the LPC32XX GPIO driver.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
>> ---
>> Note:
>> * This patch depend on the following patchset:
>> ARM: move lpc32xx and dove to multiplatform
>> https://www.spinics.net/lists/linux-usb/msg183095.html
>
> I did not think this was needed, as I added
>
> config GPIO_LPC32XX
> tristate "NXP LPC32XX GPIO support"
> default ARCH_LPC32XX
> depends on OF_GPIO && (ARCH_LPC32XX || COMPILE_TEST)
>
> so when running 'make lpc32xx_defconfig', I expected the
> driver to already be enabled. Did I miss something?
>
The GPIO driver is enable. This change is optional.
I added this new config to the default LPC32xx defconfig
to keep in sync with what is done for the other LPC32xx drivers.
All the LPC32xx drivers config option are listed in the defconfig.
> Arnd
>
Sylvain
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb zero copy dma handling
From: Christoph Hellwig @ 2019-08-08 16:12 UTC (permalink / raw)
To: yvahkhfo.1df7f8c2; +Cc: security, linux-usb, linux-arm-kernel
In-Reply-To: <20190808161015.GA8470@infradead.org>
On Thu, Aug 08, 2019 at 09:10:15AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f8c2@hashmail.org wrote:
> > --- a/drivers/usb/core/devio.c
> > +++ b/drivers/usb/core/devio.c
> > @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
> > usbm->vma_use_count = 1;
> > INIT_LIST_HEAD(&usbm->memlist);
> >
> > +#ifdef CONFIG_X86
> > if (remap_pfn_range(vma, vma->vm_start,
> > virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> > size, vma->vm_page_prot) < 0) {
> > +#else /* !CONFIG_X86 */
> > + if (dma_mmap_coherent(ps->dev->bus->sysdev,
> > + vma, mem, dma_handle, size) < 0) {
> > +#endif /* !CONFIG_X86 */
>
> Doing the dma_mmap_coherent unconditionally is the right thing here.
> Gavin who is on Cc has been looking into that.
Ok, tht is assuming it always is dma_alloc_* memory which apparently
it isn't. But the arch ifdef for sure is wrong.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 4/6] clk: mvebu: ap806: Fix clock name for the cluster
From: Stephen Boyd @ 2019-08-08 16:12 UTC (permalink / raw)
To: Gregory CLEMENT, Mike Turquette, linux-clk, linux-kernel
Cc: devicetree, Jason Cooper, Andrew Lunn, Antoine Tenart,
Gregory CLEMENT, Maxime Chevallier, Rob Herring, Thomas Petazzoni,
Miquèl Raynal, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190710134346.30239-5-gregory.clement@bootlin.com>
Quoting Gregory CLEMENT (2019-07-10 06:43:44)
> Actually, the clocks exposed for the cluster are not the CPU clocks, but
> the PLL clock used as entry clock for the CPU clocks. The CPU clock will
> be managed by a driver submitting in the following patches.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 3/6] clk: mvebu: add CPU clock driver for Armada 7K/8K
From: Stephen Boyd @ 2019-08-08 16:12 UTC (permalink / raw)
To: Gregory CLEMENT, Mike Turquette, linux-clk, linux-kernel
Cc: devicetree, Jason Cooper, Andrew Lunn, Antoine Tenart,
Gregory CLEMENT, Maxime Chevallier, Rob Herring, Thomas Petazzoni,
Miquèl Raynal, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190710134346.30239-4-gregory.clement@bootlin.com>
Quoting Gregory CLEMENT (2019-07-10 06:43:43)
> The CPU frequency is managed at the AP level for the Armada 7K/8K. The
> CPU frequency is modified by cluster: the CPUs of the same cluster have
> the same frequency.
>
> This patch adds the clock driver that will be used by CPUFreq, it is
> based on the work of Omri Itach <omrii@marvell.com>.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 2/6] clk: mvebu: add helper file for Armada AP and CP clocks
From: Stephen Boyd @ 2019-08-08 16:12 UTC (permalink / raw)
To: Gregory CLEMENT, Mike Turquette, linux-clk, linux-kernel
Cc: devicetree, Jason Cooper, Andrew Lunn, Antoine Tenart,
Gregory CLEMENT, Maxime Chevallier, Rob Herring, Thomas Petazzoni,
Miquèl Raynal, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190710134346.30239-3-gregory.clement@bootlin.com>
Quoting Gregory CLEMENT (2019-07-10 06:43:42)
> Clock drivers for Armada AP and Armada CP use the same function to
> generate unique clock name. A third drivers is coming with the same
> need, so it's time to move this function in a common file.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 1/6] dt-bindings: ap806: add the cluster clock node in the syscon file
From: Stephen Boyd @ 2019-08-08 16:12 UTC (permalink / raw)
To: Gregory CLEMENT, Mike Turquette, linux-clk, linux-kernel
Cc: devicetree, Jason Cooper, Andrew Lunn, Antoine Tenart,
Gregory CLEMENT, Maxime Chevallier, Rob Herring, Thomas Petazzoni,
Miquèl Raynal, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20190710134346.30239-2-gregory.clement@bootlin.com>
Quoting Gregory CLEMENT (2019-07-10 06:43:41)
> Document the device tree binding for the cluster clock controllers found
> in the Armada 7K/8K SoCs.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> ---
Applied to clk-next
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: usb zero copy dma handling
From: Christoph Hellwig @ 2019-08-08 16:10 UTC (permalink / raw)
To: yvahkhfo.1df7f8c2; +Cc: security, linux-usb, linux-arm-kernel
In-Reply-To: <20190808084636.GB15080@priv-mua.localdomain>
On Thu, Aug 08, 2019 at 10:46:36AM +0200, yvahkhfo.1df7f8c2@hashmail.org wrote:
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -238,9 +238,14 @@ static int usbdev_mmap(struct file *file, struct vm_area_struct *vma)
> usbm->vma_use_count = 1;
> INIT_LIST_HEAD(&usbm->memlist);
>
> +#ifdef CONFIG_X86
> if (remap_pfn_range(vma, vma->vm_start,
> virt_to_phys(usbm->mem) >> PAGE_SHIFT,
> size, vma->vm_page_prot) < 0) {
> +#else /* !CONFIG_X86 */
> + if (dma_mmap_coherent(ps->dev->bus->sysdev,
> + vma, mem, dma_handle, size) < 0) {
> +#endif /* !CONFIG_X86 */
Doing the dma_mmap_coherent unconditionally is the right thing here.
Gavin who is on Cc has been looking into that.
Note that you'll also need this patch which I'm going to send to Linus
this week before it properly works on x86:
http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/197b3e665b82c6027be5c68a143233df7ce5224f
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 6/6] PSCI: cpuidle: Refactor CPU suspend power_state parameter handling
From: Sudeep Holla @ 2019-08-08 16:04 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, Lorenzo Pieralisi, Linux PM, Catalin Marinas,
Daniel Lezcano, Rafael J. Wysocki, LKML, Will Deacon, LAKML
In-Reply-To: <CAPDyKFqHHwq=3XhSH_=uu5QoFkP3VYJ+2h7ENG5DNs-YzM6bNQ@mail.gmail.com>
On Thu, Aug 08, 2019 at 05:29:24PM +0200, Ulf Hansson wrote:
> On Thu, 8 Aug 2019 at 14:55, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Mon, Jul 22, 2019 at 04:37:45PM +0100, Lorenzo Pieralisi wrote:
> > > Current PSCI code handles idle state entry through the
> > > psci_cpu_suspend_enter() API, that takes an idle state index as a
> > > parameter and convert the index into a previously initialized
> > > power_state parameter before calling the PSCI.CPU_SUSPEND() with it.
> > >
> > > This is unwieldly, since it forces the PSCI firmware layer to keep track
> > > of power_state parameter for every idle state so that the
> > > index->power_state conversion can be made in the PSCI firmware layer
> > > instead of the CPUidle driver implementations.
> > >
> > > Move the power_state handling out of drivers/firmware/psci
> > > into the respective ACPI/DT PSCI CPUidle backends and convert
> > > the psci_cpu_suspend_enter() API to get the power_state
> > > parameter as input, which makes it closer to its firmware
> > > interface PSCI.CPU_SUSPEND() API.
> > >
> > > A notable side effect is that the PSCI ACPI/DT CPUidle backends
> > > now can directly handle (and if needed update) power_state
> > > parameters before handing them over to the PSCI firmware
> > > interface to trigger PSCI.CPU_SUSPEND() calls.
> > >
> > > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > > Cc: Sudeep Holla <sudeep.holla@arm.com>
> >
> > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> > > +static __init int psci_cpu_init_idle(unsigned int cpu)
> > > +{
> > > + struct device_node *cpu_node;
> > > + int ret;
> > > +
> > > + /*
> > > + * If the PSCI cpu_suspend function hook has not been initialized
> > > + * idle states must not be enabled, so bail out
> > > + */
> > > + if (!psci_ops.cpu_suspend)
> > > + return -EOPNOTSUPP;
> > > +
> > > + cpu_node = of_get_cpu_node(cpu, NULL);
> >
> > [nit] You could use of_cpu_device_node_get in linux/of_device.h as
> > it may avoid parsing if used later during the boot(i.e. after
> > cpu->of_node is populated). I think there's another instance in
> > psci_idle_init_cpu
>
> Good idea!
>
> However, as $subject patch more or less just moves code from the
> current psci firmware directory into cpuidle, perhaps it's better to
> defer improvements to be made on top?
>
I am fine either way. But since cpuidle-psci.c is new file introduced
in this series, we can have it as part of the original patch. I leave it
to Lorenzo to decide :)
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox