* Re: [PATCH 01/10] spi: dw: Add support for polled operation via no IRQ specified in DT
From: Andy Shevchenko @ 2020-05-13 14:55 UTC (permalink / raw)
To: Lars Povlsen
Cc: Mark Brown, SoC Team, Microchip Linux Driver Support, linux-spi,
devicetree, Linux Kernel Mailing List, linux-arm Mailing List,
Alexandre Belloni
In-Reply-To: <20200513140031.25633-2-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 5:03 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
>
> With this change a SPI controller can be added without having a IRQ
> associated, and causing all transfers to be polled. For SPI controllers
> without DMA, this can significantly improve performance by less
> interrupt handling overhead.
...
> +#define VALID_IRQ(i) (i >= 0)
drivers/rtc/rtc-cmos.c:95:#define is_valid_irq(n) ((n) > 0)
Candidate to be in include/linux/irq.h ?
...
> + if (VALID_IRQ(dws->irq))
> + free_irq(dws->irq, master);
Isn't free_irq() aware of invalid ones (not found IRQ in the tree or
any other backend container won't do anything)?
> err_free_master:
> spi_controller_put(master);
> return ret;
> --
> 2.26.2
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 2/5] PCI: Add Loongson PCI Controller support
From: Bjorn Helgaas @ 2020-05-13 15:05 UTC (permalink / raw)
To: Jiaxun Yang
Cc: linux-pci, Rob Herring, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <08C2301A-7349-4044-80F4-0B0520780DB9@flygoat.com>
On Wed, May 13, 2020 at 09:20:08AM +0800, Jiaxun Yang wrote:
> 于 2020年5月13日 GMT+08:00 上午2:06:02, Bjorn Helgaas <helgaas@kernel.org> 写到:
> >On Tue, May 12, 2020 at 03:43:56PM +0800, Jiaxun Yang wrote:
> >> This controller can be found on Loongson-2K SoC, Loongson-3
> >> systems with RS780E/LS7A PCH.
> >>
> >> The RS780E part of code was previously located at
> >> arch/mips/pci/ops-loongson3.c and now it can use generic PCI
> >> driver implementation.
> >>
> >> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> >> Reviewed-by: Rob Herring <robh@kernel.org>
> >
> >> +static void system_bus_quirk(struct pci_dev *pdev)
> >> +{
> >> + u16 tmp;
> >> +
> >> + /*
> >> + * These devices are not sharing resouces with rest of devices
> >> + * on host bus and firmware will ensure their BARs are placed
> >> + * in safe ranges. Also there might be some config registers
> >> + * in their config space so kernel shouldn't ignore them.
> >
> >"Firmware ensuring BARs are placed in 'safe' ranges" is not a
> >sufficient answer. As I said before, Linux needs to know both the
> >ADDRESS and the SIZE of whatever non-standard BARs these are.
> >Otherwise, we're liable to assign that space to a different device.
>
> The address assigned to these devices will never be a part of resources
> belongs to the host bridge. That's enforced by hardware and firmware,
> so address conflict would never happen.
>
> I'm doing like this to ensure kernel will discover this device but do nothing
> about assignment of resources to it.
OK, that's really ugly, but I guess we can't do anything about it. It
would be helpful to make the comment say something like:
The address space consumed by these devices is outside the resources
of the host bridge.
Side note: in ACPI systems, the ACPI namespace is supposed to describe
all resources consumed by all devices. Does DT have a similar
expectation? Is there something in DT that tells us about the address
space used by these devices? Even if that space never overlaps with
the PCI host bridge apertures, it might be useful to show the space in
/proc/iomem and similar places.
Bjorn
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Florian Fainelli @ 2020-05-13 15:08 UTC (permalink / raw)
To: Greg Kroah-Hartman, Al Cooper
Cc: linux-kernel, Alan Stern, Andy Shevchenko,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda,
Andy Shevchenko
In-Reply-To: <20200513122613.GA1023594@kroah.com>
On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>> devices and OHCI handles <2.0 devices. Currently the Makefile
>> has XHCI linking at the bottom which will result in the XHIC driver
>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>> device will be seen as a 2.0 device. Moving the XHCI linking
>> above the EHCI and OHCI linking fixes the issue.
>
> What happens if all of these are modules and they are loaded in a
> different order? This makefile change will not help with that, you need
> to have logic in the code in order to properly coordinate this type of
> mess, sorry.
I believe we should be using module soft dependencies to instruct the
module loaders to load the modules in the correct order, so something
like this would do (not tested) for xhci-plat-hcd.c:
MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
and I am not sure whether we need to add the opposite for ehci-hcd and
ohci-hcd:
MODULE_SOFTDEP("pre: xhci-plat-hcd");
Al, do you want to test that?
--
Florian
^ permalink raw reply
* [PATCH v3] dt-bindings: thermal: rcar-gen3-thermal: Convert bindings to json-schema
From: Niklas Söderlund @ 2020-05-13 15:12 UTC (permalink / raw)
To: Rob Herring, linux-pm, devicetree
Cc: linux-renesas-soc, Niklas Söderlund, Geert Uytterhoeven
Convert Renesas R-Car Gen3 Thermal bindings documentation to
json-schema.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
* Changes since v2
- Use reg = <0xe6198000 0x100> instead of reg = <0 0xe6198000 0 0x100>
in examples due to #{address,size}-cells = <1>.
* Changes since v1
- Improved on reg and interrupt descriptions with the use of 'items:'
- Improved the examples inside the yaml file
- Added compatibility value renesas,r8a77961-thermal for R-Car M3-W+
which was merged in the text binding description.
---
.../bindings/thermal/rcar-gen3-thermal.txt | 60 -----------
.../bindings/thermal/rcar-gen3-thermal.yaml | 99 +++++++++++++++++++
2 files changed, 99 insertions(+), 60 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
create mode 100644 Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
deleted file mode 100644
index 2993fa720195308f..0000000000000000
--- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-* DT bindings for Renesas R-Car Gen3 Thermal Sensor driver
-
-On R-Car Gen3 SoCs, the thermal sensor controllers (TSC) control the thermal
-sensors (THS) which are the analog circuits for measuring temperature (Tj)
-inside the LSI.
-
-Required properties:
-- compatible : "renesas,<soctype>-thermal",
- Examples with soctypes are:
- - "renesas,r8a774a1-thermal" (RZ/G2M)
- - "renesas,r8a774b1-thermal" (RZ/G2N)
- - "renesas,r8a7795-thermal" (R-Car H3)
- - "renesas,r8a7796-thermal" (R-Car M3-W)
- - "renesas,r8a77961-thermal" (R-Car M3-W+)
- - "renesas,r8a77965-thermal" (R-Car M3-N)
- - "renesas,r8a77980-thermal" (R-Car V3H)
-- reg : Address ranges of the thermal registers. Each sensor
- needs one address range. Sorting must be done in
- increasing order according to datasheet, i.e.
- TSC1, TSC2, ...
-- clocks : Must contain a reference to the functional clock.
-- #thermal-sensor-cells : must be <1>.
-
-Optional properties:
-
-- interrupts : interrupts routed to the TSC (must be 3).
-- power-domain : Must contain a reference to the power domain. This
- property is mandatory if the thermal sensor instance
- is part of a controllable power domain.
-
-Example:
-
- tsc: thermal@e6198000 {
- compatible = "renesas,r8a7795-thermal";
- reg = <0 0xe6198000 0 0x100>,
- <0 0xe61a0000 0 0x100>,
- <0 0xe61a8000 0 0x100>;
- interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&cpg CPG_MOD 522>;
- power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
- #thermal-sensor-cells = <1>;
- };
-
- thermal-zones {
- sensor_thermal1: sensor-thermal1 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 0>;
-
- trips {
- sensor1_crit: sensor1-crit {
- temperature = <90000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
new file mode 100644
index 0000000000000000..b1a55ae497dec9f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml
@@ -0,0 +1,99 @@
+# SPDX-License-Identifier: GPL-2.0-only
+# Copyright (C) 2020 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/rcar-gen3-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen3 Thermal Sensor
+
+description:
+ On R-Car Gen3 SoCs, the thermal sensor controllers (TSC) control the thermal
+ sensors (THS) which are the analog circuits for measuring temperature (Tj)
+ inside the LSI.
+
+maintainers:
+ - Niklas Söderlund <niklas.soderlund@ragnatech.se>
+
+properties:
+ compatible:
+ enum:
+ - renesas,r8a774a1-thermal # RZ/G2M
+ - renesas,r8a774b1-thermal # RZ/G2N
+ - renesas,r8a7795-thermal # R-Car H3
+ - renesas,r8a7796-thermal # R-Car M3-W
+ - renesas,r8a77961-thermal # R-Car M3-W+
+ - renesas,r8a77965-thermal # R-Car M3-N
+ - renesas,r8a77980-thermal # R-Car V3H
+ reg:
+ minItems: 2
+ maxItems: 3
+ items:
+ - description: TSC1 registers
+ - description: TSC2 registers
+ - description: TSC3 registers
+
+ interrupts:
+ items:
+ - description: TEMP1 interrupt
+ - description: TEMP2 interrupt
+ - description: TEMP3 interrupt
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ "#thermal-sensor-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - power-domains
+ - resets
+ - "#thermal-sensor-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a7795-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a7795-sysc.h>
+
+ tsc: thermal@e6198000 {
+ compatible = "renesas,r8a7795-thermal";
+ reg = <0xe6198000 0x100>,
+ <0xe61a0000 0x100>,
+ <0xe61a8000 0x100>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 522>;
+ power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
+ resets = <&cpg 522>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal-zones {
+ sensor_thermal: sensor-thermal {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 0>;
+
+ trips {
+ sensor1_crit: sensor1-crit {
+ temperature = <90000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 3/3] hwmon: sparx5: Add Sparx5 SoC temperature driver
From: Guenter Roeck @ 2020-05-13 15:20 UTC (permalink / raw)
To: Lars Povlsen
Cc: SoC Team, Jean Delvare, Microchip Linux Driver Support,
linux-hwmon, devicetree, linux-arm-kernel, linux-kernel,
Alexandre Belloni
In-Reply-To: <20200513134140.25357-4-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 03:41:40PM +0200, Lars Povlsen wrote:
> This patch adds a temperature sensor driver to the Sparx5 SoC.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> drivers/hwmon/Kconfig | 10 +++
> drivers/hwmon/Makefile | 2 +-
> drivers/hwmon/sparx5-temp.c | 154 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 165 insertions(+), 1 deletion(-)
> create mode 100644 drivers/hwmon/sparx5-temp.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 4c62f900bf7e8..130cb1f1748ff 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -480,6 +480,16 @@ config SENSORS_I5K_AMB
> This driver can also be built as a module. If so, the module
> will be called i5k_amb.
>
> +config SENSORS_SPARX5
> + tristate "Sparx5 SoC temperature sensor"
> + depends on ARCH_SPARX5
> + help
> + If you say yes here you get support for temperature monitoring
> + with the Microchip Sparx5 SoC.
> +
> + This driver can also be built as a module. If so, the module
> + will be called sparx5-temp.
> +
> config SENSORS_F71805F
> tristate "Fintek F71805F/FG, F71806F/FG and F71872F/FG"
> depends on !PPC
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index b0b9c8e571762..28a09986b7a62 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -64,6 +64,7 @@ obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
> obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o
> obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o
> obj-$(CONFIG_SENSORS_EMC6W201) += emc6w201.o
> +obj-$(CONFIG_SENSORS_SPARX5) += sparx5-temp.o
> obj-$(CONFIG_SENSORS_F71805F) += f71805f.o
> obj-$(CONFIG_SENSORS_F71882FG) += f71882fg.o
> obj-$(CONFIG_SENSORS_F75375S) += f75375s.o
> @@ -190,4 +191,3 @@ obj-$(CONFIG_SENSORS_OCC) += occ/
> obj-$(CONFIG_PMBUS) += pmbus/
>
> ccflags-$(CONFIG_HWMON_DEBUG_CHIP) := -DDEBUG
> -
> diff --git a/drivers/hwmon/sparx5-temp.c b/drivers/hwmon/sparx5-temp.c
> new file mode 100644
> index 0000000000000..bf9dd102a9825
> --- /dev/null
> +++ b/drivers/hwmon/sparx5-temp.c
> @@ -0,0 +1,154 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/* Sparx5 SoC temperature sensor driver
> + *
> + * Copyright (C) 2020 Lars Povlsen <lars.povlsen@microchip.com>
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
Unnecessary include
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +
> +#define TEMP_CTRL 0
> +#define TEMP_CFG 4
> +#define TEMP_CFG_CYCLES GENMASK(24, 15)
> +#define TEMP_CFG_CYCLES_OFF 15
> +#define TEMP_CFG_ENA BIT(0)
> +#define TEMP_STAT 8
> +#define TEMP_STAT_VALID BIT(12)
> +#define TEMP_STAT_TEMP GENMASK(11, 0)
> +
> +struct s5_hwmon {
> + void __iomem *base;
> +};
> +
> +static void s5_temp_enable(struct s5_hwmon *hwmon)
> +{
> + u32 val = readl(hwmon->base + TEMP_CFG);
> + u32 clk = 250;
> +
> + val &= ~TEMP_CFG_CYCLES;
> + val |= (clk << TEMP_CFG_CYCLES_OFF);
> + val |= TEMP_CFG_ENA;
> +
> + writel(val, hwmon->base + TEMP_CFG);
> +}
> +
> +static void s5_temp_disable(void *data)
> +{
> + struct s5_hwmon *hwmon = data;
> + u32 val = readl(hwmon->base + TEMP_CFG);
> +
> + val &= ~TEMP_CFG_ENA;
> +
> + writel(val, hwmon->base + TEMP_CFG);
> +}
> +
> +static int s5_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *temp)
> +{
> + struct s5_hwmon *hwmon = dev_get_drvdata(dev);
> + int rc = 0, value;
> + u32 stat;
> +
> + switch (attr) {
> + case hwmon_temp_input:
> + stat = readl_relaxed(hwmon->base + TEMP_STAT);
> + if (stat & TEMP_STAT_VALID) {
> + value = (stat & TEMP_STAT_TEMP);
Unnecessary ( )
> + value = DIV_ROUND_CLOSEST(value * 3522, 4096) - 1094;
> + value *= 100;
> + *temp = value;
> + } else
> + rc = -EINVAL;
-EINVAL is for bad used input. -EIO, maybe, unless there is a better error.
Also,
if (!(stat & TEMP_STAT_VALID))
return -EIO;
...
would be easier to read (and not result in a checkpatch warning).
> + break;
> + default:
> + rc = -EOPNOTSUPP;
break;
> + }
> +
> + return rc;
> +}
> +
> +static umode_t s5_is_visible(const void *_data, enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + if (type != hwmon_temp)
> + return 0;
> +
> + switch (attr) {
> + case hwmon_temp_input:
> + return 0444;
> + default:
> + return 0;
> + }
> +}
> +
> +static const struct hwmon_channel_info *s5_info[] = {
> + HWMON_CHANNEL_INFO(chip,
> + HWMON_C_REGISTER_TZ),
> + HWMON_CHANNEL_INFO(temp,
> + HWMON_T_INPUT),
> + NULL
> +};
> +
> +static const struct hwmon_ops s5_hwmon_ops = {
> + .is_visible = s5_is_visible,
> + .read = s5_read,
> +};
> +
> +static const struct hwmon_chip_info s5_chip_info = {
> + .ops = &s5_hwmon_ops,
> + .info = s5_info,
> +};
> +
> +static int s5_temp_probe(struct platform_device *pdev)
> +{
> + struct device *hwmon_dev;
> + struct s5_hwmon *hwmon;
> + int err = 0;
Unnecessary initialization
> +
> + hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon), GFP_KERNEL);
> + if (!hwmon)
> + return -ENOMEM;
> +
> + hwmon->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(hwmon->base))
> + return PTR_ERR(hwmon->base);
> +
> + err = devm_add_action(&pdev->dev, s5_temp_disable, hwmon);
> + if (err)
> + return err;
> +
> + s5_temp_enable(hwmon);
> +
> + hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
> + "s5_temp",
> + hwmon,
> + &s5_chip_info,
> + NULL);
> +
> + return PTR_ERR_OR_ZERO(hwmon_dev);
> +}
> +
> +const struct of_device_id s5_temp_match[] = {
> + { .compatible = "microchip,sparx5-temp" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, s5_temp_match);
> +
> +static struct platform_driver s5_temp_driver = {
> + .probe = s5_temp_probe,
> + .driver = {
> + .name = "sparx5-temp",
> + .of_match_table = s5_temp_match,
> + },
> +};
> +
> +module_platform_driver(s5_temp_driver);
> +
> +MODULE_AUTHOR("Lars Povlsen <lars.povlsen@microchip.com>");
> +MODULE_DESCRIPTION("Sparx5 SoC temperature sensor driver");
> +MODULE_LICENSE("GPL");
> --
> 2.26.2
^ permalink raw reply
* Re: [PATCH v10 2/3] i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver
From: Andy Shevchenko @ 2020-05-13 15:24 UTC (permalink / raw)
To: Tali Perry
Cc: ofery, Brendan Higgins, avifishman70, Tomer Maimon, kfting,
Patrick Venture, Nancy Yuen, Benjamin Fair, Rob Herring,
Wolfram Sang, linux-arm-kernel, linux-i2c, OpenBMC Maillist,
devicetree, Linux Kernel Mailing List
In-Reply-To: <CAHb3i=tERsM+gwmQN1+vjnML9o5NxRK=uBokEUsd-Ljyje4s3A@mail.gmail.com>
On Mon, May 11, 2020 at 02:28:50PM +0300, Tali Perry wrote:
> On Mon, May 11, 2020 at 12:18 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Sun, May 10, 2020 at 01:23:29PM +0300, Tali Perry wrote:
...
> > > +#if IS_ENABLED(CONFIG_DEBUG_FS)
> >
> > Why?
>
> We wanted to add an optional feature to track i2c slave status.
> the NPCM has 16 channels handling multiple devices each. Some of the devices
> are polled periodically, and might power down.
> The user wanted to implement a health monitoring option
> to occasionally check the status of the buses (how many timeouts, recovery etc.)
> This feature is optional and depends on CONFIG_DEBUG_FS The counters are exposed
> to user through the file system.
What I meant is why do you need an #ifdef?
...
> > > +#define I2C_NUM_OF_ADDR 10
> >
> > Is it 10-bit address support or what?
> >
>
> No, the NPCM has an option to respond to multiple slave addresses
> (10 own slave addresses)
Perhaps more descriptive name then?
...
> > > + // Repeat the following sequence until SDA is released
> > > + do {
> > > + // Issue a single SCL toggle
> > > + iowrite8(NPCM_I2CCST_TGSCL, bus->reg + NPCM_I2CCST);
> > > + udelay(20);
> > > + // If SDA line is inactive (high), stop
> > > + if (npcm_i2c_get_SDA(_adap)) {
> > > + done = true;
> > > + status = 0;
> > > + }
> > > + } while (!done && iter--);
> >
> > readx_poll_timeout() ?
>
> Not exactly, readx_poll_timeout includes only a read operation, here there is a
> write in the middle. (iowrite8)
Ah, indeed. Perhaps time to add writex_poll_timeout() ?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Andy Shevchenko @ 2020-05-13 15:26 UTC (permalink / raw)
To: Florian Fainelli
Cc: Greg Kroah-Hartman, Al Cooper, linux-kernel, Alan Stern,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda
In-Reply-To: <7acc2a4c-caab-11e7-7b3f-4176f19c58cf@gmail.com>
On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >> devices and OHCI handles <2.0 devices. Currently the Makefile
> >> has XHCI linking at the bottom which will result in the XHIC driver
> >> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >> device will be seen as a 2.0 device. Moving the XHCI linking
> >> above the EHCI and OHCI linking fixes the issue.
> >
> > What happens if all of these are modules and they are loaded in a
> > different order? This makefile change will not help with that, you need
> > to have logic in the code in order to properly coordinate this type of
> > mess, sorry.
>
> I believe we should be using module soft dependencies to instruct the
> module loaders to load the modules in the correct order, so something
> like this would do (not tested) for xhci-plat-hcd.c:
>
> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>
> and I am not sure whether we need to add the opposite for ehci-hcd and
> ohci-hcd:
>
> MODULE_SOFTDEP("pre: xhci-plat-hcd");
JFYI: not all user space support this (alas, but that's current state of
affairs), OTOH I don't really care about those which do not support it
(Busybox).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Florian Fainelli @ 2020-05-13 15:28 UTC (permalink / raw)
To: Andy Shevchenko, Florian Fainelli
Cc: Greg Kroah-Hartman, Al Cooper, linux-kernel, Alan Stern,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda
In-Reply-To: <20200513152613.GR185537@smile.fi.intel.com>
On 5/13/2020 8:26 AM, Andy Shevchenko wrote:
> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
>>>> has XHCI linking at the bottom which will result in the XHIC driver
>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>>>> device will be seen as a 2.0 device. Moving the XHCI linking
>>>> above the EHCI and OHCI linking fixes the issue.
>>>
>>> What happens if all of these are modules and they are loaded in a
>>> different order? This makefile change will not help with that, you need
>>> to have logic in the code in order to properly coordinate this type of
>>> mess, sorry.
>>
>> I believe we should be using module soft dependencies to instruct the
>> module loaders to load the modules in the correct order, so something
>> like this would do (not tested) for xhci-plat-hcd.c:
>>
>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>>
>> and I am not sure whether we need to add the opposite for ehci-hcd and
>> ohci-hcd:
>>
>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
>
> JFYI: not all user space support this (alas, but that's current state of
> affairs), OTOH I don't really care about those which do not support it
> (Busybox).
I know that Gentoo's initramfs tool does not support it, however given
there are no symbols being cross referenced, I am not sure how to best
support this other than using these hints, and possibly making use of
device links too?
--
Florian
^ permalink raw reply
* Re: [PATCH v6 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Andy Shevchenko @ 2020-05-13 15:34 UTC (permalink / raw)
To: Ramuthevar,Vadivel MuruganX
Cc: linux-kernel, linux-mtd, devicetree, miquel.raynal, richard,
vigneshr, arnd, brendanhiggins, tglx, boris.brezillon,
anders.roxell, masonccyang, robh+dt, linux-mips, hauke.mehrtens,
qi-ming.wu, cheol.yong.kim
In-Reply-To: <20200513104615.7905-3-vadivel.muruganx.ramuthevar@linux.intel.com>
On Wed, May 13, 2020 at 06:46:15PM +0800, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com>
>
> This patch adds the new IP of Nand Flash Controller(NFC) support
> on Intel's Lightning Mountain(LGM) SoC.
>
> DMA is used for burst data transfer operation, also DMA HW supports
> aligned 32bit memory address and aligned data access by default.
> DMA burst of 8 supported. Data register used to support the read/write
> operation from/to device.
>
> NAND controller driver implements ->exec_op() to replace legacy hooks,
> these specific call-back method to execute NAND operations.
...
> +static int ebu_nand_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct ebu_nand_controller *ebu_host;
> + struct nand_chip *nand;
> + struct mtd_info *mtd;
> + struct resource *res;
> + char *resname;
> + int ret, i;
> + u32 reg;
> +
> + ebu_host = devm_kzalloc(dev, sizeof(*ebu_host), GFP_KERNEL);
> + if (!ebu_host)
> + return -ENOMEM;
> +
> + ebu_host->dev = dev;
> + nand_controller_init(&ebu_host->controller);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
> + ebu_host->ebu = devm_ioremap_resource(&pdev->dev, res);
devm_platform_ioremap_resource_byname
> + if (IS_ERR(ebu_host->ebu))
> + return PTR_ERR(ebu_host->ebu);
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
> + ebu_host->hsnand = devm_ioremap_resource(&pdev->dev, res);
devm_platform_ioremap_resource_byname
> + if (IS_ERR(ebu_host->hsnand))
> + return PTR_ERR(ebu_host->hsnand);
> +
> + ret = device_property_read_u32(dev, "nand,cs", ®);
> + if (ret) {
> + dev_err(dev, "failed to get chip select: %d\n", ret);
> + return ret;
> + }
> + ebu_host->cs_num = reg;
> +
> + for (i = 0; i < MAX_CS; i++) {
> + resname = devm_kasprintf(dev, GFP_KERNEL, "nand_cs%d", i);
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + resname);
if res is NULL?
> + ebu_host->cs[i].chipaddr = devm_ioremap_resource(dev, res);
> + ebu_host->cs[i].nand_pa = res->start;
> + if (IS_ERR(ebu_host->cs[i].chipaddr))
> + return PTR_ERR(ebu_host->cs[i].chipaddr);
Something happened with ordering / indentation along these lines...
> + }
> +
> + for (i = 0; i < MAX_CS; i++) {
> + resname = devm_kasprintf(dev, GFP_KERNEL, "addr_sel%d", i);
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> + resname);
if res is NULL?
> + ebu_host->cs[i].addr_sel = res->start;
> + writel(ebu_host->cs[i].addr_sel | EBU_ADDR_MASK(5) |
> + EBU_ADDR_SEL_REGEN, ebu_host->ebu + EBU_ADDR_SEL(i));
> + }
> + return ret;
> +}
...
> +static int ebu_nand_remove(struct platform_device *pdev)
> +{
> + struct ebu_nand_controller *ebu_host = platform_get_drvdata(pdev);
> +
> + if (ebu_host) {
How it can be NULL here?
> + mtd_device_unregister(nand_to_mtd(&ebu_host->chip));
> + nand_cleanup(&ebu_host->chip);
> + ebu_nand_disable(&ebu_host->chip);
> +
> + if (ebu_host->dma_rx || ebu_host->dma_tx)
> + ebu_dma_cleanup(ebu_host);
> +
> + clk_disable_unprepare(ebu_host->clk);
> + }
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v6 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
From: Andy Shevchenko @ 2020-05-13 15:35 UTC (permalink / raw)
To: Ramuthevar,Vadivel MuruganX
Cc: linux-kernel, linux-mtd, devicetree, miquel.raynal, richard,
vigneshr, arnd, brendanhiggins, tglx, boris.brezillon,
anders.roxell, masonccyang, robh+dt, linux-mips, hauke.mehrtens,
qi-ming.wu, cheol.yong.kim
In-Reply-To: <20200513153405.GS185537@smile.fi.intel.com>
On Wed, May 13, 2020 at 06:34:05PM +0300, Andy Shevchenko wrote:
> On Wed, May 13, 2020 at 06:46:15PM +0800, Ramuthevar,Vadivel MuruganX wrote:
...
> > +static int ebu_nand_remove(struct platform_device *pdev)
> > +{
> > + struct ebu_nand_controller *ebu_host = platform_get_drvdata(pdev);
> > +
>
> > + if (ebu_host) {
>
> How it can be NULL here?
>
> > + mtd_device_unregister(nand_to_mtd(&ebu_host->chip));
> > + nand_cleanup(&ebu_host->chip);
> > + ebu_nand_disable(&ebu_host->chip);
> > +
> > + if (ebu_host->dma_rx || ebu_host->dma_tx)
This is duplicate and thus redundant.
> > + ebu_dma_cleanup(ebu_host);
> > +
> > + clk_disable_unprepare(ebu_host->clk);
> > + }
> > +
> > + return 0;
> > +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* RE: [PATCH v7 RESEND 07/13] spi: imx: fix ERR009165
From: Robin Gong @ 2020-05-13 15:48 UTC (permalink / raw)
To: Sascha Hauer
Cc: vkoul@kernel.org, shawnguo@kernel.org,
u.kleine-koenig@pengutronix.de, robh+dt@kernel.org,
festevam@gmail.com, dan.j.williams@intel.com,
mark.rutland@arm.com, catalin.marinas@arm.com,
will.deacon@arm.com, l.stach@pengutronix.de,
martin.fuzzey@flowbird.group, kernel@pengutronix.de,
linux-spi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20200513092038.GR5877@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
On 2020/05/13 Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, May 13, 2020 at 08:52:39AM +0000, Robin Gong wrote:
> > On 2020/05/13 16:48 Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > On Wed, May 13, 2020 at 08:38:26AM +0000, Robin Gong wrote:
> > > > On 2020/05/13 Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > > > This patch is the one bisecting will end up with when somebody
> > > > > uses an older SDMA firmware or the ROM scripts. It should have a
> > > > > better description what happens and what should be done about it.
> > > > Emm..That's true. Timeout will be caught in such case, hence,
> > > > maybe we can
> > > fall back it to pio always.
> > >
> > > With my patch applied sdma_load_context() will fail. I don't know
> > > how exactly this hits into the SPI driver, but it won't be a timeout.
> > Thanks for your quick test, assume you use ROM firmware, right?
>
> Yes.
Would you please have a try with the attached patch which is based this patch set?
[-- Attachment #2: 0014-spi-imx-fallback-to-PIO-if-dma-setup-failure.patch --]
[-- Type: application/octet-stream, Size: 3274 bytes --]
From b4f9860be8cc8b9672626baa62a4cec89cf29e87 Mon Sep 17 00:00:00 2001
From: Robin Gong <yibin.gong@nxp.com>
Date: Thu, 14 May 2020 07:18:33 +0800
Subject: [PATCH v7 RESEND 14/14] spi: imx: fallback to PIO if dma setup
failure
Fallback to PIO in case dma setup failed. For example, sdma firmware not
updated but ERR009165 workaroud added in kernel.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
---
drivers/spi/spi-imx.c | 31 +++++++++++++++++++++++++++----
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index a57edcb..56505cb 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -72,6 +72,7 @@ struct spi_imx_devtype_data {
void (*reset)(struct spi_imx_data *);
void (*setup_wml)(struct spi_imx_data *);
void (*disable)(struct spi_imx_data *);
+ void (*disable_dma)(struct spi_imx_data *);
bool has_dmamode;
bool has_slavemode;
unsigned int fifo_size;
@@ -496,6 +497,11 @@ static void mx51_ecspi_trigger(struct spi_imx_data *spi_imx)
writel(reg, spi_imx->base + MX51_ECSPI_CTRL);
}
+static void mx51_disable_dma(struct spi_imx_data *spi_imx)
+{
+ writel(0, spi_imx->base + MX51_ECSPI_DMA);
+}
+
static void mx51_ecspi_disable(struct spi_imx_data *spi_imx)
{
u32 ctrl;
@@ -1008,6 +1014,7 @@ static struct spi_imx_devtype_data imx51_ecspi_devtype_data = {
.rx_available = mx51_ecspi_rx_available,
.reset = mx51_ecspi_reset,
.setup_wml = mx51_setup_wml,
+ .disable_dma = mx51_disable_dma,
.fifo_size = 64,
.has_dmamode = true,
.dynamic_burst = true,
@@ -1022,6 +1029,7 @@ static struct spi_imx_devtype_data imx53_ecspi_devtype_data = {
.prepare_transfer = mx51_ecspi_prepare_transfer,
.trigger = mx51_ecspi_trigger,
.rx_available = mx51_ecspi_rx_available,
+ .disable_dma = mx51_disable_dma,
.reset = mx51_ecspi_reset,
.fifo_size = 64,
.has_dmamode = true,
@@ -1430,6 +1438,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data *spi_imx,
DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
if (!desc_tx) {
dmaengine_terminate_all(master->dma_tx);
+ dmaengine_terminate_all(master->dma_rx);
return -EINVAL;
}
@@ -1543,6 +1552,7 @@ static int spi_imx_transfer(struct spi_device *spi,
struct spi_transfer *transfer)
{
struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master);
+ int ret;
/* flush rxfifo before transfer */
while (spi_imx->devtype_data->rx_available(spi_imx))
@@ -1551,10 +1561,23 @@ static int spi_imx_transfer(struct spi_device *spi,
if (spi_imx->slave_mode)
return spi_imx_pio_transfer_slave(spi, transfer);
- if (spi_imx->usedma)
- return spi_imx_dma_transfer(spi_imx, transfer);
- else
- return spi_imx_pio_transfer(spi, transfer);
+ /*
+ * fallback PIO mode if dma setup error happen, for example sdma
+ * firmware may not be updated as ERR009165 required.
+ */
+ if (spi_imx->usedma) {
+ ret = spi_imx_dma_transfer(spi_imx, transfer);
+ if (ret != -EINVAL)
+ return ret;
+
+ spi_imx->devtype_data->disable_dma(spi_imx);
+
+ spi_imx->usedma = false;
+ spi_imx->dynamic_burst = spi_imx->devtype_data->dynamic_burst;
+ dev_info(&spi->dev, "Fallback to PIO mode\n");
+ }
+
+ return spi_imx_pio_transfer(spi, transfer);
}
static int spi_imx_setup(struct spi_device *spi)
--
2.7.4
^ permalink raw reply related
* [PATCH] arm64: dts: qcom: disable the new cti nodes on devices with broken coresight
From: michael.srba @ 2020-05-13 15:47 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson
Cc: Rob Herring, Mathieu Poirier, Suzuki K Poulose, Mike Leach,
linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming, Michael Srba
From: Michael Srba <michael.srba@seznam.cz>
Attempting to enable these devices causes a "synchronous
external abort". Suspected cause is that the debug power
domain is not enabled by default on this device.
Disable these devices for now to avoid the crash.
See: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/
Fixes: b1fcc5702a41 ("arm64: dts: qcom: msm8916: Add CTI options")
Signed-off-by: Michael Srba <michael.srba@seznam.cz>
---
arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts | 6 ++++++
arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
index d1ccb9472c8b..28983b871a70 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
@@ -105,6 +105,12 @@ wcnss@a21b000 {
etm@85d000 { status = "disabled"; };
etm@85e000 { status = "disabled"; };
etm@85f000 { status = "disabled"; };
+ cti@810000 { status = "disabled"; };
+ cti@811000 { status = "disabled"; };
+ cti@858000 { status = "disabled"; };
+ cti@859000 { status = "disabled"; };
+ cti@85a000 { status = "disabled"; };
+ cti@85b000 { status = "disabled"; };
};
// FIXME: Use extcon device provided by charger driver when available
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
index 43c5e0f882f1..8569a1532a3f 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
@@ -98,6 +98,12 @@ wcnss@a21b000 {
etm@85d000 { status = "disabled"; };
etm@85e000 { status = "disabled"; };
etm@85f000 { status = "disabled"; };
+ cti@810000 { status = "disabled"; };
+ cti@811000 { status = "disabled"; };
+ cti@858000 { status = "disabled"; };
+ cti@859000 { status = "disabled"; };
+ cti@85a000 { status = "disabled"; };
+ cti@85b000 { status = "disabled"; };
};
gpio-keys {
--
2.24.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: disable the new cti nodes on devices with broken coresight
From: Jeffrey Hugo @ 2020-05-13 16:04 UTC (permalink / raw)
To: michael.srba
Cc: Andy Gross, Bjorn Andersson, Rob Herring, Mathieu Poirier,
Suzuki K Poulose, Mike Leach, MSM, DTML, lkml,
~postmarketos/upstreaming
In-Reply-To: <20200513154718.17401-1-michael.srba@seznam.cz>
On Wed, May 13, 2020 at 9:53 AM <michael.srba@seznam.cz> wrote:
>
> From: Michael Srba <michael.srba@seznam.cz>
>
> Attempting to enable these devices causes a "synchronous
> external abort". Suspected cause is that the debug power
> domain is not enabled by default on this device.
> Disable these devices for now to avoid the crash.
>
> See: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/
>
> Fixes: b1fcc5702a41 ("arm64: dts: qcom: msm8916: Add CTI options")
> Signed-off-by: Michael Srba <michael.srba@seznam.cz>
>
> ---
> arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts | 6 ++++++
> arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi | 6 ++++++
> 2 files changed, 12 insertions(+)
Why are we disabling these in board specific files? Seems like these
should be disabled in the base msm8916.dtsi. Otherwise, the next
board that gets brought up is probably going to hit this same exact
issue.
This also follows the solution that msm8998 did for the same issue.
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings
From: Matthias Kaehlcke @ 2020-05-13 16:04 UTC (permalink / raw)
To: Sandeep Maheswaram (Temp)
Cc: Rob Herring, Andy Gross, Bjorn Andersson, Greg Kroah-Hartman,
Mark Rutland, Felipe Balbi, Stephen Boyd, Doug Anderson,
linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam
In-Reply-To: <64ce118c-2a8d-e16c-eed1-49350c8b07bc@codeaurora.org>
Hi Sandeep,
I would suggest to send v6 with the changes Rob and Stephen requested,
except for the 'assigned-clock-rate' constraints. A description instead
of the constraints is not ideal, but the constraints could be also be
added at a later time. Hopefully Rob can either ack with the description
or help to resolve the constraints issue.
Regards
Matthias
On Fri, May 08, 2020 at 11:52:52AM +0530, Sandeep Maheswaram (Temp) wrote:
> Hi Rob,
>
> Any suggestions to solve this error in assigned-clock-rates
>
>
> Regards
> Sandeep
>
> On 4/24/2020 1:09 AM, Matthias Kaehlcke wrote:
> > On Wed, Apr 15, 2020 at 02:23:29PM +0530, Sandeep Maheswaram (Temp) wrote:
> > > Hi Rob,
> > >
> > > Any suggestions to solve this error in assigned-clock-rates
> > > On 4/6/2020 10:09 PM, Sandeep Maheswaram (Temp) wrote:
> > > > Hi Rob,
> > > >
> > > > On 4/4/2020 10:47 PM, Rob Herring wrote:
> > > > > On Thu, Mar 26, 2020 at 12:36:07PM +0530, Sandeep Maheswaram wrote:
> > > > > > Convert USB DWC3 bindings to DT schema format using json-schema.
> > > > > >
> > > > > > Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org>
> > > > > > ---
> > > > > > .../devicetree/bindings/usb/qcom,dwc3.txt | 104
> > > > > > --------------
> > > > > > .../devicetree/bindings/usb/qcom,dwc3.yaml | 158
> > > > > > +++++++++++++++++++++
> > > > > > 2 files changed, 158 insertions(+), 104 deletions(-)
> > > > > > delete mode 100644
> > > > > > Documentation/devicetree/bindings/usb/qcom,dwc3.txt
> > > > > > create mode 100644
> > > > > > Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> > > > > > b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> > > > > > new file mode 100644
> > > > > > index 0000000..0f69475
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> > ...
> >
> > > > > > + items:
> > > > > > + - description: Must be 19.2MHz (19200000).
> > > > > Sounds like a constraint:
> > > > >
> > > > > - const: 19200000
> > > > >
> > > > > > + - description: Must be >= 60 MHz in HS mode, >= 125 MHz
> > > > > > in SS mode.
> > > > > - minimum: 60000000
> > > > > maximum: ?
> > > > Tried as below but facing errors
> > > >
> > > > assigned-clock-rates:
> > > > items:
> > > > - const: 19200000
> > > > - minimum: 60000000
> > > > maximum: 150000000
> > > >
> > > > Errors
> > > >
> > > > linux-next/Documentation/devicetree/bindings/usb/qcom,dwc3.example.dt.yaml:
> > > > usb@a6f8800: assigned-clock-rates: Additional items are not allowed
> > > > ([150000000] was unexpected)
> > > > linux-next/Documentation/devicetree/bindings/usb/qcom,dwc3.example.dt.yaml:
> > > > usb@a6f8800: assigned-clock-rates:0: [19200000] is too short
> > > > linux-next/Documentation/devicetree/bindings/usb/qcom,dwc3.example.dt.yaml:
> > > > usb@a6f8800: assigned-clock-rates: [[19200000], [150000000]] is too long
> > judging from the error messages my uneducated guess is that the above rules for
> > assigned-clock-rates expect a single tuple of two elements, not two tuples with
> > a single element, i.e.
> >
> > assigned-clock-rates = <19200000, 150000000>;
> >
> > instead of
> >
> > assigned-clock-rates = <19200000>, <150000000>;
> >
> > I experimented a bit but couldn't find the magic incantation to appease the
> > schema deities.
> >
> > Rob, could you please help to distentangle this?
> >
> > Thanks
> >
> > Matthias
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
* Re: [PATCH 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
From: kbuild test robot @ 2020-05-13 16:14 UTC (permalink / raw)
To: Vinod Koul, Daniel Vetter, David Airlie, Rob Clark
Cc: kbuild-all, devicetree, Jernej Skrabec, Neil Armstrong,
linux-arm-msm, Jonas Karlman, linux-kernel, dri-devel,
Bjorn Andersson, Andrzej Hajda
In-Reply-To: <20200513100533.42996-4-vkoul@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 10464 bytes --]
Hi Vinod,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on drm-intel/for-linux-next drm-tip/drm-tip linus/master v5.7-rc5 next-20200512]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Vinod-Koul/Add-LT9611-DSI-to-HDMI-bridge/20200513-181150
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=nios2
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/gpu/drm/bridge/lt9611.c: In function 'lt9611_reset':
drivers/gpu/drm/bridge/lt9611.c:518:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
518 | gpiod_set_value_cansleep(lt9611->reset_gpio, 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c: In function 'lt9611_gpio_init':
drivers/gpu/drm/bridge/lt9611.c:963:23: error: implicit declaration of function 'devm_gpiod_get' [-Werror=implicit-function-declaration]
963 | lt9611->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
| ^~~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:963:52: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function)
963 | lt9611->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
| ^~~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:963:52: note: each undeclared identifier is reported only once for each function it appears in
drivers/gpu/drm/bridge/lt9611.c:969:24: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? [-Werror=implicit-function-declaration]
969 | lt9611->enable_gpio = devm_gpiod_get_optional(dev, "enable",
| ^~~~~~~~~~~~~~~~~~~~~~~
| devm_regulator_get_optional
drivers/gpu/drm/bridge/lt9611.c:970:13: error: 'GPIOD_OUT_LOW' undeclared (first use in this function)
970 | GPIOD_OUT_LOW);
| ^~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c: At top level:
drivers/gpu/drm/bridge/lt9611.c:1100:1: warning: data definition has no type or storage class
1100 | MODULE_DEVICE_TABLE(of, lt9611_match_table);
| ^~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1100:1: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
drivers/gpu/drm/bridge/lt9611.c:1100:1: warning: parameter names (without types) in function declaration
In file included from include/linux/device.h:31,
from include/linux/platform_device.h:13,
from drivers/gpu/drm/bridge/lt9611.c:7:
include/linux/device/driver.h:263:1: warning: data definition has no type or storage class
263 | module_init(__driver##_init); | ^~~~~~~~~~~
include/linux/i2c.h:923:2: note: in expansion of macro 'module_driver'
923 | module_driver(__i2c_driver, i2c_add_driver, | ^~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1111:1: note: in expansion of macro 'module_i2c_driver'
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~~~~~
include/linux/device/driver.h:263:1: error: type defaults to 'int' in declaration of 'module_init' [-Werror=implicit-int]
263 | module_init(__driver##_init); | ^~~~~~~~~~~
include/linux/i2c.h:923:2: note: in expansion of macro 'module_driver'
923 | module_driver(__i2c_driver, i2c_add_driver, | ^~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1111:1: note: in expansion of macro 'module_i2c_driver'
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~~~~~
In file included from include/linux/linkage.h:7,
from include/linux/kernel.h:8,
from include/asm-generic/bug.h:19,
from ./arch/nios2/include/generated/asm/bug.h:1,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/current.h:5,
from ./arch/nios2/include/generated/asm/current.h:1,
from include/linux/sched.h:12,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from include/linux/platform_device.h:13,
from drivers/gpu/drm/bridge/lt9611.c:7:
>> include/linux/export.h:19:30: warning: parameter names (without types) in function declaration
19 | #define THIS_MODULE ((struct module *)0)
| ^~~~~~
include/linux/i2c.h:855:22: note: in expansion of macro 'THIS_MODULE'
855 | i2c_register_driver(THIS_MODULE, driver)
| ^~~~~~~~~~~
include/linux/device/driver.h:261:9: note: in expansion of macro 'i2c_add_driver'
261 | return __register(&(__driver) , ##__VA_ARGS__); | ^~~~~~~~~~
include/linux/i2c.h:923:2: note: in expansion of macro 'module_driver'
923 | module_driver(__i2c_driver, i2c_add_driver, | ^~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1111:1: note: in expansion of macro 'module_i2c_driver'
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~~~~~
In file included from include/linux/device.h:31,
from include/linux/platform_device.h:13,
from drivers/gpu/drm/bridge/lt9611.c:7:
include/linux/device/driver.h:268:1: warning: data definition has no type or storage class
268 | module_exit(__driver##_exit);
| ^~~~~~~~~~~
include/linux/i2c.h:923:2: note: in expansion of macro 'module_driver'
923 | module_driver(__i2c_driver, i2c_add_driver, | ^~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1111:1: note: in expansion of macro 'module_i2c_driver'
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~~~~~
include/linux/device/driver.h:268:1: error: type defaults to 'int' in declaration of 'module_exit' [-Werror=implicit-int]
268 | module_exit(__driver##_exit);
| ^~~~~~~~~~~
include/linux/i2c.h:923:2: note: in expansion of macro 'module_driver'
923 | module_driver(__i2c_driver, i2c_add_driver, | ^~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1111:1: note: in expansion of macro 'module_i2c_driver'
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~~~~~
In file included from include/linux/linkage.h:7,
from include/linux/kernel.h:8,
from include/asm-generic/bug.h:19,
from ./arch/nios2/include/generated/asm/bug.h:1,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/current.h:5,
from ./arch/nios2/include/generated/asm/current.h:1,
from include/linux/sched.h:12,
from include/linux/ratelimit.h:6,
from include/linux/dev_printk.h:16,
from include/linux/device.h:15,
from include/linux/platform_device.h:13,
from drivers/gpu/drm/bridge/lt9611.c:7:
>> include/linux/export.h:19:30: warning: parameter names (without types) in function declaration
19 | #define THIS_MODULE ((struct module *)0)
| ^~~~~~
include/linux/i2c.h:855:22: note: in expansion of macro 'THIS_MODULE'
855 | i2c_register_driver(THIS_MODULE, driver)
| ^~~~~~~~~~~
include/linux/device/driver.h:261:9: note: in expansion of macro 'i2c_add_driver'
261 | return __register(&(__driver) , ##__VA_ARGS__); | ^~~~~~~~~~
include/linux/i2c.h:923:2: note: in expansion of macro 'module_driver'
923 | module_driver(__i2c_driver, i2c_add_driver, | ^~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1111:1: note: in expansion of macro 'module_i2c_driver'
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1113:16: error: expected declaration specifiers or '...' before string constant
1113 | MODULE_LICENSE("GPL v2");
| ^~~~~~~~
In file included from include/linux/device.h:31,
from include/linux/platform_device.h:13,
from drivers/gpu/drm/bridge/lt9611.c:7:
drivers/gpu/drm/bridge/lt9611.c:1111:19: warning: 'lt9611_driver_init' defined but not used [-Wunused-function]
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~
include/linux/device/driver.h:259:19: note: in definition of macro 'module_driver'
259 | static int __init __driver##_init(void) | ^~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:1111:1: note: in expansion of macro 'module_i2c_driver'
1111 | module_i2c_driver(lt9611_driver);
| ^~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +19 include/linux/export.h
b67067f1176df6 Nicholas Piggin 2016-08-24 4
f50169324df4ad Paul Gortmaker 2011-05-23 5 /*
f50169324df4ad Paul Gortmaker 2011-05-23 6 * Export symbols from the kernel to modules. Forked from module.h
f50169324df4ad Paul Gortmaker 2011-05-23 7 * to reduce the amount of pointless cruft we feed to gcc when only
f50169324df4ad Paul Gortmaker 2011-05-23 8 * exporting a simple symbol or two.
f50169324df4ad Paul Gortmaker 2011-05-23 9 *
b92021b09df70c Rusty Russell 2013-03-15 10 * Try not to add #includes here. It slows compilation and makes kernel
b92021b09df70c Rusty Russell 2013-03-15 11 * hackers place grumpy comments in header files.
f50169324df4ad Paul Gortmaker 2011-05-23 12 */
f50169324df4ad Paul Gortmaker 2011-05-23 13
b92021b09df70c Rusty Russell 2013-03-15 14 #ifndef __ASSEMBLY__
f50169324df4ad Paul Gortmaker 2011-05-23 15 #ifdef MODULE
f50169324df4ad Paul Gortmaker 2011-05-23 16 extern struct module __this_module;
f50169324df4ad Paul Gortmaker 2011-05-23 17 #define THIS_MODULE (&__this_module)
f50169324df4ad Paul Gortmaker 2011-05-23 18 #else
f50169324df4ad Paul Gortmaker 2011-05-23 @19 #define THIS_MODULE ((struct module *)0)
f50169324df4ad Paul Gortmaker 2011-05-23 20 #endif
f50169324df4ad Paul Gortmaker 2011-05-23 21
:::::: The code at line 19 was first introduced by commit
:::::: f50169324df4ad942e544386d136216c8617636a module.h: split out the EXPORT_SYMBOL into export.h
:::::: TO: Paul Gortmaker <paul.gortmaker@windriver.com>
:::::: CC: Paul Gortmaker <paul.gortmaker@windriver.com>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 55353 bytes --]
^ permalink raw reply
* Re: [PATCH 06/14] arm64: dts: sparx5: Add basic cpu support
From: Marc Zyngier @ 2020-05-13 15:39 UTC (permalink / raw)
To: Lars Povlsen
Cc: SoC Team, Arnd Bergmann, Stephen Boyd, Linus Walleij, devicetree,
Alexandre Belloni, Steen Hegelund, linux-clk, linux-kernel,
Microchip Linux Driver Support, linux-gpio, linux-arm-kernel,
Olof Johansson, Michael Turquette
In-Reply-To: <20200513125532.24585-7-lars.povlsen@microchip.com>
On 2020-05-13 13:55, Lars Povlsen wrote:
> This adds the basic DT structure for the Microchip Sparx5 SoC, and the
> reference boards, pcb125, pcb134 and pcb135. The two latter have a
> NAND vs a eMMC centric variant (as a mount option),
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> MAINTAINERS | 1 +
> arch/arm64/boot/dts/Makefile | 1 +
> arch/arm64/boot/dts/microchip/Makefile | 4 +
> arch/arm64/boot/dts/microchip/sparx5.dtsi | 135 ++++++++++++++++++
> .../boot/dts/microchip/sparx5_pcb125.dts | 17 +++
> .../boot/dts/microchip/sparx5_pcb134.dts | 17 +++
> .../dts/microchip/sparx5_pcb134_board.dtsi | 15 ++
> .../boot/dts/microchip/sparx5_pcb134_emmc.dts | 17 +++
> .../boot/dts/microchip/sparx5_pcb135.dts | 17 +++
> .../dts/microchip/sparx5_pcb135_board.dtsi | 15 ++
> .../boot/dts/microchip/sparx5_pcb135_emmc.dts | 17 +++
> .../boot/dts/microchip/sparx5_pcb_common.dtsi | 15 ++
> 12 files changed, 271 insertions(+)
> create mode 100644 arch/arm64/boot/dts/microchip/Makefile
> create mode 100644 arch/arm64/boot/dts/microchip/sparx5.dtsi
> create mode 100644 arch/arm64/boot/dts/microchip/sparx5_pcb125.dts
> create mode 100644 arch/arm64/boot/dts/microchip/sparx5_pcb134.dts
> create mode 100644
> arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
> create mode 100644
> arch/arm64/boot/dts/microchip/sparx5_pcb134_emmc.dts
> create mode 100644 arch/arm64/boot/dts/microchip/sparx5_pcb135.dts
> create mode 100644
> arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
> create mode 100644
> arch/arm64/boot/dts/microchip/sparx5_pcb135_emmc.dts
> create mode 100644
> arch/arm64/boot/dts/microchip/sparx5_pcb_common.dtsi
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1b5a18d3dbb9f..5aa28d6e39d4f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2084,6 +2084,7 @@ M: Lars Povlsen <lars.povlsen@microchip.com>
> M: Steen Hegelund <Steen.Hegelund@microchip.com>
> M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for
> non-subscribers)
> +F: arch/arm64/boot/dts/microchip/
> N: sparx5
> S: Supported
>
> diff --git a/arch/arm64/boot/dts/Makefile
> b/arch/arm64/boot/dts/Makefile
> index f19b762c008d8..9680a7f20c307 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -17,6 +17,7 @@ subdir-y += intel
> subdir-y += lg
> subdir-y += marvell
> subdir-y += mediatek
> +subdir-y += microchip
> subdir-y += nvidia
> subdir-y += qcom
> subdir-y += realtek
> diff --git a/arch/arm64/boot/dts/microchip/Makefile
> b/arch/arm64/boot/dts/microchip/Makefile
> new file mode 100644
> index 0000000000000..c6e0313eea0f9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/microchip/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb125.dtb
> +dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb134.dtb sparx5_pcb134_emmc.dtb
> +dtb-$(CONFIG_ARCH_SPARX5) += sparx5_pcb135.dtb sparx5_pcb135_emmc.dtb
> diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
> b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> new file mode 100644
> index 0000000000000..3136b4369f507
> --- /dev/null
> +++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
> @@ -0,0 +1,135 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2020 Microchip Technology Inc. and its subsidiaries.
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + compatible = "microchip,sparx5";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> + };
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <0x0 0x0>;
> + enable-method = "spin-table";
Really? This is 2020, not 2012 any more. Surely a new platform
boots using PSCI, and not *this*.
> + cpu-release-addr = <0x0 0x0000fff8>;
> + next-level-cache = <&L2_0>;
> + };
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53", "arm,armv8";
> + device_type = "cpu";
> + reg = <0x0 0x1>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x0 0x0000fff8>;
> + next-level-cache = <&L2_0>;
> + };
> + L2_0: l2-cache0 {
> + compatible = "cache";
> + };
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts =
> + <GIC_PPI 13
> + (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14
> + (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11
> + (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10
> + (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
You have a GICv3. These interrupt specifiers are not the ones GICv3
expects.
> + };
> +
> + clocks: clocks {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges;
> + ahb_clk: ahb-clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <250000000>;
> + };
> + sys_clk: sys-clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <625000000>;
> + };
> + };
> +
> + axi: axi@600000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges;
> +
> + gic: interrupt-controller@600300000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-controller;
> + reg = <0x6 0x00300000 0x20000>, /* GICD */
> + <0x6 0x00340000 0x1000000>; /* GICR */
You are missing the GICv3 compatibility interfaces (GICV/GICH), which
are implemented by the CPUs.
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + uart0: serial@600100000 {
> + compatible = "ns16550a";
> + reg = <0x6 0x00100000 0x20>;
> + clocks = <&ahb_clk>;
> + reg-io-width = <4>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + uart1: serial@600102000 {
> + compatible = "ns16550a";
> + reg = <0x6 0x00102000 0x20>;
> + clocks = <&ahb_clk>;
> + reg-io-width = <4>;
> + reg-shift = <2>;
> + interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
> +
> + status = "disabled";
> + };
> +
> + timer1: timer@600105000 {
> + compatible = "snps,dw-apb-timer";
> + reg = <0x6 0x00105000 0x1000>;
> + clocks = <&ahb_clk>;
> + clock-names = "timer";
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + };
> +};
Where is the PMU node?
Thanks,
M.
--
Who you jivin' with that Cosmik Debris?
^ permalink raw reply
* Re: [PATCH v2] arm: dts: Move am33xx and am43xx mmc nodes to sdhci-omap driver
From: Tony Lindgren @ 2020-05-13 16:23 UTC (permalink / raw)
To: Keerthy; +Cc: linux-kernel, devicetree, linux-omap, robh+dt, bcousson,
Faiz Abbas
In-Reply-To: <20200512203804.9340-1-faiz_abbas@ti.com>
* Faiz Abbas <faiz_abbas@ti.com> [200512 13:39]:
> Move mmc nodes to be compatible with the sdhci-omap driver. The following
> modifications are required for omap_hsmmc specific properties:
>
> ti,non-removable: convert to the generic mmc non-removable
> ti,needs-special-reset: co-opted into the sdhci-omap driver
> ti,dual-volt: removed. Legacy property not used in am335x or am43xx
> ti,needs-special-hs-handling: removed. Legacy property not used in am335x
> or am43xx
>
> Also since the sdhci-omap driver does not support runtime PM, explicitly
> disable the mmc3 instance in the dtsi.
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
>
> v2: Rebased to latest mainline where all kernel dependancies have been merged.
>
> Suspend/Resume is now supported in the sdhci-omap driver.
Great, thanks for updating it.
Keerthy, care to test for am3 and am4?
Regards,
Tony
> Tested on: am335x-evm, am335x-boneblack, am335x-sk, am335x-bone, am437x-idk,
> am43xx-gp-evm, am43xx-epos-evm.
>
> arch/arm/boot/dts/am335x-baltos.dtsi | 2 +-
> arch/arm/boot/dts/am335x-boneblack-common.dtsi | 1 +
> arch/arm/boot/dts/am335x-boneblack-wireless.dts | 1 -
> arch/arm/boot/dts/am335x-boneblue.dts | 1 -
> arch/arm/boot/dts/am335x-bonegreen-wireless.dts | 1 -
> arch/arm/boot/dts/am335x-evm.dts | 3 +--
> arch/arm/boot/dts/am335x-evmsk.dts | 2 +-
> arch/arm/boot/dts/am335x-lxm.dts | 2 +-
> arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi | 2 +-
> arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts | 2 +-
> arch/arm/boot/dts/am335x-pepper.dts | 4 ++--
> arch/arm/boot/dts/am335x-phycore-som.dtsi | 2 +-
> arch/arm/boot/dts/am33xx-l4.dtsi | 6 ++----
> arch/arm/boot/dts/am33xx.dtsi | 3 ++-
> arch/arm/boot/dts/am4372.dtsi | 3 ++-
> arch/arm/boot/dts/am437x-cm-t43.dts | 2 +-
> arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++--
> arch/arm/boot/dts/am437x-l4.dtsi | 5 ++---
> arch/arm/boot/dts/am437x-sk-evm.dts | 2 +-
> 19 files changed, 22 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
> index 05e7b5d4a95b..04f0b1227efe 100644
> --- a/arch/arm/boot/dts/am335x-baltos.dtsi
> +++ b/arch/arm/boot/dts/am335x-baltos.dtsi
> @@ -369,7 +369,7 @@
> &mmc2 {
> status = "okay";
> vmmc-supply = <&wl12xx_vmmc>;
> - ti,non-removable;
> + non-removable;
> bus-width = <4>;
> cap-power-off-card;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/am335x-boneblack-common.dtsi b/arch/arm/boot/dts/am335x-boneblack-common.dtsi
> index 91f93bc89716..dd932220a8bf 100644
> --- a/arch/arm/boot/dts/am335x-boneblack-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-boneblack-common.dtsi
> @@ -22,6 +22,7 @@
> pinctrl-0 = <&emmc_pins>;
> bus-width = <8>;
> status = "okay";
> + non-removable;
> };
>
> &am33xx_pinmux {
> diff --git a/arch/arm/boot/dts/am335x-boneblack-wireless.dts b/arch/arm/boot/dts/am335x-boneblack-wireless.dts
> index 3124d94c0b3c..e07dd7979586 100644
> --- a/arch/arm/boot/dts/am335x-boneblack-wireless.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack-wireless.dts
> @@ -75,7 +75,6 @@
> bus-width = <4>;
> non-removable;
> cap-power-off-card;
> - ti,needs-special-hs-handling;
> keep-power-in-suspend;
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins &wl18xx_pins>;
> diff --git a/arch/arm/boot/dts/am335x-boneblue.dts b/arch/arm/boot/dts/am335x-boneblue.dts
> index 5811fb8d4fdf..83f9452c9cd3 100644
> --- a/arch/arm/boot/dts/am335x-boneblue.dts
> +++ b/arch/arm/boot/dts/am335x-boneblue.dts
> @@ -367,7 +367,6 @@
> bus-width = <4>;
> non-removable;
> cap-power-off-card;
> - ti,needs-special-hs-handling;
> keep-power-in-suspend;
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins &wl18xx_pins>;
> diff --git a/arch/arm/boot/dts/am335x-bonegreen-wireless.dts b/arch/arm/boot/dts/am335x-bonegreen-wireless.dts
> index 4092cd193b8a..609c8db687ec 100644
> --- a/arch/arm/boot/dts/am335x-bonegreen-wireless.dts
> +++ b/arch/arm/boot/dts/am335x-bonegreen-wireless.dts
> @@ -75,7 +75,6 @@
> bus-width = <4>;
> non-removable;
> cap-power-off-card;
> - ti,needs-special-hs-handling;
> keep-power-in-suspend;
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins &wl18xx_pins>;
> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
> index 68252dab32c3..a4fc6b168a85 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -743,8 +743,7 @@
> bus-width = <4>;
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins &wlan_pins>;
> - ti,non-removable;
> - ti,needs-special-hs-handling;
> + non-removable;
> cap-power-off-card;
> keep-power-in-suspend;
>
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts b/arch/arm/boot/dts/am335x-evmsk.dts
> index 32f515a295ee..78b6e1f594c9 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -655,7 +655,7 @@
> &mmc2 {
> status = "okay";
> vmmc-supply = <&wl12xx_vmmc>;
> - ti,non-removable;
> + non-removable;
> bus-width = <4>;
> cap-power-off-card;
> keep-power-in-suspend;
> diff --git a/arch/arm/boot/dts/am335x-lxm.dts b/arch/arm/boot/dts/am335x-lxm.dts
> index fef582852820..dbedf729205c 100644
> --- a/arch/arm/boot/dts/am335x-lxm.dts
> +++ b/arch/arm/boot/dts/am335x-lxm.dts
> @@ -339,7 +339,7 @@
> pinctrl-0 = <&emmc_pins>;
> vmmc-supply = <&vmmcsd_fixed>;
> bus-width = <8>;
> - ti,non-removable;
> + non-removable;
> status = "okay";
> };
>
> diff --git a/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
> index 6495a125c01f..4e90f9c23d2e 100644
> --- a/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-moxa-uc-2100-common.dtsi
> @@ -159,7 +159,7 @@
> vmmc-supply = <&vmmcsd_fixed>;
> bus-width = <8>;
> pinctrl-0 = <&mmc1_pins_default>;
> - ti,non-removable;
> + non-removable;
> status = "okay";
> };
>
> diff --git a/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts b/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts
> index 244df9c5a537..f03e72cada41 100644
> --- a/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts
> +++ b/arch/arm/boot/dts/am335x-moxa-uc-8100-me-t.dts
> @@ -451,7 +451,7 @@
> vmmc-supply = <&vmmcsd_fixed>;
> bus-width = <8>;
> pinctrl-0 = <&mmc2_pins_default>;
> - ti,non-removable;
> + non-removable;
> status = "okay";
> };
>
> diff --git a/arch/arm/boot/dts/am335x-pepper.dts b/arch/arm/boot/dts/am335x-pepper.dts
> index 6d7608d9377b..f9a027b47962 100644
> --- a/arch/arm/boot/dts/am335x-pepper.dts
> +++ b/arch/arm/boot/dts/am335x-pepper.dts
> @@ -341,7 +341,7 @@
> pinctrl-0 = <&emmc_pins>;
> vmmc-supply = <&ldo3_reg>;
> bus-width = <8>;
> - ti,non-removable;
> + non-removable;
> };
>
> &mmc3 {
> @@ -351,7 +351,7 @@
> pinctrl-0 = <&wireless_pins>;
> vmmmc-supply = <&v3v3c_reg>;
> bus-width = <4>;
> - ti,non-removable;
> + non-removable;
> dmas = <&edma_xbar 12 0 1
> &edma_xbar 13 0 2>;
> dma-names = "tx", "rx";
> diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> index 3d0672b53d77..7e46b4c02709 100644
> --- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
> +++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
> @@ -69,7 +69,7 @@
> pinctrl-0 = <&emmc_pins>;
> vmmc-supply = <&vmmc_reg>;
> bus-width = <8>;
> - ti,non-removable;
> + non-removable;
> status = "disabled";
> };
>
> diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
> index 5ed7f3c58c0f..573ff076178b 100644
> --- a/arch/arm/boot/dts/am33xx-l4.dtsi
> +++ b/arch/arm/boot/dts/am33xx-l4.dtsi
> @@ -1337,10 +1337,8 @@
> ranges = <0x0 0x60000 0x1000>;
>
> mmc1: mmc@0 {
> - compatible = "ti,omap4-hsmmc";
> - ti,dual-volt;
> + compatible = "ti,am335-sdhci";
> ti,needs-special-reset;
> - ti,needs-special-hs-handling;
> dmas = <&edma_xbar 24 0 0
> &edma_xbar 25 0 0>;
> dma-names = "tx", "rx";
> @@ -1818,7 +1816,7 @@
> ranges = <0x0 0xd8000 0x1000>;
>
> mmc2: mmc@0 {
> - compatible = "ti,omap4-hsmmc";
> + compatible = "ti,am335-sdhci";
> ti,needs-special-reset;
> dmas = <&edma 2 0
> &edma 3 0>;
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index a35f5052d76f..3b9d4d2d35bf 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -322,10 +322,11 @@
> ranges = <0x0 0x47810000 0x1000>;
>
> mmc3: mmc@0 {
> - compatible = "ti,omap4-hsmmc";
> + compatible = "ti,am335-sdhci";
> ti,needs-special-reset;
> interrupts = <29>;
> reg = <0x0 0x1000>;
> + status = "disabled";
> };
> };
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index dba87bfaf33e..092b3d4404f4 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -316,10 +316,11 @@
> ranges = <0x0 0x47810000 0x1000>;
>
> mmc3: mmc@0 {
> - compatible = "ti,omap4-hsmmc";
> + compatible = "ti,am437-sdhci";
> ti,needs-special-reset;
> interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>;
> reg = <0x0 0x1000>;
> + status = "disabled";
> };
> };
>
> diff --git a/arch/arm/boot/dts/am437x-cm-t43.dts b/arch/arm/boot/dts/am437x-cm-t43.dts
> index 063113a5da2d..a6b4fca8626a 100644
> --- a/arch/arm/boot/dts/am437x-cm-t43.dts
> +++ b/arch/arm/boot/dts/am437x-cm-t43.dts
> @@ -291,7 +291,7 @@
> pinctrl-0 = <&emmc_pins>;
> vmmc-supply = <&vmmc_3v3>;
> bus-width = <8>;
> - ti,non-removable;
> + non-removable;
> };
>
> &spi0 {
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 811c8cae315b..cadf47ee337f 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -869,7 +869,7 @@
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <&emmc_pins_default>;
> pinctrl-1 = <&emmc_pins_sleep>;
> - ti,non-removable;
> + non-removable;
> };
>
> &mmc3 {
> @@ -886,7 +886,7 @@
> pinctrl-1 = <&mmc3_pins_sleep>;
> cap-power-off-card;
> keep-power-in-suspend;
> - ti,non-removable;
> + non-removable;
>
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
> index 49c6a872052e..f4eb36d8b660 100644
> --- a/arch/arm/boot/dts/am437x-l4.dtsi
> +++ b/arch/arm/boot/dts/am437x-l4.dtsi
> @@ -1086,9 +1086,8 @@
> ranges = <0x0 0x60000 0x1000>;
>
> mmc1: mmc@0 {
> - compatible = "ti,omap4-hsmmc";
> + compatible = "ti,am437-sdhci";
> reg = <0x0 0x1000>;
> - ti,dual-volt;
> ti,needs-special-reset;
> dmas = <&edma 24 0>,
> <&edma 25 0>;
> @@ -1601,7 +1600,7 @@
> ranges = <0x0 0xd8000 0x1000>;
>
> mmc2: mmc@0 {
> - compatible = "ti,omap4-hsmmc";
> + compatible = "ti,am437-sdhci";
> reg = <0x0 0x1000>;
> ti,needs-special-reset;
> dmas = <&edma 2 0>,
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts b/arch/arm/boot/dts/am437x-sk-evm.dts
> index 25222497f828..2416597a4f5c 100644
> --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -719,7 +719,7 @@
> pinctrl-1 = <&mmc3_pins_sleep>;
> cap-power-off-card;
> keep-power-in-suspend;
> - ti,non-removable;
> + non-removable;
>
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Greg Kroah-Hartman @ 2020-05-13 16:27 UTC (permalink / raw)
To: Florian Fainelli
Cc: Al Cooper, linux-kernel, Alan Stern, Andy Shevchenko,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda,
Andy Shevchenko
In-Reply-To: <7acc2a4c-caab-11e7-7b3f-4176f19c58cf@gmail.com>
On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>
>
> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> > On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >> devices and OHCI handles <2.0 devices. Currently the Makefile
> >> has XHCI linking at the bottom which will result in the XHIC driver
> >> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >> device will be seen as a 2.0 device. Moving the XHCI linking
> >> above the EHCI and OHCI linking fixes the issue.
> >
> > What happens if all of these are modules and they are loaded in a
> > different order? This makefile change will not help with that, you need
> > to have logic in the code in order to properly coordinate this type of
> > mess, sorry.
>
> I believe we should be using module soft dependencies to instruct the
> module loaders to load the modules in the correct order, so something
> like this would do (not tested) for xhci-plat-hcd.c:
>
> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>
> and I am not sure whether we need to add the opposite for ehci-hcd and
> ohci-hcd:
>
> MODULE_SOFTDEP("pre: xhci-plat-hcd");
That's a nice start, but what happens if that isn't honored? This
really needs to work properly for any order as you never can guarantee
module/driver loading order in a system of modules.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Florian Fainelli @ 2020-05-13 16:31 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Al Cooper, linux-kernel, Alan Stern, Andy Shevchenko,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda,
Andy Shevchenko
In-Reply-To: <20200513162723.GF1362525@kroah.com>
On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
>>
>>
>> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
>>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
>>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
>>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
>>>> devices and OHCI handles <2.0 devices. Currently the Makefile
>>>> has XHCI linking at the bottom which will result in the XHIC driver
>>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
>>>> device will be seen as a 2.0 device. Moving the XHCI linking
>>>> above the EHCI and OHCI linking fixes the issue.
>>>
>>> What happens if all of these are modules and they are loaded in a
>>> different order? This makefile change will not help with that, you need
>>> to have logic in the code in order to properly coordinate this type of
>>> mess, sorry.
>>
>> I believe we should be using module soft dependencies to instruct the
>> module loaders to load the modules in the correct order, so something
>> like this would do (not tested) for xhci-plat-hcd.c:
>>
>> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
>>
>> and I am not sure whether we need to add the opposite for ehci-hcd and
>> ohci-hcd:
>>
>> MODULE_SOFTDEP("pre: xhci-plat-hcd");
>
> That's a nice start, but what happens if that isn't honored? This
> really needs to work properly for any order as you never can guarantee
> module/driver loading order in a system of modules.
I also suggested that device links may help, though I am not sure. What
do you suggest to be done?
--
Florian
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: disable the new cti nodes on devices with broken coresight
From: Michael Srba @ 2020-05-13 16:42 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: Andy Gross, Bjorn Andersson, Rob Herring, Mathieu Poirier,
Suzuki K Poulose, Mike Leach, MSM, DTML, lkml,
~postmarketos/upstreaming
In-Reply-To: <CAOCk7No3bJMpZNjXaNv-OScaLXPKbdj3d_n20ss3MyciPO=e3g@mail.gmail.com>
On 13. 05. 20 18:04, Jeffrey Hugo wrote:
> On Wed, May 13, 2020 at 9:53 AM <michael.srba@seznam.cz> wrote:
>> From: Michael Srba <michael.srba@seznam.cz>
>>
>> Attempting to enable these devices causes a "synchronous
>> external abort". Suspected cause is that the debug power
>> domain is not enabled by default on this device.
>> Disable these devices for now to avoid the crash.
>>
>> See: https://lore.kernel.org/linux-arm-msm/20190618202623.GA53651@gerhold.net/
>>
>> Fixes: b1fcc5702a41 ("arm64: dts: qcom: msm8916: Add CTI options")
>> Signed-off-by: Michael Srba <michael.srba@seznam.cz>
>>
>> ---
>> arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts | 6 ++++++
>> arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi | 6 ++++++
>> 2 files changed, 12 insertions(+)
> Why are we disabling these in board specific files? Seems like these
> should be disabled in the base msm8916.dtsi. Otherwise, the next
> board that gets brought up is probably going to hit this same exact
> issue.
>
> This also follows the solution that msm8998 did for the same issue.
I would also advocate for having them disabled by default. I *think* it was
brought up initially, but that would be before the msm8998 change.
^ permalink raw reply
* [PATCH v2] video: fbdev: ssd1307fb: Added support to Column offset
From: Rodrigo Rolim Mendes de Alencar @ 2020-05-13 16:56 UTC (permalink / raw)
To: linux-fbdev
Cc: linux-kernel, b.zolnierkie, andy.shevchenko, devicetree,
Rodrigo Rolim Mendes de Alencar, Rodrigo Alencar
This patch provides support for displays like VGM128064B0W10,
which requires a column offset of 2, i.e., its segments starts
in SEG2 and ends in SEG129.
Signed-off-by: Rodrigo Alencar <455.rodrigo.alencar@gmail.com>
---
Documentation/devicetree/bindings/display/ssd1307fb.txt | 1 +
drivers/video/fbdev/ssd1307fb.c | 8 ++++++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt
index 27333b9551b3..2dcb6d12d137 100644
--- a/Documentation/devicetree/bindings/display/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt
@@ -19,6 +19,7 @@ Optional properties:
- vbat-supply: The supply for VBAT
- solomon,segment-no-remap: Display needs normal (non-inverted) data column
to segment mapping
+ - solomon,col-offset: Offset of columns (COL/SEG) that the screen is mapped to.
- solomon,com-seq: Display uses sequential COM pin configuration
- solomon,com-lrremap: Display uses left-right COM pin remap
- solomon,com-invdir: Display uses inverted COM pin scan direction
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 8e06ba912d60..f135b2959f87 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -74,6 +74,7 @@ struct ssd1307fb_par {
struct fb_info *info;
u8 lookup_table[4];
u32 page_offset;
+ u32 col_offset;
u32 prechargep1;
u32 prechargep2;
struct pwm_device *pwm;
@@ -458,11 +459,11 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, 0x0);
+ ret = ssd1307fb_write_cmd(par->client, par->col_offset);
if (ret < 0)
return ret;
- ret = ssd1307fb_write_cmd(par->client, par->width - 1);
+ ret = ssd1307fb_write_cmd(par->client, par->col_offset + par->width - 1);
if (ret < 0)
return ret;
@@ -626,6 +627,9 @@ static int ssd1307fb_probe(struct i2c_client *client)
if (device_property_read_u32(dev, "solomon,page-offset", &par->page_offset))
par->page_offset = 1;
+ if (device_property_read_u32(node, "solomon,col-offset", &par->col_offset))
+ par->col_offset = 0;
+
if (device_property_read_u32(dev, "solomon,com-offset", &par->com_offset))
par->com_offset = 0;
--
2.23.0.rc1
^ permalink raw reply related
* Re: [PATCH 3/3] drm/bridge: Introduce LT9611 DSI to HDMI bridge
From: kbuild test robot @ 2020-05-13 16:46 UTC (permalink / raw)
To: Vinod Koul, Daniel Vetter, David Airlie, Rob Clark
Cc: kbuild-all, devicetree, Jernej Skrabec, Neil Armstrong,
linux-arm-msm, Jonas Karlman, linux-kernel, dri-devel,
Bjorn Andersson, Andrzej Hajda
In-Reply-To: <20200513100533.42996-4-vkoul@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2930 bytes --]
Hi Vinod,
I love your patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip linus/master v5.7-rc5 next-20200512]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Vinod-Koul/Add-LT9611-DSI-to-HDMI-bridge/20200513-181150
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/gpu/drm/bridge/lt9611.c: In function 'lt9611_reset':
>> drivers/gpu/drm/bridge/lt9611.c:518:2: error: implicit declaration of function 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration]
gpiod_set_value_cansleep(lt9611->reset_gpio, 1);
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c: In function 'lt9611_gpio_init':
>> drivers/gpu/drm/bridge/lt9611.c:963:23: error: implicit declaration of function 'devm_gpiod_get'; did you mean 'devm_iounmap'? [-Werror=implicit-function-declaration]
lt9611->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
^~~~~~~~~~~~~~
devm_iounmap
>> drivers/gpu/drm/bridge/lt9611.c:963:52: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function)
lt9611->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
^~~~~~~~~~~~~~
drivers/gpu/drm/bridge/lt9611.c:963:52: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/gpu/drm/bridge/lt9611.c:969:24: error: implicit declaration of function 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? [-Werror=implicit-function-declaration]
lt9611->enable_gpio = devm_gpiod_get_optional(dev, "enable",
^~~~~~~~~~~~~~~~~~~~~~~
devm_regulator_get_optional
>> drivers/gpu/drm/bridge/lt9611.c:970:13: error: 'GPIOD_OUT_LOW' undeclared (first use in this function); did you mean 'GPIOD_OUT_HIGH'?
GPIOD_OUT_LOW);
^~~~~~~~~~~~~
GPIOD_OUT_HIGH
cc1: some warnings being treated as errors
vim +/gpiod_set_value_cansleep +518 drivers/gpu/drm/bridge/lt9611.c
515
516 static void lt9611_reset(struct lt9611 *lt9611)
517 {
> 518 gpiod_set_value_cansleep(lt9611->reset_gpio, 1);
519 msleep(20);
520 gpiod_set_value_cansleep(lt9611->reset_gpio, 0);
521 msleep(20);
522 gpiod_set_value_cansleep(lt9611->reset_gpio, 1);
523 msleep(100);
524 }
525
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 72238 bytes --]
^ permalink raw reply
* Re: [PATCH v3 02/20] arm64: dts: arm: Fix node address fields
From: Sudeep Holla @ 2020-05-13 17:01 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Lorenzo Pieralisi, devicetree,
linux-arm-kernel, Sudeep Holla, Mark Rutland
In-Reply-To: <20200513103016.130417-3-andre.przywara@arm.com>
On Wed, May 13, 2020 at 11:29:58AM +0100, Andre Przywara wrote:
> The Arm Ltd. boards were using an outdated address convention in the DT
> node names, by separating the high from the low 32-bits of an address by
> a comma.
>
> Remove the comma from the node name suffix to be DT spec compliant.
>
As Robin pointed out before, this was the requirement back then. I assume
it is no longer true.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v10 1/5] usb: xhci: Change the XHCI link order in the Makefile
From: Greg Kroah-Hartman @ 2020-05-13 17:05 UTC (permalink / raw)
To: Florian Fainelli
Cc: Al Cooper, linux-kernel, Alan Stern, Andy Shevchenko,
bcm-kernel-feedback-list, devicetree, Krzysztof Kozlowski,
linux-usb, Mathias Nyman, Rob Herring, Yoshihiro Shimoda,
Andy Shevchenko
In-Reply-To: <38ff034d-a84c-2309-a8d5-f344930d9a31@gmail.com>
On Wed, May 13, 2020 at 09:31:11AM -0700, Florian Fainelli wrote:
>
>
> On 5/13/2020 9:27 AM, Greg Kroah-Hartman wrote:
> > On Wed, May 13, 2020 at 08:08:07AM -0700, Florian Fainelli wrote:
> >>
> >>
> >> On 5/13/2020 5:26 AM, Greg Kroah-Hartman wrote:
> >>> On Tue, May 12, 2020 at 11:00:15AM -0400, Al Cooper wrote:
> >>>> Some BRCMSTB USB chips have an XHCI, EHCI and OHCI controller
> >>>> on the same port where XHCI handles 3.0 devices, EHCI handles 2.0
> >>>> devices and OHCI handles <2.0 devices. Currently the Makefile
> >>>> has XHCI linking at the bottom which will result in the XHIC driver
> >>>> initalizing after the EHCI and OHCI drivers and any installed 3.0
> >>>> device will be seen as a 2.0 device. Moving the XHCI linking
> >>>> above the EHCI and OHCI linking fixes the issue.
> >>>
> >>> What happens if all of these are modules and they are loaded in a
> >>> different order? This makefile change will not help with that, you need
> >>> to have logic in the code in order to properly coordinate this type of
> >>> mess, sorry.
> >>
> >> I believe we should be using module soft dependencies to instruct the
> >> module loaders to load the modules in the correct order, so something
> >> like this would do (not tested) for xhci-plat-hcd.c:
> >>
> >> MODULE_SOFTDEP("post: ehci-hcd ohci-hcd");
> >>
> >> and I am not sure whether we need to add the opposite for ehci-hcd and
> >> ohci-hcd:
> >>
> >> MODULE_SOFTDEP("pre: xhci-plat-hcd");
> >
> > That's a nice start, but what happens if that isn't honored? This
> > really needs to work properly for any order as you never can guarantee
> > module/driver loading order in a system of modules.
>
> I also suggested that device links may help, though I am not sure. What
> do you suggest to be done?
No idea. device links will help if you defer the probe properly until
you see the proper drivers binding correctly.
good luck!
greg k-h
^ permalink raw reply
* Re: [PATCH v2] video: fbdev: ssd1307fb: Added support to Column offset
From: Andy Shevchenko @ 2020-05-13 17:13 UTC (permalink / raw)
To: Rodrigo Rolim Mendes de Alencar
Cc: linux-fbdev, Linux Kernel Mailing List, Bartlomiej Zolnierkiewicz,
devicetree, Rodrigo Rolim Mendes de Alencar
In-Reply-To: <1589388975-15499-1-git-send-email-alencar.fmce@imbel.gov.br>
On Wed, May 13, 2020 at 7:56 PM Rodrigo Rolim Mendes de Alencar
<455.rodrigo.alencar@gmail.com> wrote:
>
> This patch provides support for displays like VGM128064B0W10,
> which requires a column offset of 2, i.e., its segments starts
> in SEG2 and ends in SEG129.
Also, include Rob as well into Cc.
...
> + if (device_property_read_u32(node, "solomon,col-offset", &par->col_offset))
> + par->col_offset = 0;
> +
> if (device_property_read_u32(dev, "solomon,com-offset", &par->com_offset))
> par->com_offset = 0;
Have you ever compile it?
--
With Best Regards,
Andy Shevchenko
^ 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