* [PATCH v9 6/6] DO NOT MERGE: full sensehat device tree overlay for raspberry pi 4
From: Charles Mirabile @ 2022-04-19 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Charles Mirabile, Serge Schneider, Stefan Wahren,
Nicolas Saenz Julienne, Mattias Brugger, linux-rpi-kernel,
linux-arm-kernel, fedora-rpi, Mwesigwa Guma, Joel Savitz
In-Reply-To: <20220419205158.28088-1-cmirabil@redhat.com>
This patch shold not be merged - dtbs files are not stored in the
kernel tree. We just provide this file so the code can be tested.
This overlay is suitable for testing the driver, it can be compiled with
dtc and put in the /boot/overlays/ folder then specified in config.txt
by putting the lines:
dtoverlay= #suppress loading of default overlay for HAT
dtoverlay=sensehat #load custom overlay
at the beginning before any other lines in config.txt
Co-developed-by: Mwesigwa Guma <mguma@redhat.com>
Signed-off-by: Mwesigwa Guma <mguma@redhat.com>
Co-developed-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
---
sensehat.dtbs | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644 sensehat.dtbs
diff --git a/sensehat.dtbs b/sensehat.dtbs
new file mode 100644
index 000000000000..9e5a6d9229b1
--- /dev/null
+++ b/sensehat.dtbs
@@ -0,0 +1,52 @@
+/dts-v1/;
+/plugin/;
+
+/ {
+ compatible = "brcm,bcm2835";
+};
+
+&i2c1 {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "okay";
+
+ sensehat@46 {
+ compatible = "raspberrypi,sensehat";
+ reg = <0x46>;
+ interrupt-parent = <&gpio>;
+ status = "okay";
+ display {
+ compatible = "raspberrypi,sensehat-display";
+ status = "okay";
+ };
+ joystick {
+ compatible = "raspberrypi,sensehat-joystick";
+ interrupts = <23 1>;
+ status = "okay";
+ };
+ };
+
+ lsm9ds1-magn@1c {
+ compatible = "st,lsm9ds1-magn";
+ reg = <0x1c>;
+ status = "okay";
+ };
+
+ lsm9ds1-accel@6a {
+ compatible = "st,lsm9ds1-accel";
+ reg = <0x6a>;
+ status = "okay";
+ };
+
+ lps25h-press@5c {
+ compatible = "st,lps25h-press";
+ reg = <0x5c>;
+ status = "okay";
+ };
+
+ hts221-humid@5f {
+ compatible = "st,hts221-humid\0st,hts221";
+ reg = <0x5f>;
+ status = "okay";
+ };
+};
--
2.31.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 v9 3/6] drivers/auxdisplay: sensehat: Raspberry Pi Sense HAT display driver
From: Charles Mirabile @ 2022-04-19 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Charles Mirabile, Serge Schneider, Stefan Wahren,
Nicolas Saenz Julienne, Mattias Brugger, linux-rpi-kernel,
linux-arm-kernel, fedora-rpi, Miguel Ojeda, Daniel Bauman,
Mwesigwa Guma, Joel Savitz
In-Reply-To: <20220419205158.28088-1-cmirabil@redhat.com>
This patch adds the driver for the 8x8 RGB LED matrix display
on the Sense HAT. It appears as a character device named sense-hat
in /dev/. That special file is 192 bytes large and contains 64
RGB triplets (3 bytes each) one for each pixel in row major order.
Co-developed-by: Daniel Bauman <dbauman@redhat.com>
Signed-off-by: Daniel Bauman <dbauman@redhat.com>
Co-developed-by: Mwesigwa Guma <mguma@redhat.com>
Signed-off-by: Mwesigwa Guma <mguma@redhat.com>
Co-developed-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
---
drivers/auxdisplay/Kconfig | 8 +
drivers/auxdisplay/Makefile | 1 +
drivers/auxdisplay/sensehat-display.c | 205 ++++++++++++++++++++++++++
3 files changed, 214 insertions(+)
create mode 100644 drivers/auxdisplay/sensehat-display.c
diff --git a/drivers/auxdisplay/Kconfig b/drivers/auxdisplay/Kconfig
index 64012cda4d12..9bad1aade7a0 100644
--- a/drivers/auxdisplay/Kconfig
+++ b/drivers/auxdisplay/Kconfig
@@ -203,6 +203,14 @@ config ARM_CHARLCD
line and the Linux version on the second line, but that's
still useful.
+config SENSEHAT_DISPLAY
+ tristate "Raspberry Pi Sense HAT display driver"
+ depends on I2C
+ select MFD_SIMPLE_MFD_I2C
+ help
+ This is a driver for the Raspberry Pi Sensehat 8x8 RBG-LED matrix
+ you can access it as a misc device at /dev/sense-hat
+
menuconfig PARPORT_PANEL
tristate "Parallel port LCD/Keypad Panel support"
depends on PARPORT
diff --git a/drivers/auxdisplay/Makefile b/drivers/auxdisplay/Makefile
index 6968ed4d3f0a..30b2b7934046 100644
--- a/drivers/auxdisplay/Makefile
+++ b/drivers/auxdisplay/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_HT16K33) += ht16k33.o
obj-$(CONFIG_PARPORT_PANEL) += panel.o
obj-$(CONFIG_LCD2S) += lcd2s.o
obj-$(CONFIG_LINEDISP) += line-display.o
+obj-$(CONFIG_SENSEHAT_DISPLAY) += sensehat-display.o
diff --git a/drivers/auxdisplay/sensehat-display.c b/drivers/auxdisplay/sensehat-display.c
new file mode 100644
index 000000000000..9faaee5cde8a
--- /dev/null
+++ b/drivers/auxdisplay/sensehat-display.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Raspberry Pi Sense HAT 8x8 LED matrix display driver
+ * http://raspberrypi.org
+ *
+ * Copyright (C) 2015 Raspberry Pi
+ * Copyright (C) 2021 Charles Mirabile, Mwesigwa Guma, Joel Savitz
+ *
+ * Original Author: Serge Schneider
+ * Revised for upstream Linux by: Charles Mirabile, Mwesigwa Guma, Joel Savitz
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <linux/string.h>
+#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mod_devicetable.h>
+#include <linux/miscdevice.h>
+#include <linux/regmap.h>
+#include <linux/property.h>
+
+#define DISPLAY_SMB_REG 0x00
+#define RGB_555_MASK 0x1f
+#define NUM_LEDS 8
+#define NUM_CHANNELS 3
+
+struct sensehat_display {
+ struct platform_device *pdev;
+ struct miscdevice mdev;
+ struct mutex rw_mtx;
+ u8 vmem[NUM_LEDS][NUM_LEDS][NUM_CHANNELS];
+ struct regmap *regmap;
+};
+
+#define VMEM_SIZE sizeof_field(struct sensehat_display, vmem)
+
+
+static int sensehat_update_display(struct sensehat_display *display)
+{
+ int i, j, k, ret;
+ u8 buff[NUM_LEDS][NUM_CHANNELS][NUM_LEDS];
+
+ for (i = 0; i < NUM_LEDS; ++i)
+ for (j = 0; j < NUM_LEDS; ++j)
+ for (k = 0; k < NUM_CHANNELS; ++k)
+ buff[i][k][j] =
+ display->vmem[i][j][k] & RGB_555_MASK;
+
+ ret = regmap_bulk_write(display->regmap, DISPLAY_SMB_REG, buff,
+ VMEM_SIZE);
+ if (ret < 0)
+ dev_err(&display->pdev->dev,
+ "Update to 8x8 LED matrix display failed");
+ return ret;
+}
+
+static loff_t sensehat_display_llseek(struct file *filp, loff_t offset,
+ int whence)
+{
+ return fixed_size_llseek(filp, offset, whence, VMEM_SIZE);
+}
+
+static ssize_t sensehat_display_read(struct file *filp, char __user *buf,
+ size_t count, loff_t *f_pos)
+{
+ struct sensehat_display *sensehat_display =
+ container_of(filp->private_data, struct sensehat_display, mdev);
+ ssize_t ret = -EFAULT;
+
+ if (*f_pos < 0 || *f_pos >= VMEM_SIZE)
+ return 0;
+ count = min_t(size_t, count, VMEM_SIZE - *f_pos);
+
+ if (mutex_lock_interruptible(&sensehat_display->rw_mtx))
+ return -ERESTARTSYS;
+ if (copy_to_user(buf, *f_pos + (u8 *)sensehat_display->vmem, count))
+ goto out;
+ *f_pos += count;
+ ret = count;
+out:
+ mutex_unlock(&sensehat_display->rw_mtx);
+ return ret;
+}
+
+static ssize_t sensehat_display_write(struct file *filp, const char __user *buf,
+ size_t count, loff_t *f_pos)
+{
+ struct sensehat_display *sensehat_display =
+ container_of(filp->private_data, struct sensehat_display, mdev);
+ int ret = -EFAULT;
+
+ if (*f_pos < 0 || *f_pos >= VMEM_SIZE)
+ return -EFBIG;
+ count = min_t(size_t, count, VMEM_SIZE - *f_pos);
+
+ if (mutex_lock_interruptible(&sensehat_display->rw_mtx))
+ return -ERESTARTSYS;
+ if (copy_from_user(*f_pos + (u8 *)sensehat_display->vmem, buf, count))
+ goto out;
+ ret = sensehat_update_display(sensehat_display);
+ if (ret < 0) {
+ ret = -EIO;
+ goto out;
+ }
+ *f_pos += count;
+ ret = count;
+out:
+ mutex_unlock(&sensehat_display->rw_mtx);
+ return ret;
+}
+
+static const struct file_operations sensehat_display_fops = {
+ .owner = THIS_MODULE,
+ .llseek = sensehat_display_llseek,
+ .read = sensehat_display_read,
+ .write = sensehat_display_write,
+};
+
+static int sensehat_display_probe(struct platform_device *pdev)
+{
+ int ret;
+
+ struct sensehat_display *sensehat_display =
+ devm_kmalloc(&pdev->dev, sizeof(*sensehat_display), GFP_KERNEL);
+ if (!sensehat_display)
+ return -ENOMEM;
+
+ sensehat_display->pdev = pdev;
+
+ dev_set_drvdata(&pdev->dev, sensehat_display);
+
+ sensehat_display->regmap = dev_get_regmap(pdev->dev.parent, NULL);
+ if (!sensehat_display->regmap) {
+ dev_err(&pdev->dev,
+ "unable to get sensehat regmap");
+ return -ENODEV;
+ }
+
+ memset(sensehat_display->vmem, 0, VMEM_SIZE);
+
+ mutex_init(&sensehat_display->rw_mtx);
+
+ ret = sensehat_update_display(sensehat_display);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "Could not communicate with sensehat");
+ return ret;
+ }
+
+ sensehat_display->mdev = (struct miscdevice){
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = "sense-hat",
+ .mode = 0666,
+ .fops = &sensehat_display_fops,
+ };
+
+ ret = misc_register(&sensehat_display->mdev);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "Could not register 8x8 LED matrix display.");
+ return ret;
+ }
+
+ dev_info(&pdev->dev,
+ "8x8 LED matrix display registered with minor number %i",
+ sensehat_display->mdev.minor);
+
+ return 0;
+}
+
+static int sensehat_display_remove(struct platform_device *pdev)
+{
+ struct sensehat_display *sensehat_display = dev_get_drvdata(&pdev->dev);
+
+ misc_deregister(&sensehat_display->mdev);
+ return 0;
+}
+
+static const struct of_device_id sensehat_display_device_id[] = {
+ { .compatible = "raspberrypi,sensehat-display" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sensehat_display_device_id);
+
+static struct platform_driver sensehat_display_driver = {
+ .probe = sensehat_display_probe,
+ .remove = sensehat_display_remove,
+ .driver = {
+ .name = "sensehat-display",
+ .of_match_table = sensehat_display_device_id,
+ },
+};
+
+module_platform_driver(sensehat_display_driver);
+
+MODULE_DESCRIPTION("Raspberry Pi Sense HAT 8x8 LED matrix display driver");
+MODULE_AUTHOR("Charles Mirabile <cmirabil@redhat.com>");
+MODULE_AUTHOR("Serge Schneider <serge@raspberrypi.org>");
+MODULE_LICENSE("GPL");
--
2.31.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 v9 2/6] drivers/input/joystick: sensehat: Raspberry Pi Sense HAT joystick driver
From: Charles Mirabile @ 2022-04-19 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Charles Mirabile, Serge Schneider, Stefan Wahren,
Nicolas Saenz Julienne, Mattias Brugger, linux-rpi-kernel,
linux-arm-kernel, fedora-rpi, Dmitry Torokhov, linux-input,
Daniel Bauman, Mwesigwa Guma, Joel Savitz
In-Reply-To: <20220419205158.28088-1-cmirabil@redhat.com>
This patch adds the driver for the Sense HAT joystick. It outputs BTN_DPAD
key events when moved in any of the four directions and the BTN_SELECT
event when depressed.
Co-developed-by: Daniel Bauman <dbauman@redhat.com>
Signed-off-by: Daniel Bauman <dbauman@redhat.com>
Co-developed-by: Mwesigwa Guma <mguma@redhat.com>
Signed-off-by: Mwesigwa Guma <mguma@redhat.com>
Co-developed-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
---
drivers/input/joystick/Kconfig | 11 ++
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/sensehat-joystick.c | 137 +++++++++++++++++++++
3 files changed, 149 insertions(+)
create mode 100644 drivers/input/joystick/sensehat-joystick.c
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index 3b23078bc7b5..505a032e2786 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -399,4 +399,15 @@ config JOYSTICK_N64
Say Y here if you want enable support for the four
built-in controller ports on the Nintendo 64 console.
+config JOYSTICK_SENSEHAT
+ tristate "Raspberry Pi Sense HAT joystick"
+ depends on INPUT && I2C
+ select MFD_SIMPLE_MFD_I2C
+ help
+ Say Y here if you want to enable the driver for the
+ the Raspberry Pi Sense HAT.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sensehat_joystick.
+
endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 5174b8aba2dd..39c8b5c6e5ae 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_JOYSTICK_N64) += n64joy.o
obj-$(CONFIG_JOYSTICK_PSXPAD_SPI) += psxpad-spi.o
obj-$(CONFIG_JOYSTICK_PXRC) += pxrc.o
obj-$(CONFIG_JOYSTICK_QWIIC) += qwiic-joystick.o
+obj-$(CONFIG_JOYSTICK_SENSEHAT) += sensehat-joystick.o
obj-$(CONFIG_JOYSTICK_SIDEWINDER) += sidewinder.o
obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
obj-$(CONFIG_JOYSTICK_SPACEORB) += spaceorb.o
diff --git a/drivers/input/joystick/sensehat-joystick.c b/drivers/input/joystick/sensehat-joystick.c
new file mode 100644
index 000000000000..6fed6004f464
--- /dev/null
+++ b/drivers/input/joystick/sensehat-joystick.c
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Raspberry Pi Sense HAT joystick driver
+ * http://raspberrypi.org
+ *
+ * Copyright (C) 2015 Raspberry Pi
+ * Copyright (C) 2021 Charles Mirabile, Mwesigwa Guma, Joel Savitz
+ *
+ * Original Author: Serge Schneider
+ * Revised for upstream Linux by: Charles Mirabile, Mwesigwa Guma, Joel Savitz
+ */
+
+#include <linux/module.h>
+#include <linux/input.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/property.h>
+
+#define JOYSTICK_SMB_REG 0xf2
+
+struct sensehat_joystick {
+ struct platform_device *pdev;
+ struct input_dev *keys_dev;
+ unsigned long prev_states;
+ struct regmap *regmap;
+};
+
+static const unsigned int keymap[] = {
+ BTN_DPAD_DOWN, BTN_DPAD_RIGHT, BTN_DPAD_UP, BTN_SELECT, BTN_DPAD_LEFT,
+};
+
+static irqreturn_t sensehat_joystick_report(int n, void *cookie)
+{
+ int i, error, keys;
+ struct sensehat_joystick *sensehat_joystick = cookie;
+ unsigned long curr_states, changes;
+
+ error = regmap_read(sensehat_joystick->regmap, JOYSTICK_SMB_REG, &keys);
+ if (error < 0) {
+ dev_err(&sensehat_joystick->pdev->dev,
+ "Failed to read joystick state: %d", error);
+ return IRQ_NONE;
+ }
+ curr_states = keys;
+ bitmap_xor(&changes, &curr_states, &sensehat_joystick->prev_states,
+ ARRAY_SIZE(keymap));
+
+ for_each_set_bit(i, &changes, ARRAY_SIZE(keymap)) {
+ input_report_key(sensehat_joystick->keys_dev, keymap[i],
+ curr_states & BIT(i));
+ }
+
+ input_sync(sensehat_joystick->keys_dev);
+ sensehat_joystick->prev_states = keys;
+ return IRQ_HANDLED;
+}
+
+static int sensehat_joystick_probe(struct platform_device *pdev)
+{
+ int error, i, irq;
+ struct sensehat_joystick *sensehat_joystick = devm_kzalloc(
+ &pdev->dev, sizeof(*sensehat_joystick), GFP_KERNEL);
+ if (!sensehat_joystick)
+ return -ENOMEM;
+
+ sensehat_joystick->pdev = pdev;
+
+ sensehat_joystick->regmap = dev_get_regmap(sensehat_joystick->pdev->dev.parent, NULL);
+ if (!sensehat_joystick->regmap) {
+ dev_err(&pdev->dev,
+ "unable to get sensehat regmap");
+ return -ENODEV;
+ }
+
+
+ sensehat_joystick->keys_dev = devm_input_allocate_device(&pdev->dev);
+ if (!sensehat_joystick->keys_dev) {
+ dev_err(&pdev->dev, "Could not allocate input device.");
+ return -ENOMEM;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(keymap); i++)
+ set_bit(keymap[i], sensehat_joystick->keys_dev->keybit);
+
+ sensehat_joystick->keys_dev->name = "Raspberry Pi Sense HAT Joystick";
+ sensehat_joystick->keys_dev->phys = "sensehat-joystick/input0";
+ sensehat_joystick->keys_dev->id.bustype = BUS_I2C;
+ sensehat_joystick->keys_dev->evbit[0] =
+ BIT_MASK(EV_KEY) | BIT_MASK(EV_REP);
+
+ error = input_register_device(sensehat_joystick->keys_dev);
+ if (error) {
+ dev_err(&pdev->dev, "Could not register input device.");
+ return error;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "Could not retrieve interrupt request.");
+ return irq;
+ }
+
+ error = devm_request_threaded_irq(&pdev->dev, irq, NULL,
+ sensehat_joystick_report,
+ IRQF_ONESHOT, "keys",
+ sensehat_joystick);
+
+ if (error) {
+ dev_err(&pdev->dev, "IRQ request failed.");
+ return error;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id sensehat_joystick_device_id[] = {
+ { .compatible = "raspberrypi,sensehat-joystick" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sensehat_joystick_device_id);
+
+static struct platform_driver sensehat_joystick_driver = {
+ .probe = sensehat_joystick_probe,
+ .driver = {
+ .name = "sensehat-joystick",
+ .of_match_table = sensehat_joystick_device_id,
+ },
+};
+
+module_platform_driver(sensehat_joystick_driver);
+
+MODULE_DESCRIPTION("Raspberry Pi Sense HAT joystick driver");
+MODULE_AUTHOR("Charles Mirabile <cmirabil@redhat.com>");
+MODULE_AUTHOR("Serge Schneider <serge@raspberrypi.org>");
+MODULE_LICENSE("GPL");
--
2.31.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 v9 4/6] dt-bindings: mfd: sensehat: Add Raspberry Pi Sense HAT schema
From: Charles Mirabile @ 2022-04-19 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Charles Mirabile, Serge Schneider, Stefan Wahren,
Nicolas Saenz Julienne, Mattias Brugger, linux-rpi-kernel,
linux-arm-kernel, fedora-rpi, Miguel Ojeda, Rob Herring,
Krzysztof Kozlowski, Dmitry Torokhov, Lee Jones, devicetree,
linux-input, Mwesigwa Guma, Joel Savitz
In-Reply-To: <20220419205158.28088-1-cmirabil@redhat.com>
This patch adds the device tree bindings for the Sense HAT
and each of its children devices in yaml form.
Co-developed-by: Mwesigwa Guma <mguma@redhat.com>
Signed-off-by: Mwesigwa Guma <mguma@redhat.com>
Co-developed-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
---
.../raspberrypi,sensehat-display.yaml | 27 +++++++++
.../input/raspberrypi,sensehat-joystick.yaml | 32 ++++++++++
.../bindings/mfd/raspberrypi,sensehat.yaml | 58 +++++++++++++++++++
3 files changed, 117 insertions(+)
create mode 100644 Documentation/devicetree/bindings/auxdisplay/raspberrypi,sensehat-display.yaml
create mode 100644 Documentation/devicetree/bindings/input/raspberrypi,sensehat-joystick.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/raspberrypi,sensehat.yaml
diff --git a/Documentation/devicetree/bindings/auxdisplay/raspberrypi,sensehat-display.yaml b/Documentation/devicetree/bindings/auxdisplay/raspberrypi,sensehat-display.yaml
new file mode 100644
index 000000000000..5e41d6b7817d
--- /dev/null
+++ b/Documentation/devicetree/bindings/auxdisplay/raspberrypi,sensehat-display.yaml
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/auxdisplay/raspberrypi,sensehat-display.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi Sensehat Display
+
+maintainers:
+ - Charles Mirabile <cmirabil@redhat.com>
+ - Mwesigwa Guma <mguma@redhat.com>
+ - Joel Savitz <jsavitz@redhat.com>
+
+description:
+ This device is part of the sensehat multi function device.
+ For more information see ../mfd/raspberrypi,sensehat.yaml.
+
+ This device features a programmable 8x8 RGB LED matrix.
+
+properties:
+ compatible:
+ const: raspberrypi,sensehat-display
+
+required:
+ - compatible
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/input/raspberrypi,sensehat-joystick.yaml b/Documentation/devicetree/bindings/input/raspberrypi,sensehat-joystick.yaml
new file mode 100644
index 000000000000..2c8bc10e6436
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/raspberrypi,sensehat-joystick.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/raspberrypi,sensehat-joystick.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi Sensehat Joystick
+
+maintainers:
+ - Charles Mirabile <cmirabil@redhat.com>
+ - Mwesigwa Guma <mguma@redhat.com>
+ - Joel Savitz <jsavitz@redhat.com>
+
+description:
+ This device is part of the sensehat multi function device.
+ For more information see ../mfd/raspberrypi,sensehat.yaml.
+
+ This device features a five button joystick (up, down,left,
+ right, click)
+
+properties:
+ compatible:
+ const: raspberrypi,sensehat-joystick
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
diff --git a/Documentation/devicetree/bindings/mfd/raspberrypi,sensehat.yaml b/Documentation/devicetree/bindings/mfd/raspberrypi,sensehat.yaml
new file mode 100644
index 000000000000..6ac43dfc0270
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/raspberrypi,sensehat.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/raspberrypi,sensehat.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Raspberry Pi Sensehat
+
+maintainers:
+ - Charles Mirabile <cmirabil@redhat.com>
+ - Mwesigwa Guma <mguma@redhat.com>
+ - Joel Savitz <jsavitz@redhat.com>
+
+description:
+ The Raspberry Pi Sensehat is an addon board originally developed
+ for the Raspberry Pi that has a joystick and an 8x8 RGB LED display
+ as well as several environmental sensors. It connects via i2c and
+ a gpio for irq.
+
+properties:
+ compatible:
+ const: raspberrypi,sensehat
+
+ reg:
+ maxItems: 1
+
+ joystick:
+ $ref: /schemas/input/raspberrypi,sensehat-joystick.yaml#
+
+ display:
+ $ref: /schemas/auxdisplay/raspberrypi,sensehat-display.yaml#
+
+required:
+ - compatible
+ - reg
+ - joystick
+ - display
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ hat@46 {
+ compatible = "raspberrypi,sensehat";
+ reg = <0x46>;
+ display {
+ compatible = "raspberrypi,sensehat-display";
+ };
+ joystick {
+ compatible = "raspberrypi,sensehat-joystick";
+ interrupts = <23 IRQ_TYPE_EDGE_RISING>;
+ };
+ };
+ };
--
2.31.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 v9 0/6] Raspberry Pi Sense HAT driver
From: Charles Mirabile @ 2022-04-19 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Charles Mirabile, Serge Schneider, Stefan Wahren,
Nicolas Saenz Julienne, Mattias Brugger, linux-rpi-kernel,
linux-arm-kernel, fedora-rpi, Daniel Bauman, Mwesigwa Guma,
Joel Savitz
This patch series adds a set of drivers for operating the Sense HAT
peripheral device. This board is an add on for the Raspberry Pi that is
designed to connect using the GPIO connector and communicate via I2C.
It features:
- a joystick
- an 8x8 RGB LED matrix display
- a whole bunch of environmental sensors with their own drivers
(those are already in upstream Linux)
This is a refactor of the work of Serge Schneider, the author of a
version of this driver that is currently in the Raspberry Pi downstream
kernel. We modified his code to make it suitable for upstream Linux.
A couple of tests are available for the driver in the test folder in
this repo: https://github.com/underground-software/sensehat.git
- sensehat_joystick_test logs the input events from the
joystick to the console
- sensehat_display_test displays various solid colors on
the LED panel.
- full_sensehat_test displays a single lit cell that can be
moved with the joystick. Pressing the joystick ends the
program.
For more information about the Sense HAT, visit:
https://www.raspberrypi.org/products/sense-hat/
Changes since v8:
- Fixed a few small things in the device tree bindings.
I forgot to include the fact that Rob Herring had already
reviewed them when I posted v8, so Krzysztof Kozlowski
jumped in and offered his input. The suggestions were good
so we decided to include them. Sorry for the confusion.
- Corrected a typo in the description of the display driver.
The format of the special file used by the driver was changed
in v8 and this was described in the cover letter of the patch,
but not in the actual note attached to that patch. This is now
fixed.
Co-developed-by: Daniel Bauman <dbauman@redhat.com>
Signed-off-by: Daniel Bauman <dbauman@redhat.com>
Co-developed-by: Mwesigwa Guma <mguma@redhat.com>
Signed-off-by: Mwesigwa Guma <mguma@redhat.com>
Co-developed-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
Charles Mirabile (6):
drivers/mfd: sensehat: Add Raspberry Pi Sense HAT to simple_mfd_i2c
drivers/input/joystick: sensehat: Raspberry Pi Sense HAT joystick
driver
drivers/auxdisplay: sensehat: Raspberry Pi Sense HAT display driver
dt-bindings: mfd: sensehat: Add Raspberry Pi Sense HAT schema
MAINTAINERS: Add sensehat driver authors to MAINTAINERS
DO NOT MERGE: full sensehat device tree overlay for raspberry pi 4
.../raspberrypi,sensehat-display.yaml | 27 +++
.../input/raspberrypi,sensehat-joystick.yaml | 32 +++
.../bindings/mfd/raspberrypi,sensehat.yaml | 58 +++++
MAINTAINERS | 11 +
drivers/auxdisplay/Kconfig | 8 +
drivers/auxdisplay/Makefile | 1 +
drivers/auxdisplay/sensehat-display.c | 205 ++++++++++++++++++
drivers/input/joystick/Kconfig | 11 +
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/sensehat-joystick.c | 137 ++++++++++++
drivers/mfd/simple-mfd-i2c.c | 1 +
sensehat.dtbs | 52 +++++
12 files changed, 544 insertions(+)
create mode 100644 Documentation/devicetree/bindings/auxdisplay/raspberrypi,sensehat-display.yaml
create mode 100644 Documentation/devicetree/bindings/input/raspberrypi,sensehat-joystick.yaml
create mode 100644 Documentation/devicetree/bindings/mfd/raspberrypi,sensehat.yaml
create mode 100644 drivers/auxdisplay/sensehat-display.c
create mode 100644 drivers/input/joystick/sensehat-joystick.c
create mode 100644 sensehat.dtbs
--
2.31.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v9 1/6] drivers/mfd: sensehat: Add Raspberry Pi Sense HAT to simple_mfd_i2c
From: Charles Mirabile @ 2022-04-19 20:51 UTC (permalink / raw)
To: linux-kernel
Cc: Charles Mirabile, Serge Schneider, Stefan Wahren,
Nicolas Saenz Julienne, Mattias Brugger, linux-rpi-kernel,
linux-arm-kernel, fedora-rpi, Lee Jones, Mwesigwa Guma,
Joel Savitz
In-Reply-To: <20220419205158.28088-1-cmirabil@redhat.com>
This patch adds the compatible string for the Sense HAT device to
the list of compatible strings in the simple_mfd_i2c driver so that
it can match against the device and load its children and their drivers
Co-developed-by: Mwesigwa Guma <mguma@redhat.com>
Signed-off-by: Mwesigwa Guma <mguma@redhat.com>
Co-developed-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Joel Savitz <jsavitz@redhat.com>
Signed-off-by: Charles Mirabile <cmirabil@redhat.com>
---
drivers/mfd/simple-mfd-i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c
index f4c8fc3ee463..c47f36581f3f 100644
--- a/drivers/mfd/simple-mfd-i2c.c
+++ b/drivers/mfd/simple-mfd-i2c.c
@@ -75,6 +75,7 @@ static const struct simple_mfd_data silergy_sy7636a = {
static const struct of_device_id simple_mfd_i2c_of_match[] = {
{ .compatible = "kontron,sl28cpld" },
{ .compatible = "silergy,sy7636a", .data = &silergy_sy7636a},
+ { .compatible = "raspberrypi,sensehat" },
{}
};
MODULE_DEVICE_TABLE(of, simple_mfd_i2c_of_match);
--
2.31.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: Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
From: Krzysztof Kozlowski @ 2022-04-19 20:48 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Frank Wunderlich, linux-rockchip, Kishon Vijay Abraham I,
Vinod Koul, Rob Herring, Krzysztof Kozlowski, Heiko Stuebner,
Lorenzo Pieralisi, Krzysztof Wilczyński, Bjorn Helgaas,
Philipp Zabel, Johan Jonker, Peter Geis, Michael Riesch,
linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-pci
In-Reply-To: <trinity-a5ae4007-e6e3-4869-80ad-3783109b6d4c-1650400612809@3c-app-gmx-bap70>
On 19/04/2022 22:36, Frank Wunderlich wrote:
>> Just use default as I wrote above.
>
> so like this?
>
> rockchip,pcie30-phymode:
> $ref: '/schemas/types.yaml#/definitions/uint32'
> description: |
> set the phy-mode for enabling bifurcation
> bit0: bifurcation for port 0
> bit1: bifurcation for port 1
> bit2: aggregation
> constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
> minimum: 0x0
> maximum: 0x4
> default: 0x4
Yes.
Best regards,
Krzysztof
_______________________________________________
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/4] PCI: dwc: rockchip: add legacy interrupt support
From: Peter Geis @ 2022-04-19 20:37 UTC (permalink / raw)
To: Marc Zyngier
Cc: Lorenzo Pieralisi, Rob Herring, Krzysztof Wilczyński,
Bjorn Helgaas, Heiko Stuebner, open list:ARM/Rockchip SoC..., PCI,
devicetree, arm-mail-list, Linux Kernel Mailing List
In-Reply-To: <87r15ta469.wl-maz@kernel.org>
On Tue, Apr 19, 2022 at 4:05 AM Marc Zyngier <maz@kernel.org> wrote:
>
> On Tue, 19 Apr 2022 01:23:23 +0100,
> Peter Geis <pgwipeout@gmail.com> wrote:
> >
> > > My only ask is that you properly initialise the HW. This will save
> > > countless amount of head-scratching once you have a decent firmware or
> > > kexec.
> >
> > The only way to ensure that in a sane way is to trigger the resets at
> > driver probe.
>
> If that can be done, that'd be great.
Okay, I'll work on implementing this then.
>
> > Can that be safely done without causing other issues with an already
> > configured card or should I power cycle it as well?
>
> Well, you are already renegotiating the link anyway, so that's a very
> moot point.
Understood, thank you.
>
> > This is starting to feature creep from the original intention of this
> > series, since a pre-configured controller would affect more than just
> > interrupts.
>
> Configuring the HW is not exactly a feature creep. If your intention
> is to keep everything as it was left, then you don't have much of a
> driver, but instead a time bomb. And we can do without another one in
> the tree.
Understood, I apologize if I'm being difficult here, I just want to
make sure I completely understand the assignment.
Your comment about kexec made it clear for me, thank you.
>
> > If you wish, as a compromise I can ensure all INTx interrupts are
> > masked at probe (which would hilariously be the opposite of
> > downstream).
>
> As far as I'm concerned, downstream doesn't exist. If someone wants
> the downstream code, they can use it directly and we don't need to
> merge this code.
Once again, you'll have no argument from me in this regard.
I've had several blocks of hardware enablement sitting out of tree
waiting for the phy code to land.
As much testing as my branch has seen, it's still only a drop in the
bucket compared to finally being mainlined.
I appreciate all of your effort and review here and I absolutely want
this done correctly.
>
> If, on the other hand, you want this driver to be useful and to be
> maintained upstream, initialising the interrupt mask is the absolute
> bare minimum.
I think resetting the whole core is the best move, since it's the only
way we can guarantee a sane configuration with the documentation we
have.
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
From: Frank Wunderlich @ 2022-04-19 20:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Frank Wunderlich, linux-rockchip, Kishon Vijay Abraham I,
Vinod Koul, Rob Herring, Krzysztof Kozlowski, Heiko Stuebner,
Lorenzo Pieralisi, Krzysztof Wilczyński, Bjorn Helgaas,
Philipp Zabel, Johan Jonker, Peter Geis, Michael Riesch,
linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-pci
In-Reply-To: <fce0337a-0c71-a040-0a01-f20b55eb568b@linaro.org>
> Gesendet: Dienstag, 19. April 2022 um 21:43 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> An: "Frank Wunderlich" <frank-w@public-files.de>
> Cc: "Frank Wunderlich" <linux@fw-web.de>, linux-rockchip@lists.infradead.org, "Kishon Vijay Abraham I" <kishon@ti.com>, "Vinod Koul" <vkoul@kernel.org>, "Rob Herring" <robh+dt@kernel.org>, "Krzysztof Kozlowski" <krzk+dt@kernel.org>, "Heiko Stuebner" <heiko@sntech.de>, "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>, "Krzysztof Wilczyński" <kw@linux.com>, "Bjorn Helgaas" <bhelgaas@google.com>, "Philipp Zabel" <p.zabel@pengutronix.de>, "Johan Jonker" <jbx6244@gmail.com>, "Peter Geis" <pgwipeout@gmail.com>, "Michael Riesch" <michael.riesch@wolfvision.net>, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
> Betreff: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
>
> On 19/04/2022 19:49, Frank Wunderlich wrote:
> >> The list should be strictly ordered (defined), so:
> >> items:
> >> - const: ...
> >> - const: ...
> >> - const: ...
> >> minItems: 1
> >>
> >> However the question is - why the clocks have different amount? Is it
> >> per different SoC implementation?
> >
> > i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> > in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> >
> > not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).
>
> You can skip RK3588 compatible or define it this strictly also for that
> chip.
currently driver does clk_bulk initialization so i would define it like you suggested (without any SoC specific switch):
clocks:
minItems: 1
maxItems: 3
clock-names:
items:
- const: "refclk_m"
- const: "refclk_n"
- const: "pclk"
minItems: 1
> >>> +
> >>> + "#phy-cells":
> >>> + const: 0
> >>> +
> >>> + resets:
> >>> + maxItems: 1
> >>> +
> >>> + reset-names:
> >>> + const: phy
> >>> +
> >>> + rockchip,phy-grf:
> >>> + $ref: /schemas/types.yaml#/definitions/phandle
> >>> + description: phandle to the syscon managing the phy "general register files"
> >>> +
> >>> + rockchip,pipe-grf:
> >>> + $ref: /schemas/types.yaml#/definitions/phandle
> >>> + description: phandle to the syscon managing the pipe "general register files"
> >>> +
> >>> + rockchip,pcie30-phymode:
> >>> + $ref: '/schemas/types.yaml#/definitions/uint32'
> >>> + description: |
> >>> + use PHY_MODE_PCIE_AGGREGATION if not defined
> >>
> >> I don't understand the description. Do you mean here a case when the
> >> variable is missing?
> >
> > yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4
>
> Then just use "default: 4"
>
> >
> >>> + minimum: 0x0
> >>> + maximum: 0x4
> >>
> >> Please explain these values. Register values should not be part of
> >> bindings, but instead some logical behavior of hardware or its logic.
> >
> > it's a bitmask, so maybe
> >
> > description: |
> > bit0: bifurcation for port 0
> > bit1: bifurcation for port 1
> > bit2: aggregation
>
> That's good. I got impression you have a header with these values. If
> yes - mention it here.
>
> > use PHY_MODE_PCIE_AGGREGATION (4) as default
>
> Just use default as I wrote above.
so like this?
rockchip,pcie30-phymode:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: |
set the phy-mode for enabling bifurcation
bit0: bifurcation for port 0
bit1: bifurcation for port 1
bit2: aggregation
constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
minimum: 0x0
maximum: 0x4
default: 0x4
regards Frank
_______________________________________________
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 v1] iommu: arm-smmu: disable large page mappings for Nvidia arm-smmu
From: Robin Murphy @ 2022-04-19 20:27 UTC (permalink / raw)
To: Ashish Mhetre, thierry.reding, vdumpa, will, joro, jonathanh,
linux-tegra, linux-arm-kernel, iommu, linux-kernel
Cc: nicolinc, Snikam, Pritesh Raithatha
In-Reply-To: <20220417090432.21110-1-amhetre@nvidia.com>
On 2022-04-17 10:04, Ashish Mhetre wrote:
> Tegra194 and Tegra234 SoCs have the erratum that causes walk cache
> entries to not be invalidated correctly. The problem is that the walk
> cache index generated for IOVA is not same across translation and
> invalidation requests. This is leading to page faults when PMD entry is
> released during unmap and populated with new PTE table during subsequent
> map request. Disabling large page mappings avoids the release of PMD
> entry and avoid translations seeing stale PMD entry in walk cache.
> Fix this by limiting the page mappings to PAGE_SIZE for Tegra194 and
> Tegra234 devices. This is recommended fix from Tegra hardware design
> team.
Is this related to any of the several known MMU-500 invalidation errata,
or is it definitely specific to something NVIDIA have done with their
integration?
> Co-developed-by: Pritesh Raithatha <praithatha@nvidia.com>
> Signed-off-by: Pritesh Raithatha <praithatha@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 23 ++++++++++++++++++++
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 3 +++
> drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
> 3 files changed, 27 insertions(+)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c b/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
> index 01e9b50b10a1..b7a3d06da2f4 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c
> @@ -258,6 +258,27 @@ static void nvidia_smmu_probe_finalize(struct arm_smmu_device *smmu, struct devi
> dev_name(dev), err);
> }
>
> +static void nvidia_smmu_cfg_pgsize_bitmap(struct arm_smmu_device *smmu)
> +{
> + const struct device_node *np = smmu->dev->of_node;
> +
> + /*
> + * Tegra194 and Tegra234 SoCs have the erratum that causes walk cache
> + * entries to not be invalidated correctly. The problem is that the walk
> + * cache index generated for IOVA is not same across translation and
> + * invalidation requests. This is leading to page faults when PMD entry
> + * is released during unmap and populated with new PTE table during
> + * subsequent map request. Disabling large page mappings avoids the
> + * release of PMD entry and avoid translations seeing stale PMD entry in
> + * walk cache.
> + * Fix this by limiting the page mappings to PAGE_SIZE on Tegra194 and
> + * Tegra234.
> + */
> + if (of_device_is_compatible(np, "nvidia,tegra234-smmu") ||
> + of_device_is_compatible(np, "nvidia,tegra194-smmu"))
> + smmu->pgsize_bitmap = PAGE_SIZE;
> +}
> +
> static const struct arm_smmu_impl nvidia_smmu_impl = {
> .read_reg = nvidia_smmu_read_reg,
> .write_reg = nvidia_smmu_write_reg,
> @@ -268,10 +289,12 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
> .global_fault = nvidia_smmu_global_fault,
> .context_fault = nvidia_smmu_context_fault,
> .probe_finalize = nvidia_smmu_probe_finalize,
> + .cfg_pgsize_bitmap = nvidia_smmu_cfg_pgsize_bitmap,
> };
>
> static const struct arm_smmu_impl nvidia_smmu_single_impl = {
> .probe_finalize = nvidia_smmu_probe_finalize,
> + .cfg_pgsize_bitmap = nvidia_smmu_cfg_pgsize_bitmap,
> };
>
> struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 568cce590ccc..3692a19a588a 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -1872,6 +1872,9 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
> if (smmu->features & ARM_SMMU_FEAT_FMT_AARCH64_64K)
> smmu->pgsize_bitmap |= SZ_64K | SZ_512M;
>
> + if (smmu->impl && smmu->impl->cfg_pgsize_bitmap)
> + smmu->impl->cfg_pgsize_bitmap(smmu);
I'm not the biggest fan of adding a super-specific hook for this, when
it seems like it could just as easily be handled in the init_context
hook, which is where it is precisely for the purpose of mangling the
pgtable_cfg to influence io-pgtable's behaviour.
Thanks,
Robin.
> +
> if (arm_smmu_ops.pgsize_bitmap == -1UL)
> arm_smmu_ops.pgsize_bitmap = smmu->pgsize_bitmap;
> else
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> index 2b9b42fb6f30..5d9b03024969 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.h
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.h
> @@ -442,6 +442,7 @@ struct arm_smmu_impl {
> void (*write_s2cr)(struct arm_smmu_device *smmu, int idx);
> void (*write_sctlr)(struct arm_smmu_device *smmu, int idx, u32 reg);
> void (*probe_finalize)(struct arm_smmu_device *smmu, struct device *dev);
> + void (*cfg_pgsize_bitmap)(struct arm_smmu_device *smmu);
> };
>
> #define INVALID_SMENDX -1
_______________________________________________
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] iommu/arm-smmu-v3: Align size in __arm_smmu_tlb_inv_range
From: Nicolin Chen @ 2022-04-19 20:05 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Robin Murphy, will, joro, thunder.leizhen, tglx, john.garry,
jean-philippe, christophe.jaillet, linux-arm-kernel, iommu,
linux-kernel
In-Reply-To: <20220419200233.GN64706@ziepe.ca>
On Tue, Apr 19, 2022 at 05:02:33PM -0300, Jason Gunthorpe wrote:
> > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > index d816759a6bcf..e280568bb513 100644
> > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> > @@ -183,7 +183,7 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
> > {
> > struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn);
> > struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
> > - size_t size = end - start + 1;
> > + size_t size = end - start;
>
> +1 to this bug fix. You should send a formal patch for stable with a fixes/etc
>
> mmu notifiers uses 'end' not 'last' in alignment with how VMA's work:
>
> include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address
Thanks for the review!
Yea, I will send a new patch.
Nic
_______________________________________________
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] iommu/arm-smmu-v3: Align size in __arm_smmu_tlb_inv_range
From: Robin Murphy @ 2022-04-19 20:15 UTC (permalink / raw)
To: Nicolin Chen, Jason Gunthorpe
Cc: will, joro, thunder.leizhen, tglx, john.garry, jean-philippe,
christophe.jaillet, linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <Yl8WF9R7tubSgREw@Asurada-Nvidia>
On 2022-04-19 21:05, Nicolin Chen wrote:
> On Tue, Apr 19, 2022 at 05:02:33PM -0300, Jason Gunthorpe wrote:
>
>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
>>> index d816759a6bcf..e280568bb513 100644
>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
>>> @@ -183,7 +183,7 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
>>> {
>>> struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn);
>>> struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
>>> - size_t size = end - start + 1;
>>> + size_t size = end - start;
>>
>> +1 to this bug fix. You should send a formal patch for stable with a fixes/etc
>>
>> mmu notifiers uses 'end' not 'last' in alignment with how VMA's work:
>>
>> include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address
>
> Thanks for the review!
>
> Yea, I will send a new patch.
Yup, +1 from me too - this is exactly the kind of thing I suspected -
and I reckon it might even be worth a comment in the code here that mm's
"end" is an exclusive limit, to help us remember in future. If there
doesn't look to be any way for completely arbitrarily-aligned addresses
to slip through then I'd be tempted to leave it at that (i.e. reason
that if the infinite loop can only happen due to catastrophic failure
then it's beyond the scope of things that are worth trying to mitigate),
but I'll let Jean and Will have the final say there.
Cheers,
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 4/4] selftests/arm64: Fix O= builds for the floating point tests
From: Mark Brown @ 2022-04-19 20:04 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Shuah Khan, Shuah Khan
Cc: linux-arm-kernel, linux-kselftest, Mark Brown
In-Reply-To: <20220419200442.1374548-1-broonie@kernel.org>
Currently the arm64 floating point tests don't support out of tree builds
due to two quirks of the kselftest build system. One is that when building
a program from multiple files we shouldn't separately compile the main
program to an object file as that will result in the pattern rule not
matching when adjusted for the output directory. The other is that we also
need to include $(OUTPUT) in the names of the binaries when specifying the
dependencies in order to ensure that they get picked up with O=.
Rewrite the dependencies for the executables to fix these issues. The
kselftest build system will ensure OUTPUT is always defined.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/arm64/fp/Makefile | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/arm64/fp/Makefile b/tools/testing/selftests/arm64/fp/Makefile
index 927b1e83f469..45bbbf1c5b97 100644
--- a/tools/testing/selftests/arm64/fp/Makefile
+++ b/tools/testing/selftests/arm64/fp/Makefile
@@ -14,16 +14,16 @@ TEST_PROGS_EXTENDED := fpsimd-stress sve-stress
EXTRA_CLEAN += $(OUTPUT)/asm-utils.o $(OUTPUT)/rdvl.o
-fp-pidbench: fp-pidbench.S asm-utils.o
+$(OUTPUT)/fp-pidbench: fp-pidbench.S asm-utils.o
$(CC) -nostdlib $^ -o $@
-fpsimd-test: fpsimd-test.o asm-utils.o
+$(OUTPUT)/fpsimd-test: fpsimd-test.S asm-utils.o
$(CC) -nostdlib $^ -o $@
-rdvl-sve: rdvl-sve.o rdvl.o
-sve-ptrace: sve-ptrace.o
-sve-probe-vls: sve-probe-vls.o rdvl.o
-sve-test: sve-test.o asm-utils.o
+$(OUTPUT)/rdvl-sve: rdvl-sve.c rdvl.o
+$(OUTPUT)/sve-ptrace: sve-ptrace.c
+$(OUTPUT)/sve-probe-vls: sve-probe-vls.c rdvl.o
+$(OUTPUT)/sve-test: sve-test.S asm-utils.o
$(CC) -nostdlib $^ -o $@
-vec-syscfg: vec-syscfg.o rdvl.o
-vlset: vlset.o
+$(OUTPUT)/vec-syscfg: vec-syscfg.c rdvl.o
+$(OUTPUT)/vlset: vlset.c
include ../../lib.mk
--
2.30.2
_______________________________________________
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 v2 3/4] selftests/arm64: Clean the fp helper libraries
From: Mark Brown @ 2022-04-19 20:04 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Shuah Khan, Shuah Khan
Cc: linux-arm-kernel, linux-kselftest, Mark Brown
In-Reply-To: <20220419200442.1374548-1-broonie@kernel.org>
We provide a couple of object files with helpers linked into several of
the test programs, ensure they are cleaned.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/arm64/fp/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/arm64/fp/Makefile b/tools/testing/selftests/arm64/fp/Makefile
index 41b420050765..927b1e83f469 100644
--- a/tools/testing/selftests/arm64/fp/Makefile
+++ b/tools/testing/selftests/arm64/fp/Makefile
@@ -12,6 +12,8 @@ TEST_GEN_PROGS_EXTENDED := fp-pidbench fpsimd-test \
vlset
TEST_PROGS_EXTENDED := fpsimd-stress sve-stress
+EXTRA_CLEAN += $(OUTPUT)/asm-utils.o $(OUTPUT)/rdvl.o
+
fp-pidbench: fp-pidbench.S asm-utils.o
$(CC) -nostdlib $^ -o $@
fpsimd-test: fpsimd-test.o asm-utils.o
--
2.30.2
_______________________________________________
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 v2 1/4] selftests/arm64: Use TEST_GEN_PROGS_EXTENDED in the FP Makefile
From: Mark Brown @ 2022-04-19 20:04 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Shuah Khan, Shuah Khan
Cc: linux-arm-kernel, linux-kselftest, Mark Brown
In-Reply-To: <20220419200442.1374548-1-broonie@kernel.org>
The kselftest lib.mk provides a default all target which builds additional
programs from TEST_GEN_PROGS_EXTENDED, use that rather than using
TEST_PROGS_EXTENDED which is for programs that don't need to be built like
shell scripts. Leave fpsimd-stress and sve-stress there since they are
scripts.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/arm64/fp/Makefile | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/arm64/fp/Makefile b/tools/testing/selftests/arm64/fp/Makefile
index 95f0b877a060..774c38cee317 100644
--- a/tools/testing/selftests/arm64/fp/Makefile
+++ b/tools/testing/selftests/arm64/fp/Makefile
@@ -2,12 +2,11 @@
CFLAGS += -I../../../../../usr/include/
TEST_GEN_PROGS := sve-ptrace sve-probe-vls vec-syscfg
-TEST_PROGS_EXTENDED := fp-pidbench fpsimd-test fpsimd-stress \
+TEST_GEN_PROGS_EXTENDED := fp-pidbench fpsimd-test \
rdvl-sve \
- sve-test sve-stress \
+ sve-test \
vlset
-
-all: $(TEST_GEN_PROGS) $(TEST_PROGS_EXTENDED)
+TEST_PROGS_EXTENDED := fpsimd-stress sve-stress
fp-pidbench: fp-pidbench.S asm-utils.o
$(CC) -nostdlib $^ -o $@
--
2.30.2
_______________________________________________
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 v2 2/4] selftests/arm64: Define top_srcdir for the fp tests
From: Mark Brown @ 2022-04-19 20:04 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Shuah Khan, Shuah Khan
Cc: linux-arm-kernel, linux-kselftest, Mark Brown
In-Reply-To: <20220419200442.1374548-1-broonie@kernel.org>
Some of the rules in lib.mk use a top_srcdir variable to figure out where
the top of the kselftest tree is, provide it.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/arm64/fp/Makefile | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/fp/Makefile b/tools/testing/selftests/arm64/fp/Makefile
index 774c38cee317..41b420050765 100644
--- a/tools/testing/selftests/arm64/fp/Makefile
+++ b/tools/testing/selftests/arm64/fp/Makefile
@@ -1,6 +1,10 @@
# SPDX-License-Identifier: GPL-2.0
-CFLAGS += -I../../../../../usr/include/
+# A proper top_srcdir is needed by KSFT(lib.mk)
+top_srcdir = $(realpath ../../../../../)
+
+CFLAGS += -I$(top_srcdir)/usr/include/
+
TEST_GEN_PROGS := sve-ptrace sve-probe-vls vec-syscfg
TEST_GEN_PROGS_EXTENDED := fp-pidbench fpsimd-test \
rdvl-sve \
--
2.30.2
_______________________________________________
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 v2 0/4] selftests/arm64: Fix O= builds for the FP selftests
From: Mark Brown @ 2022-04-19 20:04 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Shuah Khan, Shuah Khan
Cc: linux-arm-kernel, linux-kselftest, Mark Brown
Currently the arm64 selftests don't support building with O=, this
series fixes that, bringing them more into line with how the kselftest
Makefiles want to work.
v2:
- Rebase onto v5.18-rc3.
Mark Brown (4):
selftests/arm64: Use TEST_GEN_PROGS_EXTENDED in the FP Makefile
selftests/arm64: Define top_srcdir for the fp tests
selftests/arm64: Clean the fp helper libraries
selftests/arm64: Fix O= builds for the floating point tests
tools/testing/selftests/arm64/fp/Makefile | 29 +++++++++++++----------
1 file changed, 17 insertions(+), 12 deletions(-)
base-commit: b2d229d4ddb17db541098b83524d901257e93845
--
2.30.2
_______________________________________________
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] iommu/arm-smmu-v3: Align size in __arm_smmu_tlb_inv_range
From: Jason Gunthorpe @ 2022-04-19 20:02 UTC (permalink / raw)
To: Nicolin Chen
Cc: Robin Murphy, will, joro, thunder.leizhen, tglx, john.garry,
jean-philippe, christophe.jaillet, linux-arm-kernel, iommu,
linux-kernel
In-Reply-To: <Yloj6GM+yykImKvp@Asurada-Nvidia>
On Fri, Apr 15, 2022 at 07:03:20PM -0700, Nicolin Chen wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index d816759a6bcf..e280568bb513 100644
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -183,7 +183,7 @@ static void arm_smmu_mm_invalidate_range(struct mmu_notifier *mn,
> {
> struct arm_smmu_mmu_notifier *smmu_mn = mn_to_smmu(mn);
> struct arm_smmu_domain *smmu_domain = smmu_mn->domain;
> - size_t size = end - start + 1;
> + size_t size = end - start;
+1 to this bug fix. You should send a formal patch for stable with a fixes/etc
mmu notifiers uses 'end' not 'last' in alignment with how VMA's work:
include/linux/mm_types.h: unsigned long vm_end; /* The first byte after our end address
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
From: Krzysztof Kozlowski @ 2022-04-19 19:43 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Frank Wunderlich, linux-rockchip, Kishon Vijay Abraham I,
Vinod Koul, Rob Herring, Krzysztof Kozlowski, Heiko Stuebner,
Lorenzo Pieralisi, Krzysztof Wilczyński, Bjorn Helgaas,
Philipp Zabel, Johan Jonker, Peter Geis, Michael Riesch,
linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-pci
In-Reply-To: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70>
On 19/04/2022 19:49, Frank Wunderlich wrote:
>> The list should be strictly ordered (defined), so:
>> items:
>> - const: ...
>> - const: ...
>> - const: ...
>> minItems: 1
>>
>> However the question is - why the clocks have different amount? Is it
>> per different SoC implementation?
>
> i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
>
> not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).
You can skip RK3588 compatible or define it this strictly also for that
chip.
>
>>> +
>>> + "#phy-cells":
>>> + const: 0
>>> +
>>> + resets:
>>> + maxItems: 1
>>> +
>>> + reset-names:
>>> + const: phy
>>> +
>>> + rockchip,phy-grf:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: phandle to the syscon managing the phy "general register files"
>>> +
>>> + rockchip,pipe-grf:
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> + description: phandle to the syscon managing the pipe "general register files"
>>> +
>>> + rockchip,pcie30-phymode:
>>> + $ref: '/schemas/types.yaml#/definitions/uint32'
>>> + description: |
>>> + use PHY_MODE_PCIE_AGGREGATION if not defined
>>
>> I don't understand the description. Do you mean here a case when the
>> variable is missing?
>
> yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4
Then just use "default: 4"
>
>>> + minimum: 0x0
>>> + maximum: 0x4
>>
>> Please explain these values. Register values should not be part of
>> bindings, but instead some logical behavior of hardware or its logic.
>
> it's a bitmask, so maybe
>
> description: |
> bit0: bifurcation for port 0
> bit1: bifurcation for port 1
> bit2: aggregation
That's good. I got impression you have a header with these values. If
yes - mention it here.
> use PHY_MODE_PCIE_AGGREGATION (4) as default
Just use default as I wrote above.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Aw: Re: [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf
From: Krzysztof Kozlowski @ 2022-04-19 19:40 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Frank Wunderlich, linux-rockchip, Kishon Vijay Abraham I,
Vinod Koul, Rob Herring, Krzysztof Kozlowski, Heiko Stuebner,
Lorenzo Pieralisi, Krzysztof Wilczyński, Bjorn Helgaas,
Philipp Zabel, Johan Jonker, Peter Geis, Michael Riesch,
linux-phy, devicetree, linux-arm-kernel, linux-kernel, linux-pci
In-Reply-To: <trinity-c60358c4-ebd1-47bf-91e0-9ae0beefd39f-1650389348418@3c-app-gmx-bap70>
On 19/04/2022 19:29, Frank Wunderlich wrote:
>> Gesendet: Montag, 18. April 2022 um 17:54 Uhr
>> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
>
>>> --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml
>>> @@ -14,6 +14,8 @@ properties:
>>> oneOf:
>>> - items:
>>> - enum:
>>> + - rockchip,pcie30-phy-grf
>>> + - rockchip,pcie30-pipe-grf
>>
>> These are without SoC parts. Are these PCIe v3 General Register Files
>> part of some PCIe spec?
>
> imho they are shared across SoCs rk3568 and rk3588, but have only seen rk3568 implementation yet.
> PCIe driver currently supports these 2 Soc (different offsets in the Phy-GRF), but can only test rk3568.
>
> pipe-grf seems only be used for rk35688 (offset used in probe is defined for this SoC), which i cannot test.
>
> so i have left them SoC independed.
Compatibles should be SoC dependent, with some exceptions. Lack of
documentation or lack of possibility of testing is actually argument
against any exception, so they should be SoC specific/dependent.
Best regards,
Krzysztof
_______________________________________________
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 v2 1/5] dt-bindings: arm: add bcmbca device tree binding document
From: William Zhang @ 2022-04-19 19:29 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-arm-kernel
Cc: Broadcom Kernel List, Kursad Oney, Joel Peshkin, Anand Gore,
Dan Beygelman, Florian Fainelli, Krzysztof Kozlowski, Rob Herring,
devicetree, linux-kernel
In-Reply-To: <63aad869-ec0c-58cf-55a9-6739f6e3e3e5@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 500 bytes --]
On 4/17/22 11:13, Krzysztof Kozlowski wrote:
> On 14/04/2022 19:38, William Zhang wrote:
>> Hi Krzysztof,
>>
>> Yeah I saw your ack. I guess I should put an ack-by in this v2 set?
>> Still new to the upstream process and thanks for your help!
>
> Yes, please add all tags before your Signed-off-by part.
> https://elixir.bootlin.com/linux/v5.18-rc2/source/Documentation/process/submitting-patches.rst#L541
>
>
Will add Acked-by: and Reviewed-by: tag in v3. Thanks!
> Best regards,
> Krzysztof
[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4212 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 09/48] watchdog: sa1100: use platform device registration
From: Guenter Roeck @ 2022-04-19 19:19 UTC (permalink / raw)
To: Arnd Bergmann, robert.jarzmik, linux-arm-kernel
Cc: Arnd Bergmann, Daniel Mack, Haojian Zhuang, Marek Vasut,
Philipp Zabel, Lubomir Rintel, Paul Parsons, Tomas Cech,
Sergey Lapin, Thomas Bogendoerfer, Michael Turquette,
Stephen Boyd, Rafael J. Wysocki, Viresh Kumar, Dmitry Torokhov,
Ulf Hansson, Dominik Brodowski, Helge Deller, Mark Brown,
Linus Walleij, linux-kernel, linux-mips, linux-ide, linux-clk,
linux-pm, linux-input, patches, linux-leds, linux-mmc, linux-mtd,
linux-rtc, linux-usb, linux-fbdev, dri-devel, alsa-devel,
Wim Van Sebroeck, linux-watchdog
In-Reply-To: <20220419163810.2118169-10-arnd@kernel.org>
On 4/19/22 09:37, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Rather than relying on machine specific headers to
> pass down the reboot status and the register locations,
> use resources and platform_data.
>
> Aside from this, keep the changes to a minimum.
>
> Cc: Wim Van Sebroeck <wim@linux-watchdog.org>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: linux-watchdog@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
> ---
> arch/arm/mach-pxa/devices.c | 11 +++
> arch/arm/mach-pxa/include/mach/regs-ost.h | 2 +
> arch/arm/mach-pxa/include/mach/reset.h | 2 +-
> arch/arm/mach-pxa/pxa25x.c | 2 +-
> arch/arm/mach-pxa/pxa27x.c | 2 +-
> arch/arm/mach-pxa/pxa3xx.c | 2 +-
> arch/arm/mach-pxa/reset.c | 3 -
> arch/arm/mach-sa1100/generic.c | 6 +-
> arch/arm/mach-sa1100/include/mach/reset.h | 1 -
> drivers/watchdog/sa1100_wdt.c | 87 ++++++++++++++++-------
> 10 files changed, 83 insertions(+), 35 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
> index 454523237c97..12f78636045f 100644
> --- a/arch/arm/mach-pxa/devices.c
> +++ b/arch/arm/mach-pxa/devices.c
> @@ -24,6 +24,8 @@
> #include <linux/platform_data/mmp_dma.h>
> #include <linux/platform_data/mtd-nand-pxa3xx.h>
>
> +#include <mach/regs-ost.h>
> +#include <mach/reset.h>
> #include "devices.h"
> #include "generic.h"
>
> @@ -1118,3 +1120,12 @@ void __init pxa2xx_set_dmac_info(struct mmp_dma_platdata *dma_pdata)
> {
> pxa_register_device(&pxa2xx_pxa_dma, dma_pdata);
> }
> +
> +void __init pxa_register_wdt(unsigned int reset_status)
> +{
> + struct resource res = DEFINE_RES_MEM(OST_PHYS, OST_LEN);
> +
> + reset_status &= RESET_STATUS_WATCHDOG;
> + platform_device_register_resndata(NULL, "sa1100_wdt", -1, &res, 1,
> + &reset_status, sizeof(reset_status));
> +}
> diff --git a/arch/arm/mach-pxa/include/mach/regs-ost.h b/arch/arm/mach-pxa/include/mach/regs-ost.h
> index 109d0ed264df..c8001cfc8d6b 100644
> --- a/arch/arm/mach-pxa/include/mach/regs-ost.h
> +++ b/arch/arm/mach-pxa/include/mach/regs-ost.h
> @@ -7,6 +7,8 @@
> /*
> * OS Timer & Match Registers
> */
> +#define OST_PHYS 0x40A00000
> +#define OST_LEN 0x00000020
>
> #define OSMR0 io_p2v(0x40A00000) /* */
> #define OSMR1 io_p2v(0x40A00004) /* */
> diff --git a/arch/arm/mach-pxa/include/mach/reset.h b/arch/arm/mach-pxa/include/mach/reset.h
> index e1c4d100fd45..963dd190bc13 100644
> --- a/arch/arm/mach-pxa/include/mach/reset.h
> +++ b/arch/arm/mach-pxa/include/mach/reset.h
> @@ -8,8 +8,8 @@
> #define RESET_STATUS_GPIO (1 << 3) /* GPIO Reset */
> #define RESET_STATUS_ALL (0xf)
>
> -extern unsigned int reset_status;
> extern void clear_reset_status(unsigned int mask);
> +extern void pxa_register_wdt(unsigned int reset_status);
>
> /**
> * init_gpio_reset() - register GPIO as reset generator
> diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
> index 305047ebd2f1..dfc90b41fba3 100644
> --- a/arch/arm/mach-pxa/pxa25x.c
> +++ b/arch/arm/mach-pxa/pxa25x.c
> @@ -240,7 +240,7 @@ static int __init pxa25x_init(void)
>
> if (cpu_is_pxa25x()) {
>
> - reset_status = RCSR;
> + pxa_register_wdt(RCSR);
>
> pxa25x_init_pm();
>
> diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
> index a81ac88ecbfd..38fdd22c4dc5 100644
> --- a/arch/arm/mach-pxa/pxa27x.c
> +++ b/arch/arm/mach-pxa/pxa27x.c
> @@ -337,7 +337,7 @@ static int __init pxa27x_init(void)
>
> if (cpu_is_pxa27x()) {
>
> - reset_status = RCSR;
> + pxa_register_wdt(RCSR);
>
> pxa27x_init_pm();
>
> diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
> index fc84aed99481..7c569fa2a6da 100644
> --- a/arch/arm/mach-pxa/pxa3xx.c
> +++ b/arch/arm/mach-pxa/pxa3xx.c
> @@ -463,7 +463,7 @@ static int __init pxa3xx_init(void)
>
> if (cpu_is_pxa3xx()) {
>
> - reset_status = ARSR;
> + pxa_register_wdt(ARSR);
>
> /*
> * clear RDH bit every time after reset
> diff --git a/arch/arm/mach-pxa/reset.c b/arch/arm/mach-pxa/reset.c
> index af78405aa4e9..fcb791c5ae3e 100644
> --- a/arch/arm/mach-pxa/reset.c
> +++ b/arch/arm/mach-pxa/reset.c
> @@ -11,9 +11,6 @@
> #include <mach/reset.h>
> #include <mach/smemc.h>
>
> -unsigned int reset_status;
> -EXPORT_SYMBOL(reset_status);
> -
> static void do_hw_reset(void);
>
> static int reset_gpio = -1;
> diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
> index 4dfb7554649d..6c21f214cd60 100644
> --- a/arch/arm/mach-sa1100/generic.c
> +++ b/arch/arm/mach-sa1100/generic.c
> @@ -39,9 +39,6 @@
> #include "generic.h"
> #include <clocksource/pxa.h>
>
> -unsigned int reset_status;
> -EXPORT_SYMBOL(reset_status);
> -
> #define NR_FREQS 16
>
> /*
> @@ -319,10 +316,13 @@ static struct platform_device *sa11x0_devices[] __initdata = {
>
> static int __init sa1100_init(void)
> {
> + struct resource wdt_res = DEFINE_RES_MEM(0x90000000, 0x20);
> pm_power_off = sa1100_power_off;
>
> regulator_has_full_constraints();
>
> + platform_device_register_simple("sa1100_wdt", -1, &wdt_res, 1);
> +
> return platform_add_devices(sa11x0_devices, ARRAY_SIZE(sa11x0_devices));
> }
>
> diff --git a/arch/arm/mach-sa1100/include/mach/reset.h b/arch/arm/mach-sa1100/include/mach/reset.h
> index 27695650a567..a6723d45ae2a 100644
> --- a/arch/arm/mach-sa1100/include/mach/reset.h
> +++ b/arch/arm/mach-sa1100/include/mach/reset.h
> @@ -10,7 +10,6 @@
> #define RESET_STATUS_GPIO (1 << 3) /* GPIO Reset */
> #define RESET_STATUS_ALL (0xf)
>
> -extern unsigned int reset_status;
> static inline void clear_reset_status(unsigned int mask)
> {
> RCSR = mask;
> diff --git a/drivers/watchdog/sa1100_wdt.c b/drivers/watchdog/sa1100_wdt.c
> index d33f0375112f..2d0a06a158a8 100644
> --- a/drivers/watchdog/sa1100_wdt.c
> +++ b/drivers/watchdog/sa1100_wdt.c
> @@ -22,6 +22,7 @@
> #include <linux/types.h>
> #include <linux/kernel.h>
> #include <linux/fs.h>
> +#include <linux/platform_device.h>
> #include <linux/miscdevice.h>
> #include <linux/watchdog.h>
> #include <linux/init.h>
> @@ -30,16 +31,42 @@
> #include <linux/uaccess.h>
> #include <linux/timex.h>
>
> -#ifdef CONFIG_ARCH_PXA
> -#include <mach/regs-ost.h>
> -#endif
> +#define REG_OSMR0 0x0000 /* OS timer Match Reg. 0 */
> +#define REG_OSMR1 0x0004 /* OS timer Match Reg. 1 */
> +#define REG_OSMR2 0x0008 /* OS timer Match Reg. 2 */
> +#define REG_OSMR3 0x000c /* OS timer Match Reg. 3 */
> +#define REG_OSCR 0x0010 /* OS timer Counter Reg. */
> +#define REG_OSSR 0x0014 /* OS timer Status Reg. */
> +#define REG_OWER 0x0018 /* OS timer Watch-dog Enable Reg. */
> +#define REG_OIER 0x001C /* OS timer Interrupt Enable Reg. */
>
> -#include <mach/reset.h>
> +#define OSSR_M3 (1 << 3) /* Match status channel 3 */
> +#define OSSR_M2 (1 << 2) /* Match status channel 2 */
> +#define OSSR_M1 (1 << 1) /* Match status channel 1 */
> +#define OSSR_M0 (1 << 0) /* Match status channel 0 */
> +
> +#define OWER_WME (1 << 0) /* Watchdog Match Enable */
> +
> +#define OIER_E3 (1 << 3) /* Interrupt enable channel 3 */
> +#define OIER_E2 (1 << 2) /* Interrupt enable channel 2 */
> +#define OIER_E1 (1 << 1) /* Interrupt enable channel 1 */
> +#define OIER_E0 (1 << 0) /* Interrupt enable channel 0 */
>
> static unsigned long oscr_freq;
> static unsigned long sa1100wdt_users;
> static unsigned int pre_margin;
> static int boot_status;
> +static void __iomem *reg_base;
> +
> +static inline void sa1100_wr(u32 val, u32 offset)
> +{
> + writel_relaxed(val, reg_base + offset);
> +}
> +
> +static inline u32 sa1100_rd(u32 offset)
> +{
> + return readl_relaxed(reg_base + offset);
> +}
>
> /*
> * Allow only one person to hold it open
> @@ -50,10 +77,10 @@ static int sa1100dog_open(struct inode *inode, struct file *file)
> return -EBUSY;
>
> /* Activate SA1100 Watchdog timer */
> - writel_relaxed(readl_relaxed(OSCR) + pre_margin, OSMR3);
> - writel_relaxed(OSSR_M3, OSSR);
> - writel_relaxed(OWER_WME, OWER);
> - writel_relaxed(readl_relaxed(OIER) | OIER_E3, OIER);
> + sa1100_wr(sa1100_rd(REG_OSCR) + pre_margin, REG_OSMR3);
> + sa1100_wr(OSSR_M3, REG_OSSR);
> + sa1100_wr(OWER_WME, REG_OWER);
> + sa1100_wr(sa1100_rd(REG_OIER) | OIER_E3, REG_OIER);
> return stream_open(inode, file);
> }
>
> @@ -61,7 +88,7 @@ static int sa1100dog_open(struct inode *inode, struct file *file)
> * The watchdog cannot be disabled.
> *
> * Previous comments suggested that turning off the interrupt by
> - * clearing OIER[E3] would prevent the watchdog timing out but this
> + * clearing REG_OIER[E3] would prevent the watchdog timing out but this
> * does not appear to be true (at least on the PXA255).
> */
> static int sa1100dog_release(struct inode *inode, struct file *file)
> @@ -76,7 +103,7 @@ static ssize_t sa1100dog_write(struct file *file, const char __user *data,
> {
> if (len)
> /* Refresh OSMR3 timer. */
> - writel_relaxed(readl_relaxed(OSCR) + pre_margin, OSMR3);
> + sa1100_wr(sa1100_rd(REG_OSCR) + pre_margin, REG_OSMR3);
> return len;
> }
>
> @@ -110,7 +137,7 @@ static long sa1100dog_ioctl(struct file *file, unsigned int cmd,
> break;
>
> case WDIOC_KEEPALIVE:
> - writel_relaxed(readl_relaxed(OSCR) + pre_margin, OSMR3);
> + sa1100_wr(sa1100_rd(REG_OSCR) + pre_margin, REG_OSMR3);
> ret = 0;
> break;
>
> @@ -125,7 +152,7 @@ static long sa1100dog_ioctl(struct file *file, unsigned int cmd,
> }
>
> pre_margin = oscr_freq * time;
> - writel_relaxed(readl_relaxed(OSCR) + pre_margin, OSMR3);
> + sa1100_wr(sa1100_rd(REG_OSCR) + pre_margin, REG_OSMR3);
> fallthrough;
>
> case WDIOC_GETTIMEOUT:
> @@ -151,12 +178,22 @@ static struct miscdevice sa1100dog_miscdev = {
> .fops = &sa1100dog_fops,
> };
>
> -static int margin __initdata = 60; /* (secs) Default is 1 minute */
> +static int margin = 60; /* (secs) Default is 1 minute */
> static struct clk *clk;
>
> -static int __init sa1100dog_init(void)
> +static int sa1100dog_probe(struct platform_device *pdev)
> {
> int ret;
> + int *platform_data;
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENXIO;
> + reg_base = devm_ioremap(&pdev->dev, res->start, resource_size(res));
> + ret = PTR_ERR_OR_ZERO(reg_base);
> + if (ret)
> + return ret;
>
> clk = clk_get(NULL, "OSTIMER0");
> if (IS_ERR(clk)) {
> @@ -174,13 +211,9 @@ static int __init sa1100dog_init(void)
>
> oscr_freq = clk_get_rate(clk);
>
> - /*
> - * Read the reset status, and save it for later. If
> - * we suspend, RCSR will be cleared, and the watchdog
> - * reset reason will be lost.
> - */
> - boot_status = (reset_status & RESET_STATUS_WATCHDOG) ?
> - WDIOF_CARDRESET : 0;
> + platform_data = pdev->dev.platform_data;
> + if (platform_data && *platform_data)
> + boot_status = WDIOF_CARDRESET;
> pre_margin = oscr_freq * margin;
>
> ret = misc_register(&sa1100dog_miscdev);
> @@ -196,15 +229,21 @@ static int __init sa1100dog_init(void)
> return ret;
> }
>
> -static void __exit sa1100dog_exit(void)
> +static int sa1100dog_remove(struct platform_device *pdev)
> {
> misc_deregister(&sa1100dog_miscdev);
> clk_disable_unprepare(clk);
> clk_put(clk);
> +
> + return 0;
> }
>
> -module_init(sa1100dog_init);
> -module_exit(sa1100dog_exit);
> +struct platform_driver sa1100dog_driver = {
> + .driver.name = "sa1100_wdt",
> + .probe = sa1100dog_probe,
> + .remove = sa1100dog_remove,
> +};
> +module_platform_driver(sa1100dog_driver);
>
> MODULE_AUTHOR("Oleg Drokin <green@crimea.edu>");
> MODULE_DESCRIPTION("SA1100/PXA2xx Watchdog");
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v7 net-next 10/13] mfd: ocelot: add support for the vsc7512 chip via spi
From: Colin Foster @ 2022-04-20 2:13 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-gpio, linux-phy, netdev, linux-kernel,
Rafael J. Wysocki, Marc Zyngier, Hector Martin, Angela Czubak,
Steen Hegelund, Lars Povlsen, Linus Walleij, Vinod Koul,
Kishon Vijay Abraham I, Russell King, Heiner Kallweit,
Jakub Kicinski, David S. Miller, Florian Fainelli, Vivien Didelot,
Andrew Lunn, UNGLinuxDriver, Alexandre Belloni, Claudiu Manoil,
Vladimir Oltean, katie.morris
In-Reply-To: <Yl57uP+rsl/bsI4i@google.com>
Thanks for the feedback Lee,
I'll do some final cleanup (hopefully this month...?) and prepare
another patch set.
Something I plan to do, lest anyone object, is send the next patch set
that explicitly states that ports 4-10 currently aren't supported, and
inform a user as such. One main reason for this is that the additional
ports rely on the drivers/phy/mscc/phy-ocelot-serdes driver, which
utilizes syscon_node_to_regmap. The same issue comes up, where syscon of
course only supports mmio. I can foresee that being worthy of its own
rounds of reviews, and will change the .
But I'm quite new to this process - so if that isn't an acceptable path
forward I understand.
On Tue, Apr 19, 2022 at 10:07:04AM +0100, Lee Jones wrote:
> [Adding everyone/lists back on Cc]
Oops... I'm not sure how I did that. Thanks!
>
> On Thu, 14 Apr 2022, Colin Foster wrote:
>
> > Hi Lee,
> >
> > Thanks for the feedback. I agree with (and have made) your suggestions.
> > Additional comments below.
>
> I'm swamped right now, so I cannot do a full re-review, but please see
> in-line for a couple of (most likely flippant i.e. not fully
> thought out comments).
>
> Please submit the changes you end up making off the back of this
> review and I'll conduct another on the next version you send.
>
> > On Wed, Apr 13, 2022 at 09:32:22AM +0100, Lee Jones wrote:
> > > On Sun, 06 Mar 2022, Colin Foster wrote:
> > >
> > [...]
> > > > +
> > > > +int ocelot_core_init(struct ocelot_core *core)
> > > > +{
> > > > + struct device *dev = core->dev;
> > > > + int ret;
> > > > +
> > > > + dev_set_drvdata(dev, core);
> > > > +
> > > > + core->gcb_regmap = ocelot_devm_regmap_init(core, dev,
> > > > + &vsc7512_gcb_resource);
> > >
> > > This just ends up calling ocelot_spi_devm_get_regmap() right?
> > >
> > > Why not call that from inside ocelot-spi.c where 'core' was allocated?
> >
> > core->gcb_regmap doesn't handle anything more than chip reset. This will
> > have to happen regardless of the interface.
> >
> > The "spi" part uses the core->cpuorg_regmap, which is needed for
> > configuring the SPI bus. In the case of I2C, this cpu_org regmap
> > (likely?) wouldn't be necessary, but the gcb_regmap absolutely would.
> > That's why gcb is allocated in core and cpuorg is allocated in SPI.
> >
> > The previous RFC had cpuorg_regmap hidden inside a private struct to
> > emphasize this separation. As you pointed out, there was a lot of
> > bouncing between "core" structs and "spi" structs that got ugly.
> >
> > (Looking at this more now... the value of cpuorg_regmap should have been
> > in the CONFIG_MFD_OCELOT_SPI ifdef, which might have made this
> > distinction more clear)
>
> The TL;DR of my review point would be to make this as simple as
> possible. If you can call a single function, instead of needlessly
> sending the thread of execution through three, please do.
>
> > > > + if (IS_ERR(core->gcb_regmap))
> > > > + return -ENOMEM;
> > > > +
> > > > + ret = ocelot_reset(core);
> > > > + if (ret) {
> > > > + dev_err(dev, "Failed to reset device: %d\n", ret);
> > > > + return ret;
> > > > + }
> > > > +
> > > > + /*
> > > > + * A chip reset will clear the SPI configuration, so it needs to be done
> > > > + * again before we can access any registers
> > > > + */
> > > > + ret = ocelot_spi_initialize(core);
> > >
> > > Not a fan of calling back into the file which called us.
> > >
> > > And what happens if SPI isn't controlling us?
> > >
> > > Doesn't the documentation above say this device can also be
> > > communicated with via I2C and PCIe?
> >
> > During the last RFC this was done through a callback. You had requested
> > I not use callbacks.
> >
> > From that exchange:
> > """"
> > > > > + ret = core->config->init_bus(core->config);
> > > >
> > > > You're not writing a bus. I doubt you need ops call-backs.
> > >
> > > In the case of SPI, the chip needs to be configured both before and
> > > after reset. It sets up the bus for endianness, padding bytes, etc. This
> > > is currently achieved by running "ocelot_spi_init_bus" once during SPI
> > > probe, and once immediately after chip reset.
> > >
> > > For other control mediums I doubt this is necessary. Perhaps "init_bus"
> > > is a misnomer in this scenario...
> >
> > Please find a clearer way to do this without function pointers.
> > """"
>
> Yes, I remember.
>
> This is an improvement on that, but it doesn't mean it's ideal.
>
> > The idea is that we set up the SPI bus so we can read registers. The
> > protocol changes based on bus speed, so this is necessary.
> >
> > This initial setup is done in ocelot-spi.c, before ocelot_core_init is
> > called.
> >
> > We then reset the chip by writing some registers. This chip reset also
> > clears the SPI configuration, so we need to reconfigure the SPI bus
> > before we can read any additional registers.
> >
> > Short of using function pointers, I imagine this will have to be
> > something akin to:
> >
> > if (core->is_spi) {
> > ocelot_spi_initalize();
> > }
>
> What about if, instead of calling from SPI into Core, which calls back
> into SPI again, you do this from SPI instead:
>
> [flippant - I haven't fully assessed the viability of this suggestion]
>
> foo_type spi_probe(bar_type baz)
> {
> setup_spi();
>
> core_init();
>
> more_spi_stuff();
> }
>
> > I feel if the additional buses are added, they'll have to implement this
> > type of change. But as I don't (and don't plan to) have hardware to
> > build those interfaces out, right now ocelot_core assumes the bus is
> > SPI.
>
> What are the chances of someone else coming along and implementing the
> other interfaces? You might very well be over-complicating this
> implementation for support that may never be required.
I had one person email me about this already, though I understand they
went another direction.
But I could see this back-and-forth going away. I'll take another look
at it and try to clean it up a little more.
>
> > > > + if (ret) {
> > > > + dev_err(dev, "Failed to initialize SPI interface: %d\n", ret);
> > > > + return ret;
> > > > + }
> > > > +
> > > > + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, vsc7512_devs,
> > > > + ARRAY_SIZE(vsc7512_devs), NULL, 0, NULL);
> > > > + if (ret) {
> > > > + dev_err(dev, "Failed to add sub-devices: %d\n", ret);
> > > > + return ret;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(ocelot_core_init);
> > > > +
> > > > +MODULE_DESCRIPTION("Externally Controlled Ocelot Chip Driver");
> > > > +MODULE_AUTHOR("Colin Foster <colin.foster@in-advantage.com>");
> > > > +MODULE_LICENSE("GPL v2");
> > > > diff --git a/drivers/mfd/ocelot-spi.c b/drivers/mfd/ocelot-spi.c
> > > > new file mode 100644
> > > > index 000000000000..c788e239c9a7
> > > > --- /dev/null
> > > > +++ b/drivers/mfd/ocelot-spi.c
> > > > @@ -0,0 +1,313 @@
> > > > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > > > +/*
> > > > + * SPI core driver for the Ocelot chip family.
> > > > + *
> > > > + * This driver will handle everything necessary to allow for communication over
> > > > + * SPI to the VSC7511, VSC7512, VSC7513 and VSC7514 chips. The main functions
> > > > + * are to prepare the chip's SPI interface for a specific bus speed, and a host
> > > > + * processor's endianness. This will create and distribute regmaps for any MFD
> > >
> > > As above, please drop references to MFD.
> > >
> > > > + * children.
> > > > + *
> > > > + * Copyright 2021 Innovative Advantage Inc.
> > > > + *
> > > > + * Author: Colin Foster <colin.foster@in-advantage.com>
> > > > + */
> > > > +
> > > > +#include <linux/iopoll.h>
> > > > +#include <linux/kconfig.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of.h>
> > > > +#include <linux/regmap.h>
> > > > +#include <linux/spi/spi.h>
> > > > +
> > > > +#include <asm/byteorder.h>
> > > > +
> > > > +#include "ocelot.h"
> > > > +
> > > > +#define DEV_CPUORG_IF_CTRL 0x0000
> > > > +#define DEV_CPUORG_IF_CFGSTAT 0x0004
> > > > +
> > > > +#define CFGSTAT_IF_NUM_VCORE (0 << 24)
> > > > +#define CFGSTAT_IF_NUM_VRAP (1 << 24)
> > > > +#define CFGSTAT_IF_NUM_SI (2 << 24)
> > > > +#define CFGSTAT_IF_NUM_MIIM (3 << 24)
> > > > +
> > > > +
> > > > +static const struct resource vsc7512_dev_cpuorg_resource = {
> > > > + .start = 0x71000000,
> > > > + .end = 0x710002ff,
> > >
> > > No magic numbers. Please define these addresses.
> >
> > I missed these. Thanks.
> >
> > >
> > > > + .name = "devcpu_org",
> > > > +};
> > > > +
> > > > +#define VSC7512_BYTE_ORDER_LE 0x00000000
> > > > +#define VSC7512_BYTE_ORDER_BE 0x81818181
> > > > +#define VSC7512_BIT_ORDER_MSB 0x00000000
> > > > +#define VSC7512_BIT_ORDER_LSB 0x42424242
> > > > +
> > > > +int ocelot_spi_initialize(struct ocelot_core *core)
> > > > +{
> > > > + u32 val, check;
> > > > + int err;
> > > > +
> > > > +#ifdef __LITTLE_ENDIAN
> > > > + val = VSC7512_BYTE_ORDER_LE;
> > > > +#else
> > > > + val = VSC7512_BYTE_ORDER_BE;
> > > > +#endif
> > >
> > > Not a fan of ifdefery in the middle of C files.
> > >
> > > Please create a macro or define somewhere.
> >
> > I'll clear this up in comments and move things around. This macro
> > specifically tends to lend itself to this type of ifdef dropping:
> >
> > https://elixir.bootlin.com/linux/v5.18-rc2/C/ident/__LITTLE_ENDIAN
>
> I see that the majority of implementations exist in header files as I
> would expect. With respect to the others, past acceptance and what is
> acceptable in other subsystems has little bearing on what will be
> accepted here and now.
>
> > The comment I'm adding is:
> > /*
> > * The SPI address must be big-endian, but we want the payload to match
> > * our CPU. These are two bits (0 and 1) but they're repeated such that
> > * the write from any configuration will be valid. The four
> > * configurations are:
> > *
> > * 0b00: little-endian, MSB first
> > * | 111111 | 22221111 | 33222222 |
> > * | 76543210 | 54321098 | 32109876 | 10987654 |
> > *
> > * 0b01: big-endian, MSB first
> > * | 33222222 | 22221111 | 111111 | |
> > * | 10987654 | 32109876 | 54321098 | 76543210 |
> > *
> > * 0b10: little-endian, LSB first
> > * | 111111 | 11112222 | 22222233 |
> > * | 01234567 | 89012345 | 67890123 | 45678901 |
> > *
> > * 0b11: big-endian, LSB first
> > * | 22222233 | 11112222 | 111111 | |
> > * | 45678901 | 67890123 | 89012345 | 01234567 |
> > */
> >
> > With this info, would you recommend:
> > 1. A file-scope static const at the top of this file
> > 2. A macro assigned to one of those sequences
> > 3. A function to "detect" which architecture we're running
>
> I do not have a strong opinion.
>
> Just tuck the #iferry away somewhere in a header file.
Will do
>
> > > > + err = regmap_write(core->cpuorg_regmap, DEV_CPUORG_IF_CTRL, val);
> > > > + if (err)
> > > > + return err;
> > >
> > > Comment.
> > >
> > > > + val = core->spi_padding_bytes;
> > > > + err = regmap_write(core->cpuorg_regmap, DEV_CPUORG_IF_CFGSTAT, val);
> > > > + if (err)
> > > > + return err;
> > >
> > > Comment.
> >
> > Adding:
> >
> > /*
> > * Apply the number of padding bytes between a read request and the data
> > * payload. Some registers have access times of up to 1us, so if the
> > * first payload bit is shifted out too quickly, the read will fail.
> > */
> >
> > >
> > > > + /*
> > > > + * After we write the interface configuration, read it back here. This
> > > > + * will verify several different things. The first is that the number of
> > > > + * padding bytes actually got written correctly. These are found in bits
> > > > + * 0:3.
> > > > + *
> > > > + * The second is that bit 16 is cleared. Bit 16 is IF_CFGSTAT:IF_STAT,
> > > > + * and will be set if the register access is too fast. This would be in
> > > > + * the condition that the number of padding bytes is insufficient for
> > > > + * the SPI bus frequency.
> > > > + *
> > > > + * The last check is for bits 31:24, which define the interface by which
> > > > + * the registers are being accessed. Since we're accessing them via the
> > > > + * serial interface, it must return IF_NUM_SI.
> > > > + */
> > > > + check = val | CFGSTAT_IF_NUM_SI;
> > > > +
> > > > + err = regmap_read(core->cpuorg_regmap, DEV_CPUORG_IF_CFGSTAT, &val);
> > > > + if (err)
> > > > + return err;
> > > > +
> > > > + if (check != val)
> > > > + return -ENODEV;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(ocelot_spi_initialize);
> > > > +
> > > > +/*
> > > > + * The SPI protocol for interfacing with the ocelot chips uses 24 bits, while
> > > > + * the register locations are defined as 32-bit. The least significant two bits
> > > > + * get shifted out, as register accesses must always be word-aligned, leaving
> > > > + * bits 21:0 as the 22-bit address. It must always be big-endian, whereas the
> > > > + * payload can be optimized for bit / byte order to match whatever architecture
> > > > + * the controlling CPU has.
> > > > + */
> > > > +static unsigned int ocelot_spi_translate_address(unsigned int reg)
> > > > +{
> > > > + return cpu_to_be32((reg & 0xffffff) >> 2);
> > > > +}
> > > > +
> > > > +struct ocelot_spi_regmap_context {
> > > > + u32 base;
> > > > + struct ocelot_core *core;
> > > > +};
> > > > +
> > > > +static int ocelot_spi_reg_read(void *context, unsigned int reg,
> > > > + unsigned int *val)
> > > > +{
> > > > + struct ocelot_spi_regmap_context *regmap_context = context;
> > > > + struct ocelot_core *core = regmap_context->core;
> > > > + struct spi_transfer tx, padding, rx;
> > > > + struct spi_message msg;
> > >
> > > How big are all of these?
> > >
> > > We will receive warnings if they occupy too much stack space.
> >
> > Looking at the structs they're on the order of 10s of bytes. Maybe 70
> > bytes per instance (back of napkin calculation)
> >
> > But it seems very common to stack-allocate spi_transfers:
> >
> > https://elixir.bootlin.com/linux/v5.18-rc2/source/drivers/spi/spi.c#L4097
> > https://elixir.bootlin.com/linux/v5.18-rc2/source/include/linux/spi/spi.h#L1244
> >
> > Do you have a feel for at what point that becomes a concern?
>
> That's fine. I just want you to bear this in mind.
>
> I wish to prevent adding yet more W=1 level warnings into the kernel.
>
> > > > + struct spi_device *spi;
> > > > + unsigned int addr;
> > > > + u8 *tx_buf;
> > > > +
> > > > + spi = core->spi;
> > > > +
> > > > + addr = ocelot_spi_translate_address(reg + regmap_context->base);
> > > > + tx_buf = (u8 *)&addr;
> > > > +
> > > > + spi_message_init(&msg);
> > > > +
> > > > + memset(&tx, 0, sizeof(tx));
> > > > +
> > > > + /* Ignore the first byte for the 24-bit address */
> > > > + tx.tx_buf = &tx_buf[1];
> > > > + tx.len = 3;
> > > > +
> > > > + spi_message_add_tail(&tx, &msg);
> > > > +
> > > > + if (core->spi_padding_bytes > 0) {
> > > > + u8 dummy_buf[16] = {0};
> > > > +
> > > > + memset(&padding, 0, sizeof(padding));
> > > > +
> > > > + /* Just toggle the clock for padding bytes */
> > > > + padding.len = core->spi_padding_bytes;
> > > > + padding.tx_buf = dummy_buf;
> > > > + padding.dummy_data = 1;
> > > > +
> > > > + spi_message_add_tail(&padding, &msg);
> > > > + }
> > > > +
> > > > + memset(&rx, 0, sizeof(rx));
> > > > + rx.rx_buf = val;
> > > > + rx.len = 4;
> > > > +
> > > > + spi_message_add_tail(&rx, &msg);
> > > > +
> > > > + return spi_sync(spi, &msg);
> > > > +}
> > > > +
> > > > +static int ocelot_spi_reg_write(void *context, unsigned int reg,
> > > > + unsigned int val)
> > > > +{
> > > > + struct ocelot_spi_regmap_context *regmap_context = context;
> > > > + struct ocelot_core *core = regmap_context->core;
> > > > + struct spi_transfer tx[2] = {0};
> > > > + struct spi_message msg;
> > > > + struct spi_device *spi;
> > > > + unsigned int addr;
> > > > + u8 *tx_buf;
> > > > +
> > > > + spi = core->spi;
> > > > +
> > > > + addr = ocelot_spi_translate_address(reg + regmap_context->base);
> > > > + tx_buf = (u8 *)&addr;
> > > > +
> > > > + spi_message_init(&msg);
> > > > +
> > > > + /* Ignore the first byte for the 24-bit address and set the write bit */
> > > > + tx_buf[1] |= BIT(7);
> > > > + tx[0].tx_buf = &tx_buf[1];
> > > > + tx[0].len = 3;
> > > > +
> > > > + spi_message_add_tail(&tx[0], &msg);
> > > > +
> > > > + memset(&tx[1], 0, sizeof(struct spi_transfer));
> > > > + tx[1].tx_buf = &val;
> > > > + tx[1].len = 4;
> > > > +
> > > > + spi_message_add_tail(&tx[1], &msg);
> > > > +
> > > > + return spi_sync(spi, &msg);
> > > > +}
> > > > +
> > > > +static const struct regmap_config ocelot_spi_regmap_config = {
> > > > + .reg_bits = 24,
> > > > + .reg_stride = 4,
> > > > + .val_bits = 32,
> > > > +
> > > > + .reg_read = ocelot_spi_reg_read,
> > > > + .reg_write = ocelot_spi_reg_write,
> > > > +
> > > > + .max_register = 0xffffffff,
> > > > + .use_single_write = true,
> > > > + .use_single_read = true,
> > > > + .can_multi_write = false,
> > > > +
> > > > + .reg_format_endian = REGMAP_ENDIAN_BIG,
> > > > + .val_format_endian = REGMAP_ENDIAN_NATIVE,
> > > > +};
> > > > +
> > > > +struct regmap *
> > > > +ocelot_spi_devm_get_regmap(struct ocelot_core *core, struct device *child,
> > > > + const struct resource *res)
> > >
> > > This seems to always initialise a new Regmap.
> > >
> > > To me 'get' implies that it could fetch an already existing one.
> > >
> > > ... and *perhaps* init a new one if none exists..
> >
> > That's exactly what my intention was when I started.
> >
> > But it seems like *if* that is something that is required, it should be
> > done through a syscon / device tree implementation and not be snuck into
> > this regmap getter. I was trying to do too much.
> >
> > I'm renaming to "init"
> >
> > >
> > > > +{
> > > > + struct ocelot_spi_regmap_context *context;
> > > > + struct regmap_config regmap_config;
> > > > +
> > > > + context = devm_kzalloc(child, sizeof(*context), GFP_KERNEL);
> > > > + if (IS_ERR(context))
> > > > + return ERR_CAST(context);
> > > > +
> > > > + context->base = res->start;
> > > > + context->core = core;
> > > > +
> > > > + memcpy(®map_config, &ocelot_spi_regmap_config,
> > > > + sizeof(ocelot_spi_regmap_config));
> > > > +
> > > > + regmap_config.name = res->name;
> > > > + regmap_config.max_register = res->end - res->start;
> > > > +
> > > > + return devm_regmap_init(child, NULL, context, ®map_config);
> > > > +}
> > > > +
> > > > +static int ocelot_spi_probe(struct spi_device *spi)
> > > > +{
> > > > + struct device *dev = &spi->dev;
> > > > + struct ocelot_core *core;
> > >
> > > This would be more in keeping with current drivers if you dropped the
> > > '_core' part of the struct name and called the variable ddata.
> >
> > There's already a "struct ocelot" defined in include/soc/mscc/ocelot.h.
> > I suppose it could be renamed to align with what it actually is: the
> > "switch" component of the ocelot chip.
> >
> > Vladimir, Alexandre, Horaitu, others:
> > Any opinions about this becoming "struct ocelot" and the current struct
> > being "struct ocelot_switch"?
> >
> > Or maybe a technical / philosophical question: is "ocelot" the switch
> > core that can be implemented in other hardware? Or is it the chip family
> > entirely, (pinctrl, sgpio, etc.) who's switch core was brought into
> > other products?
> >
> > The existing struct change would hit about 30 files.
> > https://elixir.bootlin.com/linux/v5.18-rc2/C/ident/ocelot
>
> That's not ideal.
>
> Please consider using 'ocelot_ddata' for now and consider a larger
> overhaul at a later date, if it makes sense to do so.
>
> [...]
>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 v5 07/11] x86: use fallback for random_get_entropy() instead of zero
From: Jason A. Donenfeld @ 2022-04-19 19:00 UTC (permalink / raw)
To: Borislav Petkov
Cc: LKML, Linux Crypto Mailing List, Thomas Gleixner, Arnd Bergmann,
Theodore Ts'o, Dominik Brodowski, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven,
Thomas Bogendoerfer, Paul Walmsley, Palmer Dabbelt, Albert Ou,
David S . Miller, Richard Weinberger, Anton Ivanov, Johannes Berg,
Ingo Molnar, Dave Hansen, H . Peter Anvin, Chris Zankel,
Max Filippov, Stephen Boyd, Dinh Nguyen, linux-arm-kernel,
linux-m68k, open list:BROADCOM NVRAM DRIVER, linux-riscv,
sparclinux, linux-um, X86 ML, linux-xtensa
In-Reply-To: <Yl8GhNjwPLNiUfSZ@zn.tnic>
Hi Borislav,
On Tue, Apr 19, 2022 at 8:59 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Apr 19, 2022 at 08:38:41PM +0200, Jason A. Donenfeld wrote:
> > I think I prefer doing (a), and leaving (b) for another time when you
> > or another x86 maintainer can do so. But I'll do whichever you say.
> > Which would you like?
>
> We are switching all feature checks to cpu_feature_enabled() so you
> might as well do the new preferred way of checking when adding a
> new function and so that we have one less place to touch. Which is
> appreciated. :)
Okay, no problem. I'll make the change there and get_cycles() for v+1
of the patchset.
Jason
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [next] arm: boot failed - PC is at cpu_ca15_set_pte_ext
From: Russell King (Oracle) @ 2022-04-19 18:57 UTC (permalink / raw)
To: Naresh Kamboju
Cc: Linux ARM, open list, Linux-Next Mailing List, lkft-triage,
Stephen Rothwell, Arnd Bergmann, Ard Biesheuvel, Andrew Morton,
max.krummenacher, Shawn Guo, Stefano Stabellini,
Christoph Hellwig, Konrad Rzeszutek Wilk, Eric W. Biederman
In-Reply-To: <CA+G9fYuACgY2hcAgh_LwVb9AURjodMJbV6SsJb90wj-0aJKUOw@mail.gmail.com>
On Tue, Apr 19, 2022 at 04:28:52PM +0530, Naresh Kamboju wrote:
> Linux next 20220419 boot failed on arm architecture qemu_arm and BeagleBoard
> x15 device.
Was the immediately previous linux-next behaving correctly?
If so, nothing has changed in the ARM32 kernel tree, so this must be
someone else's issue - code that someone else has pushed into
linux-next.
It looks to me like someone is walking the page tables incorrectly,
somewhere buried in handle_mm_fault(), because the PTE pointer is in
the upper-2k of a 4k page, which is most definitely illegal on arm32.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
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