Re: [PATCH] MIPS: Loongson64: Add Loongson-2K1000 reset support
On 04/14/2021 08:17 PM, Jiaxun Yang wrote: On Wed, Apr 14, 2021, at 9:26 AM, Qing Zhang wrote: Add power management register operations to support reboot and poweroff. Signed-off-by: Qing Zhang No that's not what we intended to do. Please add a devicetree node for pm block. Hi, jiaxun Thanks for your reply, I will do it and send v2 . -Qing
Re: [PATCH] MIPS: Loongson64: enable CONFIG_USB_SERIAL_PL2303
On 03/30/2021 09:48 AM, Jiaxun Yang wrote: On Mon, Mar 29, 2021, at 3:15 PM, Qing Zhang wrote: When using the Loongson-3A4000 machine for serial port debugging, there is no /dev/ttyUSB* output, which makes the serial port unavailable, For convenience, we open this configuration. zhangqing@loongson-pc:~$ cat /sys/firmware/lefi/boardinfo Board Info Manufacturer: THTF Board Name : THTF-LS3A4000-7A1000-ML4A Family : LOONGSON3 BIOS Info Vendor : ZD tech Version : ZD tech-V2.1.1 ROM Size: 4 KB Release Date: 2020-06-29 zhangqing@loongson-pc:~$ lsusb Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse Bus 005 Device 002: ID 0c45:760b Microdia USB Keyboard Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Signed-off-by: Qing Zhang Please, don't add random stuff to defconfig. Carry it locally in your config as the device doesn't come with the borad, it's your accessory. Hi, jiaxun Thank you for your reply:-)， PL2303 is a commonly used accessory, I see that other platforms are turned on by default, so I also enabled it. eg: arch/powerpc/configs/g5_defconfig:191:CONFIG_USB_SERIAL_PL2303=m arch/powerpc/configs/ppc6xx_defconfig:902:CONFIG_USB_SERIAL_PL2303=m arch/mips/configs/rm200_defconfig:310:CONFIG_USB_SERIAL_PL2303=m arch/mips/configs/loongson3_defconfig:323:CONFIG_USB_SERIAL_PL2303=m arch/mips/configs/mtx1_defconfig:559:CONFIG_USB_SERIAL_PL2303=m arch/mips/configs/pistachio_defconfig:240:CONFIG_USB_SERIAL_PL2303=m arch/mips/configs/loongson1c_defconfig:88:CONFIG_USB_SERIAL_PL2303=m arch/mips/configs/loongson1b_defconfig:87:CONFIG_USB_SERIAL_PL2303=m arch/arm/configs/spitz_defconfig:183:CONFIG_USB_SERIAL_PL2303=m arch/arm/configs/s3c2410_defconfig:323:CONFIG_USB_SERIAL_PL2303=y arch/arm/configs/omap2plus_defconfig:430:CONFIG_USB_SERIAL_PL2303=m arch/arm/configs/at91_dt_defconfig:166:CONFIG_USB_SERIAL_PL2303=y arch/arm/configs/s3c6400_defconfig:57:CONFIG_USB_SERIAL_PL2303=m arch/arm/configs/corgi_defconfig:189:CONFIG_USB_SERIAL_PL2303=m arch/arm/configs/sama5_defconfig:183:CONFIG_USB_SERIAL_PL2303=y arch/arm/configs/pxa_defconfig:572:CONFIG_USB_SERIAL_PL2303=m arch/arm/configs/ep93xx_defconfig:101:CONFIG_USB_SERIAL_PL2303=y arch/arm/configs/omap1_defconfig:185:CONFIG_USB_SERIAL_PL2303=y arch/arm/configs/badge4_defconfig:90:CONFIG_USB_SERIAL_PL2303=m arch/sh/configs/landisk_defconfig:91:CONFIG_USB_SERIAL_PL2303=m arch/sh/configs/titan_defconfig:218:CONFIG_USB_SERIAL_PL2303=m Thanks, Qing Thanks.
Re: [PATCH v5 0/7] Add basic support for Loongson-2K1000
ping On 03/15/2021 03:49 PM, Qing Zhang wrote: These patches support single-core DTS boot to the serial port login interface, which can be operated using conventional commands. I have successfully tested it on the Loongson 2K1000 machine. pmon: http://cgit.loongnix.org/cgit/pmon-loongson3/ Note: After the basic support is merged, I will commit SMP and other driver support in the future. Qing Zhang (7): MIPS: Loongson64: DeviceTree for Loongson-2K1000 MIPS: Loongson64: Distinguish firmware dependencies DTB/LEFI MIPS: Loongson64: Add support for the Loongson-2K1000 to get cpu_clock_freq MIPS: Loongson64: Add Loongson-2K1000 early_printk_port irqchip/loongson-liointc: irqchip add 2.0 version dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC MIPS: Loongson64: Add a Loongson-2K1000 default config file .../loongson,liointc.yaml | 36 +- arch/mips/boot/dts/loongson/Makefile | 1 + .../boot/dts/loongson/loongson64-2k1000.dtsi | 243 .../dts/loongson/loongson64_2core_2k1000.dts | 10 + arch/mips/configs/loongson2k_defconfig| 353 ++ .../asm/mach-loongson64/builtin_dtbs.h| 1 + .../include/asm/mach-loongson64/loongson.h| 9 +- arch/mips/loongson64/env.c| 13 +- arch/mips/loongson64/init.c | 21 +- arch/mips/loongson64/time.c | 24 ++ drivers/irqchip/irq-loongson-liointc.c| 58 ++- 11 files changed, 751 insertions(+), 18 deletions(-) create mode 100644 arch/mips/boot/dts/loongson/loongson64-2k1000.dtsi create mode 100644 arch/mips/boot/dts/loongson/loongson64_2core_2k1000.dts create mode 100644 arch/mips/configs/loongson2k_defconfig
Re: [PATCH v4 6/7] dt-bindings: interrupt-controller: Add Loongson-2K1000 LIOINTC
On 03/10/2021 08:04 PM, Jiaxun Yang wrote: On Wed, Mar 10, 2021, at 3:56 PM, Qing Zhang wrote: Add liointc-2.0 properties support, so update the maxItems and description. Signed-off-by: Jiaxun Yang ^ I have nothing todo with this patch so please drop me for this one :-) Signed-off-by: Qing Zhang Tested-by: Ming Wang --- v3-v4: Standard submission of information ^ It's called commit message. .../bindings/interrupt-controller/loongson,liointc.yaml| 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index f38e0113f360..5280cf60a9a7 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -10,9 +10,9 @@ maintainers: - Jiaxun Yang description: | - This interrupt controller is found in the Loongson-3 family of chips as the primary - package interrupt controller which can route local I/O interrupt to interrupt lines - of cores. + This interrupt controller is found in the Loongson-3 family of chips and + Loongson-2K1000 chip, as the primary package interrupt controller which + can route local I/O interrupt to interrupt lines of cores. allOf: - $ref: /schemas/interrupt-controller.yaml# @@ -22,6 +22,7 @@ properties: oneOf: - const: loongson,liointc-1.0 - const: loongson,liointc-1.0a + - const: loongson,liointc-2.0 reg: maxItems: 1 ^ Please document multiple reg prop change as well. Hi, Jiaxun Thank you for your reply, I will do it and send v5. Thanks, -Qing Thanks. - Jiaxun -- 2.20.1
Re: [PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
I really don't care about whatever arbitrary limit people think there is. Please put it on a single line. Hi,Marc Thank you for your reply, I saw it my $max_line_length = 100; So already fixed it in v4:). Thanks, Qing Thanks, M.
Re: [PATCH v4 3/7] MIPS: Loongson64: Add support for the Loongson-2K1000 to get cpu_clock_freq
On 03/10/2021 04:50 PM, Sergei Shtylyov wrote: Hello! You don't seem to need this initializer. Hi,Sergei Thanks for your suggestion, clk will not be affected by others when it is defined until the value is obtained, =NULL can be deleted, but I think it seems to have no effect. Thanks, Qing
Re: [PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
On 03/10/2021 04:47 PM, Sergei Shtylyov wrote: Hello! The new line length limit is 100 chars. :-) Hi,Sergei Thank you for your reply, I saw it my $max_line_length = 100; Soalready fixed it in v4:). Thanks, Qing MBR, Sergei
Re: [PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
On 03/09/2021 05:10 PM, Marc Zyngier wrote:
+
+static void __iomem *liointc_get_reg_byname(struct device_node *node,
+ const char *name)
+{
+ int index = of_property_match_string(node, "reg-names", name);
+
+ return of_iomap(node, index);
So if of_property_match_string() returns an error, you feed that error
to of_iomap()? Somehow, I don't think that's a good idea.
Hi, Marc
Thank you for your suggestion, error handling is missing here,
+if (index <0)
+ return NULL;
return of_iomap(node, index);
It has been fixed in the fourth version, and I will send V4 soon.
+ if (of_device_is_compatible(node, "loongson,liointc-2.0")) {
+ base = liointc_get_reg_byname(node, "main");
+ if (!base) {
+ err = -ENODEV;
+ goto out_free_priv;
+ }
+ for (i = 0; i < LIOINTC_NUM_CORES; i++) {
+ priv->core_isr[i] =
+ liointc_get_reg_byname(node, core_reg_names[i]);
Please write assignments on a single line.
In addition, write assignments on a single line
for (i = 0; i priv->core_isr[i] =
liointc_get_reg_byname(node, core_reg_names[i]);
It is 92 characters, more than 80 characters...
Thanks
-Qing
Thanks,
M.
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
On 03/06/2021 04:03 PM, Thomas Bogendoerfer wrote: as you are already touching mach-loongson64 files... Is there a chance you clean up that up even further ? My goal is to have only files in mach- files, which have an mach-generic counterpart. Everything else should go to its own directory. So in case of loongson something like arch/mips/include/asm/loongson for common stuff arch/mips/include/asm/loongson/32 arch/mips/include/asm/loongson/64 Comments ? Hi,Thomas I am very interested in cleaning up. Can you merge these two patches first? Submitting the remaining patches after other clean-up work is completed, it seems that the impact will not be significant. Thanks Qing Thomas.
Re: [PATCH v3 5/7] irqchip/loongson-liointc: irqchip add 2.0 version
On 03/06/2021 11:06 AM, Huacai Chen wrote: Hi, Qing, On Sat, Mar 6, 2021 at 10:36 AM Qing Zhang wrote: Add IO interrupt controller support for Loongson 2k1000, different from the 3a series is that 2K1000 has 64 interrupt sources, 0-31 correspond to the device tree liointc0 device node, and the other correspond to liointc1 node. Use the formal name (Loongson-2K1000, Loongson-3A series), please. Hi, Huacai Thank you very much for your reply. I will modify the submission information, Use the formal name (Loongson-2K1000, Loongson-3A series) in v4, Before that, I will wait for other people's opinions about this series. Thanks, Qing Huacai
Re: [PATCH 1/2] MIPS: Loongson64: Remove unused sysconf members
On 03/05/2021 10:32 AM, Jiaxun Yang wrote: 在 2021/3/4 下午7:00, Qing Zhang 写道: We don't need them anymore, They are uniform on all Loongson64 systems and have been fixed in DeviceTree.loongson3_platform_init is replaced with DTS + driver. Signed-off-by: Jiaxun Yang Signed-off-by: Qing Zhang Acked-by: Jiaxun Yang Hmm, why it comes with my sign-off? I assue it's my patch somewhere off the tree? Hi, Jiaxun Thank you very much for your reply. Yes, it is like this.out of tree provides good ideas, and clean up others by the way. Thanks, Qing Thanks. - Jiaxun
Re: [PATCH 2/2] MIPS: Loongson64: Move loongson_system_configuration to loongson.h
On 03/05/2021 06:01 PM, Philippe Mathieu-Daudé wrote: Hi, On Thu, Mar 4, 2021 at 5:35 PM Qing Zhang wrote: The purpose of separating loongson_system_configuration from boot_param.h is to keep the other structure consistent with the firmware. This is supposed to be a trivial patch, but the description actually confuses me. Why is the move out of "boot_param.h" keeping it consistent with fw? Hi, PhilippeMathieu-Daudé Thank you for your reply. The boot_param.h file must be consistent in the kernel and the firmware pmon/cmds/bootparam.h In env.c, the loongson_system_configuration structure member gets the value passed to the firmware. eg: struct boot_params *boot_p; loongson_sysconf.restart_addr = boot_p->reset_system.ResetWarm; loongson_sysconf.poweroff_addr = boot_p->reset_system.Shutdown; loongson_sysconf.suspend_addr = boot_p->reset_system.DoSuspend; The boot_params structure is consistent with the firmware, The loongson_system_configuration is filled in the kernel, and there is no such structure in pmon-loongson3, it is actually defined in the kernel. So, remove its definition from boot_param.h. Thanks, Qing
Re: [PATCH v5 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
Hi, Huacai
On 12/28/2020 08:32 AM, Huacai Chen wrote:
Hi, Qing,
On Sat, Dec 26, 2020 at 5:13 PM Qing Zhang wrote:
The SPI controller has the following characteristics:
- Full-duplex synchronous serial data transmission
- Support up to 4 variable length byte transmission
- Main mode support
- Mode failure generates an error flag and issues an interrupt request
- Double buffer receiver
- Serial clock with programmable polarity and phase
- SPI can be controlled in wait mode
- Support boot from SPI
Use mtd_debug tool to earse/write/read /dev/mtd0 on development.
eg:
[root@linux mtd-utils-1.0.0]# mtd_debug erase /dev/mtd0 0x2 0x4
Erased 262144 bytes from address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug write /dev/mtd0 0x2 13 1.img
Copied 13 bytes from 1.img to address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug read /dev/mtd0 0x2 13 2.img
Copied 13 bytes from address 0x0002 in flash to 2.img
[root@linux mtd-utils-1.0.0]# cmp -l 1.img 2.img
Signed-off-by: Qing Zhang
---
v2:
- keep Kconfig and Makefile sorted
- make the entire comment a C++ one so things look more intentional
- Fix unclear indentation
- make conditional statements to improve legibility
- Don't use static inline
- the core handle message queue
- Add a new binding document
- Fix probe part mixed pdev and PCI
v3:
- expose set_cs to the core and let it handle things
- replace transfer_one_message to transfer_one
- replace spi_alloc_master to devm_spi_alloc_master
- split out into prepare/unprepare_message
- releases pci regions before unregister master
v4:
- names used in the manual
- rename ls7a_spi_do_transfer to ls7a_spi_setup_transfer
- change read the spcr and sper outside of this function
- mode configuration moved to prepare instead
- remove redundancy code about unprepare/prepare_message
- used 0x4 instead of 0x1,WFEMPTY instead of RFEMPTY
v5:
- remove unnecessary blank lines
---
drivers/spi/Kconfig| 7 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-ls7a.c | 280 +
3 files changed, 288 insertions(+)
create mode 100644 drivers/spi/spi-ls7a.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aadaea0..af7c0d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -413,6 +413,13 @@ config SPI_LP8841_RTC
Say N here unless you plan to run the kernel on an ICP DAS
LP-8x4x industrial computer.
+config SPI_LS7A
+ tristate "Loongson LS7A SPI Controller Support"
+ depends on CPU_LOONGSON64 || COMPILE_TEST
+ help
+ This drivers supports the Loongson LS7A SPI controller in master
+ SPI mode.
+
config SPI_MPC52xx
tristate "Freescale MPC52xx SPI (non-PSC) controller support"
depends on PPC_MPC52xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6fea582..d015cf2 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
+obj-$(CONFIG_SPI_LS7A) += spi-ls7a.o
obj-$(CONFIG_SPI_MESON_SPICC) += spi-meson-spicc.o
obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
diff --git a/drivers/spi/spi-ls7a.c b/drivers/spi/spi-ls7a.c
new file mode 100644
index 000..d24b6d91
--- /dev/null
+++ b/drivers/spi/spi-ls7a.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Loongson LS7A SPI Controller driver
+//
+// Copyright (C) 2020 Loongson Technology Corporation Limited.
+//
+
+#include
+#include
+#include
+
+/* define spi register */
+#defineSPCR0x00
+#defineSPSR0x01
+#defineFIFO0x02
+#defineSPER0x03
+#defineSFC_PARAM 0x04
+#defineSFC_SOFTCS 0x05
+#defineSFC_TIMING 0x06
+
+struct ls7a_spi {
+ struct spi_master *master;
+ void __iomem *base;
+ unsigned int hz;
+ unsigned int mode;
+};
+
+static void ls7a_spi_write_reg(struct ls7a_spi *spi,
+ unsigned char reg,
+ unsigned char data)
+{
+ writeb(data, spi->base + reg);
+}
+
+static char ls7a_spi_read_reg(struct ls7a_spi *spi, unsigned char reg)
+{
+ return readb(spi->base + reg);
+}
+
+static int ls7a_spi_prepare_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct ls7a_spi *ls7a_spi;
+ struct spi_device *spi = msg->spi;
+ unsigned char val;
+
+ ls7a_spi = spi_master_get_devdata(master);
+
+ if (ls7a_spi->mode != spi->mode) {
+ val = ls7a_spi_read_reg(ls7a_spi, SPCR);
+ val &= ~0xc;
+
Re: [PATCH v4 2/4] spi: ls7a: Add YAML schemas
Hi，Sergei
Thank you for your reply and suggestion .
I will use extra indentation levels and send v5 in the soon.
Thanks,
-Qing
On 12/25/2020 08:19 PM, Sergei Shtylyov wrote:
On 12/25/20 1:35 PM, Qing Zhang wrote:
Switch the DT binding to a YAML schema to enable the DT validation.
Signed-off-by: Qing Zhang
---
v4: fix warnings/errors about running 'make dt_binding_check'
---
.../devicetree/bindings/spi/loongson,spi-ls7a.yaml | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
diff --git a/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
new file mode 100644
index 000..8cc9bc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/loongson,spi-ls7a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A PCH SPI Controller
+
+maintainers:
+ - Qing Zhang
+
+description: |
+ This controller can be found in Loongson-3 systems with LS7A PCH.
+
+properties:
+ compatible:
+const: loongson,ls7a-spi
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - num-chipselects
+
+additionalProperties: false
+
+examples:
+ - |
+pci {
+#address-cells = <3>;
+#size-cells = <2>;
+
+spi@16,0 {
+compatible = "pci0014,7a0b.0",
+"pci0014,7a0b",
+"pciclass088000",
+"pciclass0800";
+
+reg = <0xb000 0x0 0x0 0x0 0x0>;
+num-chipselects = <0>;
The above lines after { need extra indentation level.
+};
+};
+
+...
MBR, Sergei
Re: [PATCH v4 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
Hi，Huacai
Thank you for your reply and suggestion .
I will remove blank lines and send v5 in the soon.
Thanks,
-Qing
On 12/26/2020 12:28 PM, Huacai Chen wrote:
Hi, Qing
On Fri, Dec 25, 2020 at 6:40 PM Qing Zhang wrote:
The SPI controller has the following characteristics:
- Full-duplex synchronous serial data transmission
- Support up to 4 variable length byte transmission
- Main mode support
- Mode failure generates an error flag and issues an interrupt request
- Double buffer receiver
- Serial clock with programmable polarity and phase
- SPI can be controlled in wait mode
- Support boot from SPI
Use mtd_debug tool to earse/write/read /dev/mtd0 on development.
eg:
[root@linux mtd-utils-1.0.0]# mtd_debug erase /dev/mtd0 0x2 0x4
Erased 262144 bytes from address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug write /dev/mtd0 0x2 13 1.img
Copied 13 bytes from 1.img to address 0x0002 in flash
[root@linux mtd-utils-1.0.0]# mtd_debug read /dev/mtd0 0x2 13 2.img
Copied 13 bytes from address 0x0002 in flash to 2.img
[root@linux mtd-utils-1.0.0]# cmp -l 1.img 2.img
Signed-off-by: Qing Zhang
---
v2:
- keep Kconfig and Makefile sorted
- make the entire comment a C++ one so things look more intentional
- Fix unclear indentation
- make conditional statements to improve legibility
- Don't use static inline
- the core handle message queue
- Add a new binding document
- Fix probe part mixed pdev and PCI
v3:
- expose set_cs to the core and let it handle things
- replace transfer_one_message to transfer_one
- replace spi_alloc_master to devm_spi_alloc_master
- split out into prepare/unprepare_message
- releases pci regions before unregister master
v4:
- names used in the manual
- rename ls7a_spi_do_transfer to ls7a_spi_setup_transfer
- change read the spcr and sper outside of this function
- mode configuration moved to prepare instead
- remove redundancy code about unprepare/prepare_message
- used 0x4 instead of 0x1,WFEMPTY instead of RFEMPTY
---
drivers/spi/Kconfig| 7 ++
drivers/spi/Makefile | 1 +
drivers/spi/spi-ls7a.c | 283 +
3 files changed, 291 insertions(+)
create mode 100644 drivers/spi/spi-ls7a.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index aadaea0..af7c0d4 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -413,6 +413,13 @@ config SPI_LP8841_RTC
Say N here unless you plan to run the kernel on an ICP DAS
LP-8x4x industrial computer.
+config SPI_LS7A
+ tristate "Loongson LS7A SPI Controller Support"
+ depends on CPU_LOONGSON64 || COMPILE_TEST
+ help
+ This drivers supports the Loongson LS7A SPI controller in master
+ SPI mode.
+
config SPI_MPC52xx
tristate "Freescale MPC52xx SPI (non-PSC) controller support"
depends on PPC_MPC52xx
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6fea582..d015cf2 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_SPI_LANTIQ_SSC) += spi-lantiq-ssc.o
obj-$(CONFIG_SPI_JCORE)+= spi-jcore.o
obj-$(CONFIG_SPI_LM70_LLP) += spi-lm70llp.o
obj-$(CONFIG_SPI_LP8841_RTC) += spi-lp8841-rtc.o
+obj-$(CONFIG_SPI_LS7A) += spi-ls7a.o
obj-$(CONFIG_SPI_MESON_SPICC) += spi-meson-spicc.o
obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
obj-$(CONFIG_SPI_MPC512x_PSC) += spi-mpc512x-psc.o
diff --git a/drivers/spi/spi-ls7a.c b/drivers/spi/spi-ls7a.c
new file mode 100644
index 000..d2be370
--- /dev/null
+++ b/drivers/spi/spi-ls7a.c
@@ -0,0 +1,283 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Loongson LS7A SPI Controller driver
+//
+// Copyright (C) 2020 Loongson Technology Corporation Limited.
+//
+
+#include
+#include
+#include
+
+/* define spi register */
+#defineSPCR0x00
+#defineSPSR0x01
+#defineFIFO0x02
+#defineSPER0x03
+#defineSFC_PARAM 0x04
+#defineSFC_SOFTCS 0x05
+#defineSFC_TIMING 0x06
+
+struct ls7a_spi {
+ struct spi_master *master;
+ void __iomem *base;
+ unsigned int hz;
+ unsigned int mode;
+};
+
+static void ls7a_spi_write_reg(struct ls7a_spi *spi,
+ unsigned char reg,
+ unsigned char data)
+{
+ writeb(data, spi->base + reg);
+}
+
+static char ls7a_spi_read_reg(struct ls7a_spi *spi, unsigned char reg)
+{
+ return readb(spi->base + reg);
+}
+
+static int ls7a_spi_prepare_message(struct spi_master *master,
+ struct spi_message *msg)
+{
+ struct ls7a_spi *ls7a_spi;
+ struct spi_device *spi = msg->spi;
+ unsigned char val;
+
+ ls7a_spi = spi_master_get_devdata(master);
+
+ if (ls7a_spi->mode != spi->mode) {
+ val
Re: [PATCH v4 2/4] spi: ls7a: Add YAML schemas
Hi，Jiaxun
Thank you for your reply.
I will also delete the num chipelects attribute in the device tree.
And I will send v5 in the soon.
Thanks,
-Qing
On 12/26/2020 11:31 AM, Jiaxun Yang wrote:
在 2020/12/25 下午6:35, Qing Zhang 写道:
Switch the DT binding to a YAML schema to enable the DT validation.
Signed-off-by: Qing Zhang
---
v4: fix warnings/errors about running 'make dt_binding_check'
---
.../devicetree/bindings/spi/loongson,spi-ls7a.yaml | 46
++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
diff --git
a/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
new file mode 100644
index 000..8cc9bc5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/loongson,spi-ls7a.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/loongson,spi-ls7a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson LS7A PCH SPI Controller
+
+maintainers:
+ - Qing Zhang
+
+description: |
+ This controller can be found in Loongson-3 systems with LS7A PCH.
+
+properties:
+ compatible:
+const: loongson,ls7a-spi
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - num-chipselects
num-chipselects never parsed in code?
Thanks.
- Jiaxun
+
+additionalProperties: false
+
+examples:
+ - |
+pci {
+#address-cells = <3>;
+#size-cells = <2>;
+
+spi@16,0 {
+compatible = "pci0014,7a0b.0",
+"pci0014,7a0b",
+"pciclass088000",
+"pciclass0800";
+
+reg = <0xb000 0x0 0x0 0x0 0x0>;
+num-chipselects = <0>;
+};
+};
+
+...
Re: [PATCH v2 1/4] spi: LS7A: Add Loongson LS7A SPI controller driver support
Hi Brown,
Thank you for your suggestions, these are achievable, I will send v3 in
the soon.
Before sending v3, I would like to trouble you to see if this is
correct. It has been tested locally.
On 12/08/2020 09:56 PM, Mark Brown wrote:
On Tue, Dec 08, 2020 at 03:44:24PM +0800, Qing Zhang wrote:
v2:
- keep Kconfig and Makefile sorted
- make the entire comment a C++ one so things look more intentional
You say this but...
+++ b/drivers/spi/spi-ls7a.c
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Loongson LS7A SPI Controller driver
+ *
+ * Copyright (C) 2020 Loongson Technology Corporation Limited
+ */
...this is still a mix of C and C++ comments?
Replace all with //
+static int set_cs(struct ls7a_spi *ls7a_spi, struct spi_device *spi, int val)
+{
+ int cs = ls7a_spi_read_reg(ls7a_spi, SFCS) & ~(0x11 <<
spi->chip_select);
+
+ if (spi->mode & SPI_CS_HIGH)
+ val = !val;
+ ls7a_spi_write_reg(ls7a_spi, SFCS,
+ (val ? (0x11 << spi->chip_select):(0x1 << spi->chip_select)) |
cs);
+
+ return 0;
+}
Why not just expose this to the core and let it handle things?
Please also write normal conditional statements to improve legibility.
There's quite a lot of coding style issues in this with things like
missing spaces
static void ls7a_spi_set_cs(struct spi_device *spi, bool enable)
{
struct ls7a_spi *ls7a_spi;
int cs = ls7a_spi_read_reg(ls7a_spi, SFCS) & ~(0x11 <<
spi->chip_select));
ls7a_spi = spi_master_get_devdata(spi->master);
if (!!(spi->mode & SPI_CS_HIGH) == enable)
val = (0x11 << spi->chip_select) | cs;
else
val = (0x1 << spi->chip_select) | cs;
ls7a_spi_write_reg(ls7a_spi, SFCS, val);
}
static int ls7a_spi_pci_probe>
+master->set_cs = ls7a_spi_set_cs;
+ if (t) {
+ hz = t->speed_hz;
+ if (!hz)
+ hz = spi->max_speed_hz;
+ } else
+ hz = spi->max_speed_hz;
If one branch of the conditional has braces please use them on both to
improve legibility.
+static int ls7a_spi_transfer_one_message(struct spi_master *master,
+ struct spi_message *m)
I don't understand why the driver is implementing transfer_one_message()
- it looks like this is just open coding the standard loop that the
framework provides and should just be using transfer_one().
static int ls7a_spi_transfer_one(struct spi_master *master,
struct spi_device *spi,
struct spi_transfer *t)
{
struct ls7a_spi *ls7a_spi;
int param, status;
ls7a_spi = spi_master_get_devdata(master);
spin_lock(&ls7a_spi->lock);
param = ls7a_spi_read_reg(ls7a_spi, PARA);
ls7a_spi_write_reg(ls7a_spi, PARA, param&~1);
spin_unlock(&ls7a_spi->lock);
status = ls7a_spi_do_transfer(ls7a_spi, spi, t);
if(status < 0)
return status;
if(t->len)
r = ls7a_spi_write_read(spi, t);
spin_lock(&ls7a_spi->lock);
ls7a_spi_write_reg(ls7a_spi, PARA, param);
spin_unlock(&ls7a_spi->lock);
return status;
}
static int ls7a_spi_pci_probe>
- master->transfer_one_message = ls7a_spi_transfer_one_message;
+master->transfer_one = ls7a_spi_transfer_one;
+ r = ls7a_spi_write_read(spi, t);
+ if (r < 0) {
+ status = r;
+ goto error;
+ }
The indentation here isn't following the kernel coding style.
+ master = spi_alloc_master(&pdev->dev, sizeof(struct ls7a_spi));
+ if (!master)
+ return -ENOMEM;
Why not use devm_ here?
- master = spi_alloc_master(&pdev->dev, sizeof(struct ls7a_spi));
error:
- spi_put_master(master);
+ master = devm_spi_alloc_master(&pdev->dev, sizeof(struct ls7a_spi));
+ ret = devm_spi_register_master(dev, master);
+ if (ret)
+ goto err_free_master;
The driver uses devm_spi_register_master() here but...
+static void ls7a_spi_pci_remove(struct pci_dev *pdev)
+{
+ struct spi_master *master = pci_get_drvdata(pdev);
+ struct ls7a_spi *spi;
+
+ spi = spi_master_get_devdata(master);
+ if (!spi)
+ return;
+
+ pci_release_regions(pdev);
...releases the PCI regions in the remove() function before the SPI
controller is freed so the controller could still be active.
static void ls7a_spi_pci_remove(struct pci_dev *pdev)
{
struct spi_master *master = pci_get_drvdata(pdev);
+ spi_unregister_master(master);
pci_release_regions(pdev);
}
Thanks,
-Qing
Re: [PATCH v2 2/4] spi: Add devicetree bindings documentation for Loongson SPI
On 12/08/2020 09:58 PM, Mark Brown wrote: On Tue, Dec 08, 2020 at 06:47:10PM +0800, zhangqing wrote: On 12/08/2020 04:40 PM, Sergei Shtylyov wrote: +Required properties: +- #interrupts: No hardware interrupt. You say it's a required prop, yet yuoe example doesn't have it... I want to emphasize here that LS7A SPI has no hardware interrupts, and DT is not actually used. There is no need to do this, and documenting the property as required just makes things confusing here. Thanks for your suggestion, I will remove the #interrupt attribute in the third edition. Thanks, -Qing
Re: [PATCH v2 2/4] spi: Add devicetree bindings documentation for Loongson SPI
On 12/08/2020 10:48 PM, Sergei Shtylyov wrote:
On 12/8/20 1:47 PM, zhangqing wrote:
Add spi-ls7a binding documentation.
Signed-off-by: Qing Zhang
---
Documentation/devicetree/bindings/spi/spi-ls7a.txt | 31
++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-ls7a.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-ls7a.txt
b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
new file mode 100644
index 000..56247b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
@@ -0,0 +1,31 @@
+Binding for LOONGSON LS7A SPI controller
+
+Required properties:
+- compatible: should be
"pci0014,7a0b.0","pci0014,7a0b","pciclass088000","pciclass0880".
+- reg: reference IEEE Std 1275-1994.
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+- #interrupts: No hardware interrupt.
You say it's a required prop, yet yuoe example doesn't have it...
I want to emphasize here that LS7A SPI has no hardware interrupts, and
DT is not actually used.
The why document the property at all?
Thank you for your reply again,
I will remove the #interrupt attribute in the third edition.
+
+Child nodes as per the generic SPI binding.
+
+Example:
+
+spi@16,0 {
+compatible = "pci0014,7a0b.0",
+"pci0014,7a0b",
+"pciclass088000",
+"pciclass0880";
+
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0xb000 0x0 0x0 0x0 0x0>;
+num-chipselects = <0>;
+spiflash: s25fl016k@0 {
+#address-cells = <1>;
+#size-cells = <1>;
Once more?
+compatible ="spansion,s25fl016k","jedec,spi-nor";
Once more?
+ spi-max-frequency=<5000>;
+reg=<0>;
Once more? Did you mean this for a child node?
Yes, these are child node attributes, the child node splash is not
necessary.
You should indent the child nodes with 1 more tab...
I will do it and send the v3 in the soon.
+};
+};
Thanks
-Qing
MBR, Sergei
Re: [PATCH v2 2/4] spi: Add devicetree bindings documentation for Loongson SPI
Hi Sergei Shtylyov,
On 12/08/2020 04:40 PM, Sergei Shtylyov wrote:
Hello!
On 08.12.2020 10:44, Qing Zhang wrote:
Add spi-ls7a binding documentation.
Signed-off-by: Qing Zhang
---
Documentation/devicetree/bindings/spi/spi-ls7a.txt | 31
++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-ls7a.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-ls7a.txt
b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
new file mode 100644
index 000..56247b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-ls7a.txt
@@ -0,0 +1,31 @@
+Binding for LOONGSON LS7A SPI controller
+
+Required properties:
+- compatible: should be
"pci0014,7a0b.0","pci0014,7a0b","pciclass088000","pciclass0880".
+- reg: reference IEEE Std 1275-1994.
+- #address-cells: <1>, as required by generic SPI binding.
+- #size-cells: <0>, also as required by generic SPI binding.
+- #interrupts: No hardware interrupt.
You say it's a required prop, yet yuoe example doesn't have it...
I want to emphasize here that LS7A SPI has no hardware
interrupts, and DT is not actually used.
+
+Child nodes as per the generic SPI binding.
+
+Example:
+
+spi@16,0 {
+compatible = "pci0014,7a0b.0",
+"pci0014,7a0b",
+"pciclass088000",
+"pciclass0880";
+
+#address-cells = <1>;
+#size-cells = <0>;
+reg = <0xb000 0x0 0x0 0x0 0x0>;
+num-chipselects = <0>;
+spiflash: s25fl016k@0 {
+#address-cells = <1>;
+#size-cells = <1>;
Once more?
+compatible ="spansion,s25fl016k","jedec,spi-nor";
Once more?
+ spi-max-frequency=<5000>;
+reg=<0>;
Once more? Did you mean this for a child node?
Yes, these are child node attributes, the child node splash is
not necessary.
+};
+};
Thanks
-Qing
MBR, Sergei
Re: [PATCH 1/3] spi: Loongson: Add Loongson 3A+7A SPI controller driver support
Hi Mark,
Thank you for your suggestion, I will do it and send the v2 in the future.
Thanks,
Qing
On 11/23/2020 09:10 PM, Mark Brown wrote:
On Mon, Nov 23, 2020 at 05:19:06PM +0800, Qing Zhang wrote:
This module is integrated into the Loongson-3A SoC and the LS7A bridge chip.
It looks like this needs quite a bit of update to fit into the SPI
subsystem properly, fortunately most of that is cutting code out of the
driver so you can use core features so it shouldn't be too bad. There's
also a bunch of pretty minor stylistic issues none of which look too
difficult to address.
@@ -968,6 +968,12 @@ config SPI_AMD
help
Enables SPI controller driver for AMD SoC.
+config SPI_LOONGSON
+tristate "Loongson SPI Controller Support"
Please keep Kconfig and Makefile sorted.
+depends on CPU_LOONGSON32 || CPU_LOONGSON64
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Loongson3A+7A SPI driver
+ *
Please make the entire comment a C++ one so things look more
intentional.
+#include
+#include
+/*define spi register */
+#defineSPCR0x00
Missing blank line.
+#defineSPSR0x01
+#define FIFO 0x02
This indentation is unclear, also all these defines could use some
namespacing to avoid collisions with anything that gets defined in a
header.
+ hz = t ? t->speed_hz : spi->max_speed_hz;
+
+ if (!hz)
+ hz = spi->max_speed_hz;
Please write normal conditional statements to improve legibility, and
note that the core will ensure that the transfer always has a speed set.
+ if ((hz && loongson_spi->hz != hz) || ((spi->mode ^ loongson_spi->mode)
& (SPI_CPOL | SPI_CPHA))) {
Please try to keep your lines less than 80 columns (there's not a hard
limit here but it helps legibility).
+ bit = fls(div) - 1;
+ if ((1<
1 << bit
+static int loongson_spi_setup(struct spi_device *spi)
+{
+ struct loongson_spi *loongson_spi;
+
+ loongson_spi = spi_master_get_devdata(spi->master);
+ if (spi->bits_per_word % 8)
+ return -EINVAL;
+
+ if (spi->chip_select >= spi->master->num_chipselect)
+ return -EINVAL;
+
+ loongson_spi_update_state(loongson_spi, spi, NULL);
+ set_cs(loongson_spi, spi, 1);
The setup() operation shouldn't configure the physical controller state
unless there are separate configuration registers per chip select -
another device could be active when setup() is called.
+static int loongson_spi_write_read_8bit(struct spi_device *spi,
+ const u8 **tx_buf, u8 **rx_buf, unsigned int num)
+{
+ struct loongson_spi *loongson_spi;
+ loongson_spi = spi_master_get_devdata(spi->master);
+
+ if (tx_buf && *tx_buf) {
+ loongson_spi_write_reg(loongson_spi, FIFO, *((*tx_buf)++));
+ while ((loongson_spi_read_reg(loongson_spi, SPSR) & 0x1) == 1);
+} else {
+ loongson_spi_write_reg(loongson_spi, FIFO, 0);
+ while ((loongson_spi_read_reg(loongson_spi, SPSR) & 0x1) == 1);
+}
The indentation is messed up here, looks like you have some kind of
tab/space confusion.
+ count = xfer->len;
+
+ do {
+ if (loongson_spi_write_read_8bit(spi, &tx, &rx, count) < 0)
+ goto out;
This is the only caller of _write_read_8bit(), may sa well inline it?
+static inline int set_cs(struct loongson_spi *loongson_spi, struct spi_device
*spi, int val)
Why is this static inline? This should be an operation provided to the
SPI core.
+{
+ int cs = loongson_spi_read_reg(loongson_spi, SFCS) & ~(0x11 <<
spi->chip_select);
+
+if (spi->mode & SPI_CS_HIGH)
+ val = !val;
+ loongson_spi_write_reg(loongson_spi, SFCS,
+(val ? (0x11 << spi->chip_select):(0x1 <<
spi->chip_select)) | cs);
There's mult
+static void loongson_spi_work(struct work_struct *work)
+{
Drivers shouldn't be open coding a message queue, implement
transfer_one_message() and let the core handle it for you.
+static const struct of_device_id loongson_spi_id_table[] = {
+ { .compatible = "loongson,loongson-spi", },
+ { },
+};
This is introducing a new DT binding, there should also be a new binding
document added.
+static int loongson_spi_pci_register(struct pci_dev *pdev,
+ const struct pci_device_id *ent)
+{
+ int ret;
+ unsigned char v8;
I would expect the PCI device to be a separate module with a dependency
on PCI, I'm kind of surprised that this builds on !PCI systems but I
guess it's possible there's stubs.
Re: [PATCH v2 2/2] spi: coldfire-qspi: Use clk_prepare_enable and clk_disable_unprepare
On 07/15/2020 05:49 PM, Mark Brown wrote:
On Wed, Jul 15, 2020 at 01:26:47PM +0800, Qing Zhang wrote:
Convert clk_enable() to clk_prepare_enable() and clk_disable() to
clk_disable_unprepare() respectively in the spi-coldfire-qspi.c.
Like I said on the previous version are you sure that ColdFire uses the
common clock framework and has the prepare calls?
Hi Mark,
Thanks for your reminder again.
I see the following comment and code in arch/m68k/coldfire/clk.c:
For more advanced ColdFire parts that have clocks that can be enabled
we supply enable/disable functions. These must properly define their
clocks in their platform specific code.
int clk_enable(struct clk *clk)
{
unsigned long flags;
spin_lock_irqsave(&clk_lock, flags);
if ((clk->enabled++ == 0) && clk->clk_ops)
clk->clk_ops->enable(clk);
spin_unlock_irqrestore(&clk_lock, flags);
return 0;
}
EXPORT_SYMBOL(clk_enable);
void clk_disable(struct clk *clk)
{
unsigned long flags;
if (!clk)
return;
spin_lock_irqsave(&clk_lock, flags);
if ((--clk->enabled == 0) && clk->clk_ops)
clk->clk_ops->disable(clk);
spin_unlock_irqrestore(&clk_lock, flags);
}
EXPORT_SYMBOL(clk_disable);
Thanks,
Qing
Re: [PATCH 2/2] spi: tools: Fix build errors
On 06/11/2020 04:02 PM, Geert Uytterhoeven wrote:
Hi Qing,
Thanks for your patch!
On Thu, Jun 11, 2020 at 5:43 AM Qing Zhang wrote:
Fix the following build errors:
include/linux/spi 2>&1 || true
ln -sf /home/zhangqing/spi.git2/tools/spi/../../include/uapi/linux/spi/spidev.h
include/linux/spi/spidev.h
make -f /home/zhangqing/spi.git2/tools/build/Makefile.build dir=.
obj=spidev_test
make[1]: Entering directory '/home/zhangqing/spi.git2/tools/spi'
CC spidev_test.o
spidev_test.c: In function ‘transfer’:
spidev_test.c:131:13: error: ‘SPI_TX_OCTAL’ undeclared (first use in this
function)
if (mode & SPI_TX_OCTAL)
^
spidev_test.c:131:13: note: each undeclared identifier is reported only once
for each function it appears in
spidev_test.c:137:13: error: ‘SPI_RX_OCTAL’ undeclared (first use in this
function)
if (mode & SPI_RX_OCTAL)
^
spidev_test.c: In function ‘parse_opts’:
spidev_test.c:290:12: error: ‘SPI_TX_OCTAL’ undeclared (first use in this
function)
mode |= SPI_TX_OCTAL;
^
spidev_test.c:308:12: error: ‘SPI_RX_OCTAL’ undeclared (first use in this
function)
mode |= SPI_RX_OCTAL;
^
LD spidev_test-in.o
ld: cannot find spidev_test.o: No such file or directory
/home/zhangqing/spi.git2/tools/build/Makefile.build:144: recipe for target
'spidev_test-in.o' failed
make[1]: *** [spidev_test-in.o] Error 1
make[1]: Leaving directory '/home/zhangqing/spi.git2/tools/spi'
Makefile:39: recipe for target 'spidev_test-in.o' failed
make: *** [spidev_test-in.o] Error 2
Signed-off-by: Qing Zhang
Oops, somehow I forgot I had made a similar change on the target
when adding Octal mode support to spidev_test.c.
Sorry for that.
Fixes: 896fa735084e4a91 ("spi: spidev_test: Add support for Octal mode
data transfers")
Reviewed-by: Geert Uytterhoeven
--- a/include/uapi/linux/spi/spidev.h
+++ b/include/uapi/linux/spi/spidev.h
@@ -48,6 +48,8 @@
#define SPI_TX_QUAD0x200
#define SPI_RX_DUAL0x400
#define SPI_RX_QUAD0x800
+#defineSPI_TX_OCTAL0x2000
+#defineSPI_RX_OCTAL0x4000
Probably we should add SPI_CS_WORD and SPI_3WIRE_HIZ, too?
Hi Geert,
Thanks for your reply and suggestion.
Maybe SPI_CS_WORD and SPI_3WIRE_HIZ will be used in the future.
I will do it and then send v2.
Thanks,
Qing
Gr{oetje,eeting}s,
Geert
[RESEND PATCH] rtc: rk808: rename rtc-rk808.c to rtc-rk8xx.c
make rtc-rk8xx.c compatible for all pmic chips.
for pmic chips(rk808\rk807\rk816\rk818) in the future.
Signed-off-by: zhangqing
---
drivers/mfd/rk808.c | 2 +-
drivers/rtc/Kconfig | 8 +-
drivers/rtc/Makefile | 2 +-
drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} | 218 ++-
4 files changed, 131 insertions(+), 99 deletions(-)
rename drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} (64%)
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 4b1e439..21da22b 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -77,7 +77,7 @@ static const struct mfd_cell rk808s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
{
- .name = "rk808-rtc",
+ .name = "rk8xx-rtc",
.num_resources = ARRAY_SIZE(rtc_resources),
.resources = &rtc_resources[0],
},
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 376322f..d669473d 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -325,15 +325,15 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
-config RTC_DRV_RK808
- tristate "Rockchip RK808 RTC"
+config RTC_DRV_RK8XX
+ tristate "Rockchip RK8XX RTC"
depends on MFD_RK808
help
If you say yes here you will get support for the
- RTC of RK808 PMIC.
+ RTC of RK8XX PMIC.
This driver can also be built as a module. If so, the module
- will be called rk808-rtc.
+ will be called rk8xx-rtc.
config RTC_DRV_MAX77802
tristate "Maxim 77802 RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 62d61b2..5b1384a 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -120,7 +120,7 @@ obj-$(CONFIG_RTC_DRV_PUV3) += rtc-puv3.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
-obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
+obj-$(CONFIG_RTC_DRV_RK8XX)+= rtc-rk8xx.o
obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk8xx.c
similarity index 64%
rename from drivers/rtc/rtc-rk808.c
rename to drivers/rtc/rtc-rk8xx.c
index 35c9aad..5d946bf 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk8xx.c
@@ -1,5 +1,5 @@
/*
- * RTC driver for Rockchip RK808
+ * RTC driver for Rockchip RK8XX
*
* Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
*
@@ -20,14 +20,33 @@
#include
#include
#include
-#include
#include
#include
+#include
+
+#define RK8XX_SECONDS_REG 0x00
+#define RK8XX_MINUTES_REG 0x01
+#define RK8XX_HOURS_REG0x02
+#define RK8XX_DAYS_REG 0x03
+#define RK8XX_MONTHS_REG 0x04
+#define RK8XX_YEARS_REG0x05
+#define RK8XX_WEEKS_REG0x06
+#define RK8XX_ALARM_SECONDS_REG0x08
+#define RK8XX_ALARM_MINUTES_REG0x09
+#define RK8XX_ALARM_HOURS_REG 0x0A
+#define RK8XX_ALARM_DAYS_REG 0x0B
+#define RK8XX_ALARM_MONTHS_REG 0x0C
+#define RK8XX_ALARM_YEARS_REG 0x0D
+#define RK8XX_RTC_CTRL_REG 0x10
+#define RK8XX_RTC_STATUS_REG 0x11
+#define RK8XX_RTC_INT_REG 0x12
+#define RK8XX_RTC_COMP_LSB_REG 0x13
+#define RK8XX_RTC_COMP_MSB_REG 0x14
/* RTC_CTRL_REG bitfields */
#define BIT_RTC_CTRL_REG_STOP_RTC_MBIT(0)
-/* RK808 has a shadowed register for saving a "frozen" RTC time.
+/* RK8xx has a shadowed register for saving a "frozen" RTC time.
* When user setting "GET_TIME" to 1, the time will save in this shadowed
* register. If set "READSEL" to 1, user read rtc time register, actually
* get the time of that moment. If we need the real time, clr this bit.
@@ -47,17 +66,25 @@
/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
-#define NUM_TIME_REGS (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
-#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
+#define NUM_TIME_REGS (RK8XX_WEEKS_REG - RK8XX_SECONDS_REG + 1)
+#define NUM_ALARM_REGS (RK8XX_ALARM_YEARS_REG - RK8XX_ALARM_SECONDS_REG + 1)
-struct rk808_rtc {
- struct rk808 *rk808;
+static const struct regmap_config rk8xx_rtc_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK8XX_RTC_COMP_MSB_REG,
+ .cache_type = REGCACHE
[PATCH] rtc: rk808: rename rtc-rk808.c to rtc-rk8xx.c
From: zhangqing
make rtc-rk8xx.c compatible for all pmic chips.
for pmic chips(rk808\rk807\rk816\rk818) in the future.
Signed-off-by: zhangqing
---
drivers/mfd/rk808.c | 2 +-
drivers/rtc/Kconfig | 8 +-
drivers/rtc/Makefile | 2 +-
drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} | 218 ++-
4 files changed, 131 insertions(+), 99 deletions(-)
rename drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} (64%)
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 4b1e439..21da22b 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -77,7 +77,7 @@ static const struct mfd_cell rk808s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
{
- .name = "rk808-rtc",
+ .name = "rk8xx-rtc",
.num_resources = ARRAY_SIZE(rtc_resources),
.resources = &rtc_resources[0],
},
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 376322f..d669473d 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -325,15 +325,15 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
-config RTC_DRV_RK808
- tristate "Rockchip RK808 RTC"
+config RTC_DRV_RK8XX
+ tristate "Rockchip RK8XX RTC"
depends on MFD_RK808
help
If you say yes here you will get support for the
- RTC of RK808 PMIC.
+ RTC of RK8XX PMIC.
This driver can also be built as a module. If so, the module
- will be called rk808-rtc.
+ will be called rk8xx-rtc.
config RTC_DRV_MAX77802
tristate "Maxim 77802 RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 62d61b2..5b1384a 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -120,7 +120,7 @@ obj-$(CONFIG_RTC_DRV_PUV3) += rtc-puv3.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701)+= rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
-obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
+obj-$(CONFIG_RTC_DRV_RK8XX)+= rtc-rk8xx.o
obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk8xx.c
similarity index 64%
rename from drivers/rtc/rtc-rk808.c
rename to drivers/rtc/rtc-rk8xx.c
index 35c9aad..5d946bf 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk8xx.c
@@ -1,5 +1,5 @@
/*
- * RTC driver for Rockchip RK808
+ * RTC driver for Rockchip RK8XX
*
* Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
*
@@ -20,14 +20,33 @@
#include
#include
#include
-#include
#include
#include
+#include
+
+#define RK8XX_SECONDS_REG 0x00
+#define RK8XX_MINUTES_REG 0x01
+#define RK8XX_HOURS_REG0x02
+#define RK8XX_DAYS_REG 0x03
+#define RK8XX_MONTHS_REG 0x04
+#define RK8XX_YEARS_REG0x05
+#define RK8XX_WEEKS_REG0x06
+#define RK8XX_ALARM_SECONDS_REG0x08
+#define RK8XX_ALARM_MINUTES_REG0x09
+#define RK8XX_ALARM_HOURS_REG 0x0A
+#define RK8XX_ALARM_DAYS_REG 0x0B
+#define RK8XX_ALARM_MONTHS_REG 0x0C
+#define RK8XX_ALARM_YEARS_REG 0x0D
+#define RK8XX_RTC_CTRL_REG 0x10
+#define RK8XX_RTC_STATUS_REG 0x11
+#define RK8XX_RTC_INT_REG 0x12
+#define RK8XX_RTC_COMP_LSB_REG 0x13
+#define RK8XX_RTC_COMP_MSB_REG 0x14
/* RTC_CTRL_REG bitfields */
#define BIT_RTC_CTRL_REG_STOP_RTC_MBIT(0)
-/* RK808 has a shadowed register for saving a "frozen" RTC time.
+/* RK8xx has a shadowed register for saving a "frozen" RTC time.
* When user setting "GET_TIME" to 1, the time will save in this shadowed
* register. If set "READSEL" to 1, user read rtc time register, actually
* get the time of that moment. If we need the real time, clr this bit.
@@ -47,17 +66,25 @@
/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
-#define NUM_TIME_REGS (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
-#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
+#define NUM_TIME_REGS (RK8XX_WEEKS_REG - RK8XX_SECONDS_REG + 1)
+#define NUM_ALARM_REGS (RK8XX_ALARM_YEARS_REG - RK8XX_ALARM_SECONDS_REG + 1)
-struct rk808_rtc {
- struct rk808 *rk808;
+static const struct regmap_config rk8xx_rtc_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = RK8XX_RTC_COMP_MSB_REG,
+
blk-mq: takes hours for scsi scanning finish when thousands of LUNs
Hi, Jens,Tejun
Current problem we meet:
When Multiple Queue is used for scsi, the period between each LUN probe
is increasing as the number of block request queue goes up, eventually
it takes hours for Initiator to finish scanning thousands of LUNs.
Kernel version we're using: 4.1.6-14
I tested with MainLine, it also has same issue.
My analysis:
As for each new LUN, scsi_mq_alloc_queue is called when Multiple Queue
is enabled for scsi to allocate and initialize the new queue, the process is:
->blk_mq_init_queue
->blk_mq_init_allocated_queue
->blk_mq_add_queue_tag_set
->blk_mq_update_tag_set_depth
blk_mq_update_tag_set_depth calls blk_mq_freeze_queue for each
queue in the set tag list, if the queue is already in the tag list,
we can see that it takes tens of ticks to freeze the queue, if there are
thousands of queues in the list, it will take more than ten seconds(HZ=1000)
for a new queue to finish its initialization, this is really a high delay,
my question here is: why blk_mq_update_tag_set_depth updates
each queue in the tag list?
if this thing must be done, as the code below shows just changing flags
depending on 'shared' variable why shouldn't we store the previous result of
'shared'
and compare with the current result, if it's unchanged, nothing will be done
and avoid looping all queues in list.
static void blk_mq_update_tag_set_depth(struct blk_mq_tag_set *set)
{
struct blk_mq_hw_ctx *hctx;
struct request_queue *q;
bool shared;
int i;
if (set->tag_list.next == set->tag_list.prev)
shared = false;
else
shared = true;
list_for_each_entry(q, &set->tag_list, tag_set_list) {
blk_mq_freeze_queue(q);
queue_for_each_hw_ctx(q, hctx, i) {
if (shared)
hctx->flags |= BLK_MQ_F_TAG_SHARED;
else
hctx->flags &= ~BLK_MQ_F_TAG_SHARED;
}
blk_mq_unfreeze_queue(q);
}
}
Deep insight:
I dig more into the delay and find more details, for each already existing
queue, the delay comes from blk_mq_freeze_queue_wait function
because the request queue->mq_usage_counter is not zero, blocked on
it and woken up by percpu_ref_switch_to_atomic_rcu after a grace period,
let me explain how this happens.
Although for each new allocating queue, PERCPU_REF_INIT_ATOMIC flag is set
when allocating the percpu ref, but when registering queue,
blk_mq_finish_init changes it to PERCPU by calling percpu_ref_switch_to_percpu,
So every time blk_mq_freeze_queue_start, it runs in this way
blk_mq_freeze_queue_start
->percpu_ref_kill->percpu_ref_kill_and_confirm
->__percpu_ref_switch_to_atomic
->call_rcu_sched(&ref->rcu,percpu_ref_switch_to_atomic_rcu)
and blk_mq_freeze_queue_wait blocks on queue->mq_usage_counter
as it is not zero, and wake up by percpu_ref_switch_to_atomic_rcu
after a grace period
My question here is why should we change ref to PERCPU at blk_mq_finish_init?
because of this changing, delay appears.
My suggestion:
Don't change ref to PERCPU by blk_mq_finish_init, keeping
it in ATOMIC, this can solve the problem.
Or optimize blk_mq_update_tag_set_depth to avoid such delay
The patch below is one possible fix, as I can't see if it can introduce
other regression issue, so could you guy look into it and give some advice?
/Thanks
0001-Avoid-long-delay-for-scsi-scanning-when-thousands-of.patch
>From 4505e8d499a7c336ebc3b588b089f5408841b421 Mon Sep 17 00:00:00 2001
From: Jason Luo
Date: Mon, 19 Oct 2015 14:51:51 +0800
Subject: [PATCH] Avoid long delay for scsi scanning when thousands of LUNs
Signed-off-by: Jason Luo
---
block/blk-mq-sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c
index b79685e..06533a9 100644
--- a/block/blk-mq-sysfs.c
+++ b/block/blk-mq-sysfs.c
@@ -404,7 +404,9 @@ static void blk_mq_sysfs_init(struct request_queue *q)
/* see blk_register_queue() */
void blk_mq_finish_init(struct request_queue *q)
{
- percpu_ref_switch_to_percpu(&q->mq_usage_counter);
+ /* Maybe some other things can be done here in the future
+* leave it with empty */
+ /*percpu_ref_switch_to_percpu(&q->mq_usage_counter);*/
}
int blk_mq_register_disk(struct gendisk *disk)
-- 2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
