* Re: [PATCH 1/3] dt-bindings: pinctrl: Add bindings for mscc,ocelot-sgpio
From: Linus Walleij @ 2020-05-26 9:20 UTC (permalink / raw)
To: Lars Povlsen
Cc: SoC Team, Rob Herring, Microchip Linux Driver Support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Linux ARM, linux-kernel@vger.kernel.org,
Alexandre Belloni
In-Reply-To: <87r1v8oz9f.fsf@soft-dev15.microsemi.net>
On Mon, May 25, 2020 at 4:38 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> Yes, the problem is they're not in sequence. F.ex. you could have ports
> 0,1 enabled, skip 2,3,4 and have 5,6,7 enabled.
Just use disabled nodes.
That would look like this in my idea of a device tree:
pinctrl@nnn {
gpio0: gpio@0 {
compatible = "foo";
status = "ok";
....
};
gpio1: gpio@1 {
compatible = "foo";
status = "ok";
....
};
gpio2: gpio@2 {
compatible = "foo";
status = "disabled";
....
};
gpio3: gpio@3 {
compatible = "foo";
status = "disabled";
....
};
gpio4: gpio@4 {
compatible = "foo";
status = "disabled";
....
};
gpio5: gpio@5 {
compatible = "foo";
status = "ok";
....
};
gpio6: gpio@6 {
compatible = "foo";
status = "ok";
....
};
gpio7: gpio@7 {
compatible = "foo";
status = "ok";
....
};
};
It is common to use the status to enable/disable nodes like this.
In the Linux kernel is is possible to iterate over these subnodes and
check which ones are enabled and disabled while keeping the
index by using something like:
i = 0;
struct device_node *np, *child;
for_each_child_of_node(np, child) {
if (of_device_is_available(child)) {
pr_info("populating device %d\n", i);
}
i++;
}
Certainly you can use i in the above loop to populate your registers
etc from an indexed array.
This way the consumers can pick their GPIO from the right port
and everything just using e.g.
my-gpios = <&gpio6 4 GPIO_OUT_LOW>;
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v11 0/5] Loongson Generic PCI v11
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200427060551.1372591-1-jiaxun.yang@flygoat.com>
v11 fixes a minor style issue in patch 2.
Now it have got enough ack,
Thomas, cloud you please apply it to mips-next?
Thanks.
Jiaxun Yang (5):
PCI: Don't disable decoding when mmio_always_on is set
PCI: Add Loongson PCI Controller support
dt-bindings: Document Loongson PCI Host Controller
MIPS: DTS: Loongson64: Add PCI Controller Node
MIPS: Loongson64: Switch to generic PCI driver
.../devicetree/bindings/pci/loongson.yaml | 62 +++++
arch/mips/Kconfig | 1 +
arch/mips/boot/dts/loongson/rs780e-pch.dtsi | 12 +
arch/mips/loongson64/Makefile | 2 +-
arch/mips/loongson64/vbios_quirk.c | 29 ++
arch/mips/pci/Makefile | 1 -
arch/mips/pci/fixup-loongson3.c | 71 -----
arch/mips/pci/ops-loongson3.c | 116 --------
drivers/pci/controller/Kconfig | 10 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pci-loongson.c | 247 ++++++++++++++++++
drivers/pci/probe.c | 2 +-
12 files changed, 364 insertions(+), 190 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/loongson.yaml
create mode 100644 arch/mips/loongson64/vbios_quirk.c
delete mode 100644 arch/mips/pci/fixup-loongson3.c
delete mode 100644 arch/mips/pci/ops-loongson3.c
create mode 100644 drivers/pci/controller/pci-loongson.c
--
2.27.0.rc0
^ permalink raw reply
* [PATCH v11 1/5] PCI: Don't disable decoding when mmio_always_on is set
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
Don't disable MEM/IO decoding when a device have both non_compliant_bars
and mmio_always_on.
That would allow us quirk devices with junk in BARs but can't disable
their decoding.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Acked-by: Bjorn Helgaas <helgaas@kernel.org>
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 77b8a145c39b..d9c2c3301a8a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1822,7 +1822,7 @@ int pci_setup_device(struct pci_dev *dev)
/* Device class may be changed after fixup */
class = dev->class >> 8;
- if (dev->non_compliant_bars) {
+ if (dev->non_compliant_bars && !dev->mmio_always_on) {
pci_read_config_word(dev, PCI_COMMAND, &cmd);
if (cmd & (PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) {
pci_info(dev, "device has non-compliant BARs; disabling IO/MEM decoding\n");
--
2.27.0.rc0
^ permalink raw reply related
* Re: [PATCH v6 3/5] dt-bindings: iio: magnetometer: ak8975: add gpio reset support
From: Linus Walleij @ 2020-05-26 9:22 UTC (permalink / raw)
To: Jonathan Albrieux
Cc: linux-kernel@vger.kernel.org, ~postmarketos/upstreaming,
Andy Shevchenko,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Hartmut Knaack, Jonathan Cameron, Lars-Peter Clausen,
open list:IIO SUBSYSTEM AND DRIVERS, Peter Meerwald-Stadler,
Jonathan Cameron, Rob Herring
In-Reply-To: <20200525151117.32540-4-jonathan.albrieux@gmail.com>
On Mon, May 25, 2020 at 5:13 PM Jonathan Albrieux
<jonathan.albrieux@gmail.com> wrote:
> Add reset-gpio support.
>
> Without reset's deassertion during ak8975_power_on(), driver's probe fails
> on ak8975_who_i_am() while checking for device identity for AK09911 chip.
>
> AK09911 has an active low reset gpio to handle register's reset.
> AK09911 datasheet says that, if not used, reset pin should be connected
> to VID. This patch emulates this situation.
>
> Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v11 2/5] PCI: Add Loongson PCI Controller support
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Rob Herring, Lorenzo Pieralisi, Bjorn Helgaas,
Rob Herring, Thomas Bogendoerfer, Huacai Chen, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
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>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
--
v2:
- Clean up according to rob's suggestions
- Claim that it can't work as a module
v3:
- Fix a typo
v4:
- More clean-ups: Drop flag check, use devfn
v7:
- Fix ordering according to huacai's suggestion
v8:
- Style clean and bugfix according to Bjorn's review
v9:
- Confirm with vendor about the details on system_bus BARs
- Further cleanups
- I think assume root_bus as 0 simplify our code a lot, as that's
always valid to the hardware, as we're not ecam or dwc, we can't
easily get host bus_nr via cfg, adding that will cause unnecessary
overhead.
v10:
- Enhance comments about system_bus quirk and host bus quirk.
v11:
- Add static for pci_loongson_map_bus
---
drivers/pci/controller/Kconfig | 10 ++
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pci-loongson.c | 247 ++++++++++++++++++++++++++
3 files changed, 258 insertions(+)
create mode 100644 drivers/pci/controller/pci-loongson.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 91bfdb784829..ae36edb1d7db 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -258,6 +258,16 @@ config PCI_HYPERV_INTERFACE
The Hyper-V PCI Interface is a helper driver allows other drivers to
have a common interface with the Hyper-V PCI frontend driver.
+config PCI_LOONGSON
+ bool "LOONGSON PCI Controller"
+ depends on MACH_LOONGSON64 || COMPILE_TEST
+ depends on OF
+ depends on PCI_QUIRKS
+ default MACH_LOONGSON64
+ help
+ Say Y here if you want to enable PCI controller support on
+ Loongson systems.
+
source "drivers/pci/controller/dwc/Kconfig"
source "drivers/pci/controller/mobiveil/Kconfig"
source "drivers/pci/controller/cadence/Kconfig"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index 158c59771824..fbac4b0190a0 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
+obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
obj-y += mobiveil/
diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c
new file mode 100644
index 000000000000..b590f3746ed2
--- /dev/null
+++ b/drivers/pci/controller/pci-loongson.c
@@ -0,0 +1,247 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Loongson PCI Host Controller Driver
+ *
+ * Copyright (C) 2020 Jiaxun Yang <jiaxun.yang@flygoat.com>
+ */
+
+#include <linux/of_device.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/pci_ids.h>
+
+#include "../pci.h"
+
+/* Device IDs */
+#define DEV_PCIE_PORT_0 0x7a09
+#define DEV_PCIE_PORT_1 0x7a19
+#define DEV_PCIE_PORT_2 0x7a29
+
+#define DEV_LS2K_APB 0x7a02
+#define DEV_LS7A_CONF 0x7a10
+#define DEV_LS7A_LPC 0x7a0c
+
+#define FLAG_CFG0 BIT(0)
+#define FLAG_CFG1 BIT(1)
+#define FLAG_DEV_FIX BIT(2)
+
+struct loongson_pci {
+ void __iomem *cfg0_base;
+ void __iomem *cfg1_base;
+ struct platform_device *pdev;
+ u32 flags;
+};
+
+/* Fixup wrong class code in PCIe bridges */
+static void bridge_class_quirk(struct pci_dev *dev)
+{
+ dev->class = PCI_CLASS_BRIDGE_PCI << 8;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_0, bridge_class_quirk);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_1, bridge_class_quirk);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_LOONGSON,
+ DEV_PCIE_PORT_2, bridge_class_quirk);
+
+static void system_bus_quirk(struct pci_dev *pdev)
+{
+ /*
+ * The address space consumed by these devices is outside the
+ * resources of the host bridge.
+ */
+ pdev->mmio_always_on = 1;
+ pdev->non_compliant_bars = 1;
+}
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS2K_APB, system_bus_quirk);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS7A_CONF, system_bus_quirk);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON,
+ DEV_LS7A_LPC, system_bus_quirk);
+
+static void loongson_mrrs_quirk(struct pci_dev *dev)
+{
+ struct pci_bus *bus = dev->bus;
+ struct pci_dev *bridge;
+ static const struct pci_device_id bridge_devids[] = {
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_0) },
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_1) },
+ { PCI_VDEVICE(LOONGSON, DEV_PCIE_PORT_2) },
+ { 0, },
+ };
+
+ /* look for the matching bridge */
+ while (!pci_is_root_bus(bus)) {
+ bridge = bus->self;
+ bus = bus->parent;
+ /*
+ * Some Loongson PCIe ports have a h/w limitation of
+ * 256 bytes maximum read request size. They can't handle
+ * anything larger than this. So force this limit on
+ * any devices attached under these ports.
+ */
+ if (pci_match_id(bridge_devids, bridge)) {
+ if (pcie_get_readrq(dev) > 256) {
+ pci_info(dev, "limiting MRRS to 256\n");
+ pcie_set_readrq(dev, 256);
+ }
+ break;
+ }
+ }
+}
+DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, loongson_mrrs_quirk);
+
+static void __iomem *cfg1_map(struct loongson_pci *priv, int bus,
+ unsigned int devfn, int where)
+{
+ unsigned long addroff = 0x0;
+
+ if (bus != 0)
+ addroff |= BIT(28); /* Type 1 Access */
+ addroff |= (where & 0xff) | ((where & 0xf00) << 16);
+ addroff |= (bus << 16) | (devfn << 8);
+ return priv->cfg1_base + addroff;
+}
+
+static void __iomem *cfg0_map(struct loongson_pci *priv, int bus,
+ unsigned int devfn, int where)
+{
+ unsigned long addroff = 0x0;
+
+ if (bus != 0)
+ addroff |= BIT(24); /* Type 1 Access */
+ addroff |= (bus << 16) | (devfn << 8) | where;
+ return priv->cfg0_base + addroff;
+}
+
+static void __iomem *pci_loongson_map_bus(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ unsigned char busnum = bus->number;
+ struct pci_host_bridge *bridge = pci_find_host_bridge(bus);
+ struct loongson_pci *priv = pci_host_bridge_priv(bridge);
+
+ /*
+ * Do not read more than one device on the bus other than
+ * the host bus. For our hardware the root bus is always bus 0.
+ */
+ if (priv->flags & FLAG_DEV_FIX && busnum != 0 &&
+ PCI_SLOT(devfn) > 0)
+ return NULL;
+
+ /* CFG0 can only access standard space */
+ if (where < PCI_CFG_SPACE_SIZE && priv->cfg0_base)
+ return cfg0_map(priv, busnum, devfn, where);
+
+ /* CFG1 can access extended space */
+ if (where < PCI_CFG_SPACE_EXP_SIZE && priv->cfg1_base)
+ return cfg1_map(priv, busnum, devfn, where);
+
+ return NULL;
+}
+
+static int loongson_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+ int irq;
+ u8 val;
+
+ irq = of_irq_parse_and_map_pci(dev, slot, pin);
+ if (irq > 0)
+ return irq;
+
+ /* Care i8259 legacy systems */
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, &val);
+ /* i8259 only have 15 IRQs */
+ if (val > 15)
+ return 0;
+
+ return val;
+}
+
+/* H/w only accept 32-bit PCI operations */
+static struct pci_ops loongson_pci_ops = {
+ .map_bus = pci_loongson_map_bus,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+static const struct of_device_id loongson_pci_of_match[] = {
+ { .compatible = "loongson,ls2k-pci",
+ .data = (void *)(FLAG_CFG0 | FLAG_CFG1 | FLAG_DEV_FIX), },
+ { .compatible = "loongson,ls7a-pci",
+ .data = (void *)(FLAG_CFG0 | FLAG_CFG1 | FLAG_DEV_FIX), },
+ { .compatible = "loongson,rs780e-pci",
+ .data = (void *)(FLAG_CFG0), },
+ {}
+};
+
+static int loongson_pci_probe(struct platform_device *pdev)
+{
+ struct loongson_pci *priv;
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct pci_host_bridge *bridge;
+ struct resource *regs;
+ int err;
+
+ if (!node)
+ return -ENODEV;
+
+ bridge = devm_pci_alloc_host_bridge(dev, sizeof(*priv));
+ if (!bridge)
+ return -ENODEV;
+
+ priv = pci_host_bridge_priv(bridge);
+ priv->pdev = pdev;
+ priv->flags = (unsigned long)of_device_get_match_data(dev);
+
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!regs) {
+ dev_err(dev, "missing mem resources for cfg0\n");
+ return -EINVAL;
+ }
+
+ priv->cfg0_base = devm_pci_remap_cfg_resource(dev, regs);
+ if (IS_ERR(priv->cfg0_base))
+ return PTR_ERR(priv->cfg0_base);
+
+ /* CFG1 is optional */
+ if (priv->flags & FLAG_CFG1) {
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!regs)
+ dev_info(dev, "missing mem resource for cfg1\n");
+ else {
+ priv->cfg1_base = devm_pci_remap_cfg_resource(dev, regs);
+ if (IS_ERR(priv->cfg1_base))
+ priv->cfg1_base = NULL;
+ }
+ }
+
+ err = pci_parse_request_of_pci_ranges(dev, &bridge->windows,
+ &bridge->dma_ranges, NULL);
+ if (err) {
+ dev_err(dev, "failed to get bridge resources\n");
+ return err;
+ }
+
+ bridge->dev.parent = dev;
+ bridge->sysdata = priv;
+ bridge->ops = &loongson_pci_ops;
+ bridge->map_irq = loongson_map_irq;
+
+ err = pci_host_probe(bridge);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static struct platform_driver loongson_pci_driver = {
+ .driver = {
+ .name = "loongson-pci",
+ .of_match_table = loongson_pci_of_match,
+ },
+ .probe = loongson_pci_probe,
+};
+builtin_platform_driver(loongson_pci_driver);
--
2.27.0.rc0
^ permalink raw reply related
* [PATCH v11 3/5] dt-bindings: Document Loongson PCI Host Controller
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Rob Herring, Bjorn Helgaas, Rob Herring,
Thomas Bogendoerfer, Huacai Chen, Lorenzo Pieralisi, Paul Burton,
devicetree, linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
PCI host controller found on Loongson PCHs and SoCs.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/pci/loongson.yaml | 62 +++++++++++++++++++
1 file changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/loongson.yaml
diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml
new file mode 100644
index 000000000000..30e7cf1aeb87
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/loongson.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/loongson.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Loongson PCI Host Controller
+
+maintainers:
+ - Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+description: |+
+ PCI host controller found on Loongson PCHs and SoCs.
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: loongson,ls2k-pci
+ - const: loongson,ls7a-pci
+ - const: loongson,rs780e-pci
+
+ reg:
+ minItems: 1
+ maxItems: 2
+ items:
+ - description: CFG0 standard config space register
+ - description: CFG1 extended config space register
+
+ ranges:
+ minItems: 1
+ maxItems: 3
+
+
+required:
+ - compatible
+ - reg
+ - ranges
+
+examples:
+ - |
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie@1a000000 {
+ compatible = "loongson,rs780e-pci";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ // CPU_PHYSICAL(2) SIZE(2)
+ reg = <0x0 0x1a000000 0x0 0x2000000>;
+
+ // BUS_ADDRESS(3) CPU_PHYSICAL(2) SIZE(2)
+ ranges = <0x01000000 0x0 0x00004000 0x0 0x00004000 0x0 0x00004000>,
+ <0x02000000 0x0 0x40000000 0x0 0x40000000 0x0 0x40000000>;
+ };
+ };
+...
--
2.27.0.rc0
^ permalink raw reply related
* [PATCH v11 4/5] MIPS: DTS: Loongson64: Add PCI Controller Node
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
Add PCI Host controller node for Loongson64 with RS780E PCH dts.
Note that PCI interrupts are probed via legacy way, as different
machine have different interrupt arrangement, we can't cover all
of them in dt.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
arch/mips/boot/dts/loongson/rs780e-pch.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
index 8687c4f7370a..d0d5d60a8697 100644
--- a/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
+++ b/arch/mips/boot/dts/loongson/rs780e-pch.dtsi
@@ -9,6 +9,18 @@ bus@10000000 {
0 0x40000000 0 0x40000000 0 0x40000000
0xfd 0xfe000000 0xfd 0xfe000000 0 0x2000000 /* PCI Config Space */>;
+ pci@1a000000 {
+ compatible = "loongson,rs780e-pci";
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ reg = <0 0x1a000000 0 0x02000000>;
+
+ ranges = <0x01000000 0 0x00004000 0 0x18004000 0 0x00004000>,
+ <0x02000000 0 0x40000000 0 0x40000000 0 0x40000000>;
+ };
+
isa {
compatible = "isa";
#address-cells = <2>;
--
2.27.0.rc0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Pavel Machek @ 2020-05-26 9:22 UTC (permalink / raw)
To: Flavio Suligoi
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring, linux-leds, devicetree,
linux-kernel
In-Reply-To: <20200526092052.24172-1-f.suligoi@asem.it>
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]
On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> The documentation reports the wrong macro names
> related to the pca9532 instead of the pca955x
>
> Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Nothing obviously wrong, but why did you send it twice within half an
hour?
Pavel
> Documentation/devicetree/bindings/leds/leds-pca955x.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-pca955x.txt b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
> index 7984efb767b4..7a5830f8d5ab 100644
> --- a/Documentation/devicetree/bindings/leds/leds-pca955x.txt
> +++ b/Documentation/devicetree/bindings/leds/leds-pca955x.txt
> @@ -26,9 +26,9 @@ LED sub-node properties:
> from 0 to 15 for the pca9552
> from 0 to 3 for the pca9553
> - type: (optional) either
> - PCA9532_TYPE_NONE
> - PCA9532_TYPE_LED
> - PCA9532_TYPE_GPIO
> + PCA955X_TYPE_NONE
> + PCA955X_TYPE_LED
> + PCA955X_TYPE_GPIO
> see dt-bindings/leds/leds-pca955x.h (default to LED)
> - label : (optional)
> see Documentation/devicetree/bindings/leds/common.txt
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH v11 5/5] MIPS: Loongson64: Switch to generic PCI driver
From: Jiaxun Yang @ 2020-05-26 9:21 UTC (permalink / raw)
To: linux-pci
Cc: Jiaxun Yang, Bjorn Helgaas, Rob Herring, Thomas Bogendoerfer,
Huacai Chen, Lorenzo Pieralisi, Paul Burton, devicetree,
linux-kernel, linux-mips
In-Reply-To: <20200526092130.145550-1-jiaxun.yang@flygoat.com>
We can now enable generic PCI driver in Kconfig, and remove legacy
PCI driver code.
Radeon vbios quirk is moved to the platform folder to fit the
new structure.
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
--
v9: Fix licenses tag
---
arch/mips/Kconfig | 1 +
arch/mips/loongson64/Makefile | 2 +-
arch/mips/loongson64/vbios_quirk.c | 29 ++++++++
arch/mips/pci/Makefile | 1 -
arch/mips/pci/fixup-loongson3.c | 71 ------------------
arch/mips/pci/ops-loongson3.c | 116 -----------------------------
6 files changed, 31 insertions(+), 189 deletions(-)
create mode 100644 arch/mips/loongson64/vbios_quirk.c
delete mode 100644 arch/mips/pci/fixup-loongson3.c
delete mode 100644 arch/mips/pci/ops-loongson3.c
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 0519ca9f00f9..7a4fcc4ade1f 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -480,6 +480,7 @@ config MACH_LOONGSON64
select IRQ_MIPS_CPU
select NR_CPUS_DEFAULT_64
select USE_GENERIC_EARLY_PRINTK_8250
+ select PCI_DRIVERS_GENERIC
select SYS_HAS_CPU_LOONGSON64
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_SMP
diff --git a/arch/mips/loongson64/Makefile b/arch/mips/loongson64/Makefile
index 6f3c2b47f66f..6f81b822aeae 100644
--- a/arch/mips/loongson64/Makefile
+++ b/arch/mips/loongson64/Makefile
@@ -8,5 +8,5 @@ obj-$(CONFIG_MACH_LOONGSON64) += cop2-ex.o platform.o dma.o \
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_NUMA) += numa.o
obj-$(CONFIG_RS780_HPET) += hpet.o
-obj-$(CONFIG_PCI) += pci.o
obj-$(CONFIG_SUSPEND) += pm.o
+obj-$(CONFIG_PCI_QUIRKS) += vbios_quirk.o
diff --git a/arch/mips/loongson64/vbios_quirk.c b/arch/mips/loongson64/vbios_quirk.c
new file mode 100644
index 000000000000..9a29e94d3db1
--- /dev/null
+++ b/arch/mips/loongson64/vbios_quirk.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include <linux/pci.h>
+#include <loongson.h>
+
+static void pci_fixup_radeon(struct pci_dev *pdev)
+{
+ struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
+
+ if (res->start)
+ return;
+
+ if (!loongson_sysconf.vgabios_addr)
+ return;
+
+ pci_disable_rom(pdev);
+ if (res->parent)
+ release_resource(res);
+
+ res->start = virt_to_phys((void *) loongson_sysconf.vgabios_addr);
+ res->end = res->start + 256*1024 - 1;
+ res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
+ IORESOURCE_PCI_FIXED;
+
+ dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
+ PCI_ROM_RESOURCE, res);
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, 0x9615,
+ PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_radeon);
diff --git a/arch/mips/pci/Makefile b/arch/mips/pci/Makefile
index 342ce10ef593..438f10955d89 100644
--- a/arch/mips/pci/Makefile
+++ b/arch/mips/pci/Makefile
@@ -35,7 +35,6 @@ obj-$(CONFIG_LASAT) += pci-lasat.o
obj-$(CONFIG_MIPS_COBALT) += fixup-cobalt.o
obj-$(CONFIG_LEMOTE_FULOONG2E) += fixup-fuloong2e.o ops-loongson2.o
obj-$(CONFIG_LEMOTE_MACH2F) += fixup-lemote2f.o ops-loongson2.o
-obj-$(CONFIG_MACH_LOONGSON64) += fixup-loongson3.o ops-loongson3.o
obj-$(CONFIG_MIPS_MALTA) += fixup-malta.o pci-malta.o
obj-$(CONFIG_PMC_MSP7120_GW) += fixup-pmcmsp.o ops-pmcmsp.o
obj-$(CONFIG_PMC_MSP7120_EVAL) += fixup-pmcmsp.o ops-pmcmsp.o
diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c
deleted file mode 100644
index 8a741c2c6685..000000000000
--- a/arch/mips/pci/fixup-loongson3.c
+++ /dev/null
@@ -1,71 +0,0 @@
-/*
- * fixup-loongson3.c
- *
- * Copyright (C) 2012 Lemote, Inc.
- * Author: Xiang Yu, xiangy@lemote.com
- * Chen Huacai, chenhc@lemote.com
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
- * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
- * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- */
-
-#include <linux/pci.h>
-#include <boot_param.h>
-
-static void print_fixup_info(const struct pci_dev *pdev)
-{
- dev_info(&pdev->dev, "Device %x:%x, irq %d\n",
- pdev->vendor, pdev->device, pdev->irq);
-}
-
-int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
-{
- print_fixup_info(dev);
- return dev->irq;
-}
-
-static void pci_fixup_radeon(struct pci_dev *pdev)
-{
- struct resource *res = &pdev->resource[PCI_ROM_RESOURCE];
-
- if (res->start)
- return;
-
- if (!loongson_sysconf.vgabios_addr)
- return;
-
- pci_disable_rom(pdev);
- if (res->parent)
- release_resource(res);
-
- res->start = virt_to_phys((void *) loongson_sysconf.vgabios_addr);
- res->end = res->start + 256*1024 - 1;
- res->flags = IORESOURCE_MEM | IORESOURCE_ROM_SHADOW |
- IORESOURCE_PCI_FIXED;
-
- dev_info(&pdev->dev, "BAR %d: assigned %pR for Radeon ROM\n",
- PCI_ROM_RESOURCE, res);
-}
-
-DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
- PCI_CLASS_DISPLAY_VGA, 8, pci_fixup_radeon);
-
-/* Do platform specific device initialization at pci_enable_device() time */
-int pcibios_plat_dev_init(struct pci_dev *dev)
-{
- return 0;
-}
diff --git a/arch/mips/pci/ops-loongson3.c b/arch/mips/pci/ops-loongson3.c
deleted file mode 100644
index 2f6ad36bdea6..000000000000
--- a/arch/mips/pci/ops-loongson3.c
+++ /dev/null
@@ -1,116 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <linux/types.h>
-#include <linux/pci.h>
-#include <linux/kernel.h>
-
-#include <asm/mips-boards/bonito64.h>
-
-#include <loongson.h>
-
-#define PCI_ACCESS_READ 0
-#define PCI_ACCESS_WRITE 1
-
-#define HT1LO_PCICFG_BASE 0x1a000000
-#define HT1LO_PCICFG_BASE_TP1 0x1b000000
-
-static int loongson3_pci_config_access(unsigned char access_type,
- struct pci_bus *bus, unsigned int devfn,
- int where, u32 *data)
-{
- unsigned char busnum = bus->number;
- int function = PCI_FUNC(devfn);
- int device = PCI_SLOT(devfn);
- int reg = where & ~3;
- void *addrp;
- u64 addr;
-
- if (where < PCI_CFG_SPACE_SIZE) { /* standard config */
- addr = (busnum << 16) | (device << 11) | (function << 8) | reg;
- if (busnum == 0) {
- if (device > 31)
- return PCIBIOS_DEVICE_NOT_FOUND;
- addrp = (void *)TO_UNCAC(HT1LO_PCICFG_BASE | addr);
- } else {
- addrp = (void *)TO_UNCAC(HT1LO_PCICFG_BASE_TP1 | addr);
- }
- } else if (where < PCI_CFG_SPACE_EXP_SIZE) { /* extended config */
- struct pci_dev *rootdev;
-
- rootdev = pci_get_domain_bus_and_slot(0, 0, 0);
- if (!rootdev)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- addr = pci_resource_start(rootdev, 3);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- addr |= busnum << 20 | device << 15 | function << 12 | reg;
- addrp = (void *)TO_UNCAC(addr);
- } else {
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
-
- if (access_type == PCI_ACCESS_WRITE)
- writel(*data, addrp);
- else {
- *data = readl(addrp);
- if (*data == 0xffffffff) {
- *data = -1;
- return PCIBIOS_DEVICE_NOT_FOUND;
- }
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int loongson3_pci_pcibios_read(struct pci_bus *bus, unsigned int devfn,
- int where, int size, u32 *val)
-{
- u32 data = 0;
- int ret = loongson3_pci_config_access(PCI_ACCESS_READ,
- bus, devfn, where, &data);
-
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (size == 1)
- *val = (data >> ((where & 3) << 3)) & 0xff;
- else if (size == 2)
- *val = (data >> ((where & 3) << 3)) & 0xffff;
- else
- *val = data;
-
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int loongson3_pci_pcibios_write(struct pci_bus *bus, unsigned int devfn,
- int where, int size, u32 val)
-{
- u32 data = 0;
- int ret;
-
- if (size == 4)
- data = val;
- else {
- ret = loongson3_pci_config_access(PCI_ACCESS_READ,
- bus, devfn, where, &data);
- if (ret != PCIBIOS_SUCCESSFUL)
- return ret;
-
- if (size == 1)
- data = (data & ~(0xff << ((where & 3) << 3))) |
- (val << ((where & 3) << 3));
- else if (size == 2)
- data = (data & ~(0xffff << ((where & 3) << 3))) |
- (val << ((where & 3) << 3));
- }
-
- ret = loongson3_pci_config_access(PCI_ACCESS_WRITE,
- bus, devfn, where, &data);
-
- return ret;
-}
-
-struct pci_ops loongson_pci_ops = {
- .read = loongson3_pci_pcibios_read,
- .write = loongson3_pci_pcibios_write
-};
--
2.27.0.rc0
^ permalink raw reply related
* RE: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Flavio Suligoi @ 2020-05-26 9:25 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200526092250.GB12838@amd>
> Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
>
> On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> > The documentation reports the wrong macro names
> > related to the pca9532 instead of the pca955x
> >
> > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
>
> Nothing obviously wrong, but why did you send it twice within half an
> hour?
> Pavel
Sorry Pavel, with the first email I forgot to subscribe
to the linux-leds mailing list! 😊
Flavio
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: interrupt-controller: Add Loongson HTVEC
From: Jiaxun Yang @ 2020-05-26 9:26 UTC (permalink / raw)
To: Marc Zyngier
Cc: Rob Herring, Thomas Gleixner, Jason Cooper, Huacai Chen,
linux-kernel, devicetree, linux-mips
In-Reply-To: <87v9kkz5kl.wl-maz@kernel.org>
On Mon, 25 May 2020 11:12:26 +0100
Marc Zyngier <maz@kernel.org> wrote:
> On Sat, 16 May 2020 09:29:02 +0100,
> Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
> >
> > Add binding for Loongson-3 HyperTransport Interrupt Vector
> > Controller.
> >
> > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> > --
> > v4: Drop ref, '|', add additionalProperties, fix example
>
> Rob, do you have any input on this?
Oops, looks like I was in-reply into wrong patch topic for this patch,
should I resend this series into correct thread?
Thanks.
>
> Thanks,
>
> M.
>
---
Jiaxun Yang
^ permalink raw reply
* Re: [PATCH v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Andrey Konovalov @ 2020-05-26 9:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: mchehab, manivannan.sadhasivam, linux-media, linux-kernel,
devicetree, linux-arm-kernel, c.barrett, a.brela, peter.griffin
In-Reply-To: <20200526091234.GH8214@valkosipuli.retiisi.org.uk>
Hi Sakari,
Thank you for the review!
On 26.05.2020 12:12, Sakari Ailus wrote:
> Hi Andrey,
>
> On Sun, May 24, 2020 at 10:25:00PM +0300, Andrey Konovalov wrote:
>> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>
>> IMX290 operates with multiple link frequency and pixel rate combinations.
>> The initial driver used a single setting for both but since we now have
>> the lane count support in place, let's add configurable link frequency
>> and pixel rate.
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
>> ---
>> drivers/media/i2c/imx290.c | 100 ++++++++++++++++++++++++-------------
>> 1 file changed, 66 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
>> index a361c9ac8bd5..e800557cf423 100644
>> --- a/drivers/media/i2c/imx290.c
>> +++ b/drivers/media/i2c/imx290.c
>> @@ -38,8 +38,6 @@
>> #define IMX290_HMAX_2_720 0x19C8
>> #define IMX290_HMAX_4_720 0x0CE4
>>
>> -#define IMX290_DEFAULT_LINK_FREQ 445500000
>> -
>> static const char * const imx290_supply_name[] = {
>> "vdda",
>> "vddd",
>> @@ -56,8 +54,6 @@ struct imx290_regval {
>> struct imx290_mode {
>> u32 width;
>> u32 height;
>> - u32 pixel_rate;
>> - u32 link_freq_index;
>>
>> const struct imx290_regval *data;
>> u32 data_size;
>> @@ -248,8 +244,13 @@ static const struct imx290_regval imx290_10bit_settings[] = {
>> };
>>
>> /* supported link frequencies */
>> -static const s64 imx290_link_freq[] = {
>> - IMX290_DEFAULT_LINK_FREQ,
>> +static const s64 imx290_link_freq_2lanes[] = {
>> + 891000000, /* 1920x1080 - 2 lane */
>> + 594000000, /* 1280x720 - 2 lane */
>> +};
>> +static const s64 imx290_link_freq_4lanes[] = {
>> + 445500000, /* 1920x1080 - 4 lane */
>> + 297000000, /* 1280x720 - 4 lane */
>> };
>>
>> /* Mode configs */
>> @@ -259,16 +260,12 @@ static const struct imx290_mode imx290_modes[] = {
>> .height = 1080,
>> .data = imx290_1080p_settings,
>> .data_size = ARRAY_SIZE(imx290_1080p_settings),
>> - .pixel_rate = 178200000,
>> - .link_freq_index = 0,
>> },
>> {
>> .width = 1280,
>> .height = 720,
>> .data = imx290_720p_settings,
>> .data_size = ARRAY_SIZE(imx290_720p_settings),
>> - .pixel_rate = 178200000,
>> - .link_freq_index = 0,
>> },
>> };
>>
>> @@ -442,6 +439,32 @@ static int imx290_get_fmt(struct v4l2_subdev *sd,
>> return 0;
>> }
>>
>> +static u8 imx290_get_link_freq_index(struct imx290 *imx290)
>> +{
>> + const struct imx290_mode *cur_mode = imx290->current_mode;
>> +
>> + return (cur_mode->width == 1920) ? 0 : 1;
>
> Could you use (imx290->current_mode - imx290_modes) / sizeof(*imx290_modes)
> or something like that? It'd have fewer chances of breaking if new modes
> are added.
>
>> +}
>> +
>> +static s64 imx290_get_link_freq(struct imx290 *imx290)
>> +{
>> + u8 index = imx290_get_link_freq_index(imx290);
>> +
>> + if (imx290->nlanes == 4)
>> + return imx290_link_freq_4lanes[index];
>> + else
>> + return imx290_link_freq_2lanes[index];
>
> Or even better: store the link frequencies to the modes themselves. They
> are a property of the modes after all.
Then we will get two sets (for 2 lanes and for 4 lanes) of two modes (1080p and 720p), right?
>> +}
>> +
>> +static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
>> +{
>> + s64 link_freq = imx290_get_link_freq(imx290);
>> + u8 nlanes = imx290->nlanes;
>> +
>> + /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
>> + return (link_freq * 2 * nlanes / 10);
>> +}
>> +
>> static int imx290_set_fmt(struct v4l2_subdev *sd,
>> struct v4l2_subdev_pad_config *cfg,
>> struct v4l2_subdev_format *fmt)
>> @@ -475,10 +498,14 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
>> format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
>> } else {
>> format = &imx290->current_format;
>> - __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
>> - __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
>> -
>> imx290->current_mode = mode;
>> +
>> + if (imx290->link_freq)
>> + __v4l2_ctrl_s_ctrl(imx290->link_freq,
>> + imx290_get_link_freq_index(imx290));
>> + if (imx290->pixel_rate)
>> + __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate,
>> + imx290_calc_pixel_rate(imx290));
>> }
>>
>> *format = fmt->format;
>> @@ -502,12 +529,11 @@ static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
>> return 0;
>> }
>>
>> -static int imx290_write_current_format(struct imx290 *imx290,
>> - struct v4l2_mbus_framefmt *format)
>> +static int imx290_write_current_format(struct imx290 *imx290)
>> {
>> int ret;
>>
>> - switch (format->code) {
>> + switch (imx290->current_format.code) {
>> case MEDIA_BUS_FMT_SRGGB10_1X10:
>> ret = imx290_set_register_array(imx290, imx290_10bit_settings,
>> ARRAY_SIZE(
>> @@ -558,8 +584,8 @@ static int imx290_start_streaming(struct imx290 *imx290)
>> return ret;
>> }
>>
>> - /* Set current frame format */
>> - ret = imx290_write_current_format(imx290, &imx290->current_format);
>> + /* Apply the register values related to current frame format */
>> + ret = imx290_write_current_format(imx290);
>> if (ret < 0) {
>> dev_err(imx290->dev, "Could not set frame format\n");
>> return ret;
>> @@ -821,12 +847,6 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_err;
>> }
>>
>> - if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
>
> This check needs to be modified to correspond to the driver's new
> capabilities, not removed.
Agreed.
Do I understand correct that as the driver uses two link frequencies
for a given number of lanes now, it must check that *the both* frequencies
(for the given number of lanes) are listed in the device tree node?
Thanks,
Andrey
>> - dev_err(dev, "Unsupported link frequency\n");
>> - ret = -EINVAL;
>> - goto free_err;
>> - }
>> -
>> /* Only CSI2 is supported for now */
>> if (imx290->ep.bus_type != V4L2_MBUS_CSI2_DPHY) {
>> dev_err(dev, "Unsupported bus type, should be CSI2\n");
>> @@ -879,23 +899,38 @@ static int imx290_probe(struct i2c_client *client)
>>
>> mutex_init(&imx290->lock);
>>
>> + /*
>> + * Initialize the frame format. In particular, imx290->current_mode
>> + * and imx290->bpp are set to defaults: imx290_calc_pixel_rate() call
>> + * below relies on these fields.
>> + */
>> + imx290_entity_init_cfg(&imx290->sd, NULL);
>> +
>> v4l2_ctrl_handler_init(&imx290->ctrls, 3);
>>
>> v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
>> V4L2_CID_GAIN, 0, 72, 1, 0);
>> - imx290->link_freq =
>> - v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> - &imx290_ctrl_ops,
>> - V4L2_CID_LINK_FREQ,
>> - ARRAY_SIZE(imx290_link_freq) - 1,
>> - 0, imx290_link_freq);
>> + if (imx290->nlanes == 4)
>> + imx290->link_freq =
>> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> + &imx290_ctrl_ops,
>> + V4L2_CID_LINK_FREQ,
>> + ARRAY_SIZE(imx290_link_freq_4lanes) - 1,
>> + 0, imx290_link_freq_4lanes);
>> + else
>> + imx290->link_freq =
>> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> + &imx290_ctrl_ops,
>> + V4L2_CID_LINK_FREQ,
>> + ARRAY_SIZE(imx290_link_freq_2lanes) - 1,
>> + 0, imx290_link_freq_2lanes);
>> if (imx290->link_freq)
>> imx290->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>
>> imx290->pixel_rate = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
>> V4L2_CID_PIXEL_RATE, 1,
>> INT_MAX, 1,
>> - imx290_modes[0].pixel_rate);
>> + imx290_calc_pixel_rate(imx290));
>>
>> imx290->sd.ctrl_handler = &imx290->ctrls;
>>
>> @@ -919,9 +954,6 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_ctrl;
>> }
>>
>> - /* Initialize the frame format (this also sets imx290->current_mode) */
>> - imx290_entity_init_cfg(&imx290->sd, NULL);
>> -
>> ret = v4l2_async_register_subdev(&imx290->sd);
>> if (ret < 0) {
>> dev_err(dev, "Could not register v4l2 device\n");
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Pavel Machek @ 2020-05-26 9:28 UTC (permalink / raw)
To: Flavio Suligoi
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <b58a76bed46141a1a7952303ec466f66@asem.it>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Tue 2020-05-26 09:25:58, Flavio Suligoi wrote:
> > Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
> >
> > On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> > > The documentation reports the wrong macro names
> > > related to the pca9532 instead of the pca955x
> > >
> > > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
> >
> > Nothing obviously wrong, but why did you send it twice within half an
> > hour?
> > Pavel
>
> Sorry Pavel, with the first email I forgot to subscribe
> to the linux-leds mailing list! 😊
You really don't need to be subscribed on a list for trivial
cleanups... Normally people would reply-all, anyway.
BR,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* RE: [PATCH] dt-bindings: leds: fix macro names for pca955x
From: Flavio Suligoi @ 2020-05-26 9:31 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, Dan Murphy, Rob Herring,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20200526092808.GC12838@amd>
> Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
>
> On Tue 2020-05-26 09:25:58, Flavio Suligoi wrote:
> > > Subject: Re: [PATCH] dt-bindings: leds: fix macro names for pca955x
> > >
> > > On Tue 2020-05-26 11:20:52, Flavio Suligoi wrote:
> > > > The documentation reports the wrong macro names
> > > > related to the pca9532 instead of the pca955x
> > > >
> > > > Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
> > >
> > > Nothing obviously wrong, but why did you send it twice within half an
> > > hour?
> > > Pavel
> >
> > Sorry Pavel, with the first email I forgot to subscribe
> > to the linux-leds mailing list! 😊
>
> You really don't need to be subscribed on a list for trivial
> cleanups... Normally people would reply-all, anyway.
>
> BR,
> Pavel
Thanks for the explanation!
Regards,
Flavio
^ permalink raw reply
* Re: [PATCH v12 0/6] Add battery charger driver support for MP2629
From: Lee Jones @ 2020-05-26 9:34 UTC (permalink / raw)
To: Saravanan Sekar
Cc: andy.shevchenko, robh+dt, jic23, knaack.h, lars, pmeerw, sre,
devicetree, linux-kernel, linux-iio, linux-pm
In-Reply-To: <20200526090646.25827-1-sravanhome@gmail.com>
On Tue, 26 May 2020, Saravanan Sekar wrote:
> changes in v12:
> - added SOB Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
Looks like you added my Acked-by to every patch, when actually I only
Acked the MFD one. Fortunately, as I'm the one applying these, I can
strip them off, but please be more careful about which *-bys you apply
to which patches in the future.
> changes in v11:
> - module_remove part replaced by devm_add_action_or_reset in charger patch
> - minor review comments solved in mfd and adc patch
>
> I expect, that Lee will provide an immutable branch for me and
> Jonathan once the MFD bits have been reviewed. Please tell me,
> if I should prepare one instead.
I'll do this now.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v5 2/2] clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller
From: Bryan O'Donoghue @ 2020-05-26 9:38 UTC (permalink / raw)
To: Bryan O'Donoghue, agross, bjorn.andersson, mturquette, sboyd,
robh+dt
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, shawn.guo,
p.zabel, vincent.knecht, konradybcio
In-Reply-To: <20200517131348.688405-3-bryan.odonoghue@linaro.org>
On 17/05/2020 14:13, Bryan O'Donoghue wrote:
> This patch adds support for the MSM8939 GCC. The MSM8939 is based on the
> MSM8916. MSM8939 is compatible in several ways with MSM8916 but, has
> additional functional blocks added which require additional PLL sources. In
> some cases functional blocks from the MSM8916 have different clock sources
> or different supported frequencies.
>
> Cc: Andy Gross <agross@kernel.org>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Co-developed-by: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> Tested-by: Vincent Knecht <vincent.knecht@mailoo.org>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
ping
just sending a reminder on this one
^ permalink raw reply
* Re: [PATCH v5 2/2] clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller
From: Konrad Dybcio @ 2020-05-26 9:46 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bryan O'Donoghue, Andy Gross, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Rob Herring, linux-arm-msm,
linux-clk, Linux Kernel Mailing List, DTML, Shawn Guo, p.zabel,
Vincent Knecht
In-Reply-To: <af35d732-08bf-fe95-3c98-063b32fe992a@nexus-software.ie>
Just adding my few cents, working fine on Asus Zenfone 2 Z00T, MSM8939.
Tested-by: Konrad Dybcio <konradybcio@gmail.com>
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, IIO and Power due for the v5.8 merge window
From: Lee Jones @ 2020-05-26 9:47 UTC (permalink / raw)
To: Saravanan Sekar
Cc: andy.shevchenko, robh+dt, jic23, knaack.h, lars, pmeerw, sre,
devicetree, linux-kernel, linux-iio, linux-pm
In-Reply-To: <20200526090646.25827-1-sravanhome@gmail.com>
Enjoy!
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/ib-mfd-iio-power-v5.8
for you to fetch changes up to 904ac71f4b0c1c26ec47ff597cb3d3c7d36e618d:
MAINTAINERS: Add entry for mp2629 Battery Charger driver (2020-05-26 10:42:02 +0100)
----------------------------------------------------------------
Immutable branch between MFD, IIO and Power due for the v5.8 merge window
----------------------------------------------------------------
Saravanan Sekar (6):
dt-bindings: mfd: Add document bindings for mp2629
mfd: mp2629: Add support for mps battery charger
iio: adc: mp2629: Add support for mp2629 ADC driver
power: supply: Add support for mps mp2629 battery charger
power: supply: mp2629: Add impedance compensation config
MAINTAINERS: Add entry for mp2629 Battery Charger driver
Documentation/ABI/testing/sysfs-class-power-mp2629 | 8 +
.../devicetree/bindings/mfd/mps,mp2629.yaml | 62 ++
MAINTAINERS | 5 +
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/mp2629_adc.c | 208 +++++++
drivers/mfd/Kconfig | 9 +
drivers/mfd/Makefile | 2 +
drivers/mfd/mp2629.c | 79 +++
drivers/power/supply/Kconfig | 10 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/mp2629_charger.c | 669 +++++++++++++++++++++
include/linux/mfd/mp2629.h | 26 +
13 files changed, 1090 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-power-mp2629
create mode 100644 Documentation/devicetree/bindings/mfd/mps,mp2629.yaml
create mode 100644 drivers/iio/adc/mp2629_adc.c
create mode 100644 drivers/mfd/mp2629.c
create mode 100644 drivers/power/supply/mp2629_charger.c
create mode 100644 include/linux/mfd/mp2629.h
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 2/6] dt-bindings: interrupt-controller: Add Loongson HTVEC
From: Marc Zyngier @ 2020-05-26 9:53 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Rob Herring, Thomas Gleixner, Jason Cooper, Huacai Chen,
linux-kernel, devicetree, linux-mips
In-Reply-To: <20200526172653.0a19f375@halation.net.flygoat.com>
On 2020-05-26 10:26, Jiaxun Yang wrote:
> On Mon, 25 May 2020 11:12:26 +0100
> Marc Zyngier <maz@kernel.org> wrote:
>
>> On Sat, 16 May 2020 09:29:02 +0100,
>> Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>> >
>> > Add binding for Loongson-3 HyperTransport Interrupt Vector
>> > Controller.
>> >
>> > Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
>> > --
>> > v4: Drop ref, '|', add additionalProperties, fix example
>>
>> Rob, do you have any input on this?
>
> Oops, looks like I was in-reply into wrong patch topic for this patch,
> should I resend this series into correct thread?
No, this series is fine as it is. TBH, your practice of sending
a series in reply to the previous version is not that useful
(I personally find it very annoying).
It would also be a big improvement if you sent a cover letter
with your patches (using --cover-letter when generating the patches).
I'll wait for Rob to comment on this patch as well as patch #4.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Sakari Ailus @ 2020-05-26 9:58 UTC (permalink / raw)
To: Andrey Konovalov
Cc: mchehab, manivannan.sadhasivam, linux-media, linux-kernel,
devicetree, linux-arm-kernel, c.barrett, a.brela, peter.griffin
In-Reply-To: <91992bdb-deb1-0355-e61f-78c38a68f6d1@linaro.org>
Hi Andrey,
On Tue, May 26, 2020 at 12:27:17PM +0300, Andrey Konovalov wrote:
> Hi Sakari,
>
> Thank you for the review!
You're welcome!
>
> On 26.05.2020 12:12, Sakari Ailus wrote:
> > Hi Andrey,
> >
> > On Sun, May 24, 2020 at 10:25:00PM +0300, Andrey Konovalov wrote:
> > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >
> > > IMX290 operates with multiple link frequency and pixel rate combinations.
> > > The initial driver used a single setting for both but since we now have
> > > the lane count support in place, let's add configurable link frequency
> > > and pixel rate.
> > >
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> > > ---
> > > drivers/media/i2c/imx290.c | 100 ++++++++++++++++++++++++-------------
> > > 1 file changed, 66 insertions(+), 34 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > > index a361c9ac8bd5..e800557cf423 100644
> > > --- a/drivers/media/i2c/imx290.c
> > > +++ b/drivers/media/i2c/imx290.c
> > > @@ -38,8 +38,6 @@
> > > #define IMX290_HMAX_2_720 0x19C8
> > > #define IMX290_HMAX_4_720 0x0CE4
> > > -#define IMX290_DEFAULT_LINK_FREQ 445500000
> > > -
> > > static const char * const imx290_supply_name[] = {
> > > "vdda",
> > > "vddd",
> > > @@ -56,8 +54,6 @@ struct imx290_regval {
> > > struct imx290_mode {
> > > u32 width;
> > > u32 height;
> > > - u32 pixel_rate;
> > > - u32 link_freq_index;
> > > const struct imx290_regval *data;
> > > u32 data_size;
> > > @@ -248,8 +244,13 @@ static const struct imx290_regval imx290_10bit_settings[] = {
> > > };
> > > /* supported link frequencies */
> > > -static const s64 imx290_link_freq[] = {
> > > - IMX290_DEFAULT_LINK_FREQ,
> > > +static const s64 imx290_link_freq_2lanes[] = {
> > > + 891000000, /* 1920x1080 - 2 lane */
> > > + 594000000, /* 1280x720 - 2 lane */
> > > +};
> > > +static const s64 imx290_link_freq_4lanes[] = {
> > > + 445500000, /* 1920x1080 - 4 lane */
> > > + 297000000, /* 1280x720 - 4 lane */
> > > };
> > > /* Mode configs */
> > > @@ -259,16 +260,12 @@ static const struct imx290_mode imx290_modes[] = {
> > > .height = 1080,
> > > .data = imx290_1080p_settings,
> > > .data_size = ARRAY_SIZE(imx290_1080p_settings),
> > > - .pixel_rate = 178200000,
> > > - .link_freq_index = 0,
> > > },
> > > {
> > > .width = 1280,
> > > .height = 720,
> > > .data = imx290_720p_settings,
> > > .data_size = ARRAY_SIZE(imx290_720p_settings),
> > > - .pixel_rate = 178200000,
> > > - .link_freq_index = 0,
> > > },
> > > };
> > > @@ -442,6 +439,32 @@ static int imx290_get_fmt(struct v4l2_subdev *sd,
> > > return 0;
> > > }
> > > +static u8 imx290_get_link_freq_index(struct imx290 *imx290)
> > > +{
> > > + const struct imx290_mode *cur_mode = imx290->current_mode;
> > > +
> > > + return (cur_mode->width == 1920) ? 0 : 1;
> >
> > Could you use (imx290->current_mode - imx290_modes) / sizeof(*imx290_modes)
> > or something like that? It'd have fewer chances of breaking if new modes
> > are added.
> >
> > > +}
> > > +
> > > +static s64 imx290_get_link_freq(struct imx290 *imx290)
> > > +{
> > > + u8 index = imx290_get_link_freq_index(imx290);
> > > +
> > > + if (imx290->nlanes == 4)
> > > + return imx290_link_freq_4lanes[index];
> > > + else
> > > + return imx290_link_freq_2lanes[index];
> >
> > Or even better: store the link frequencies to the modes themselves. They
> > are a property of the modes after all.
>
> Then we will get two sets (for 2 lanes and for 4 lanes) of two modes (1080p and 720p), right?
Correct.
>
> > > +}
> > > +
> > > +static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
> > > +{
> > > + s64 link_freq = imx290_get_link_freq(imx290);
> > > + u8 nlanes = imx290->nlanes;
> > > +
> > > + /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
> > > + return (link_freq * 2 * nlanes / 10);
> > > +}
> > > +
> > > static int imx290_set_fmt(struct v4l2_subdev *sd,
> > > struct v4l2_subdev_pad_config *cfg,
> > > struct v4l2_subdev_format *fmt)
> > > @@ -475,10 +498,14 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
> > > format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
> > > } else {
> > > format = &imx290->current_format;
> > > - __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
> > > - __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
> > > -
> > > imx290->current_mode = mode;
> > > +
> > > + if (imx290->link_freq)
> > > + __v4l2_ctrl_s_ctrl(imx290->link_freq,
> > > + imx290_get_link_freq_index(imx290));
> > > + if (imx290->pixel_rate)
> > > + __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate,
> > > + imx290_calc_pixel_rate(imx290));
> > > }
> > > *format = fmt->format;
> > > @@ -502,12 +529,11 @@ static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
> > > return 0;
> > > }
> > > -static int imx290_write_current_format(struct imx290 *imx290,
> > > - struct v4l2_mbus_framefmt *format)
> > > +static int imx290_write_current_format(struct imx290 *imx290)
> > > {
> > > int ret;
> > > - switch (format->code) {
> > > + switch (imx290->current_format.code) {
> > > case MEDIA_BUS_FMT_SRGGB10_1X10:
> > > ret = imx290_set_register_array(imx290, imx290_10bit_settings,
> > > ARRAY_SIZE(
> > > @@ -558,8 +584,8 @@ static int imx290_start_streaming(struct imx290 *imx290)
> > > return ret;
> > > }
> > > - /* Set current frame format */
> > > - ret = imx290_write_current_format(imx290, &imx290->current_format);
> > > + /* Apply the register values related to current frame format */
> > > + ret = imx290_write_current_format(imx290);
> > > if (ret < 0) {
> > > dev_err(imx290->dev, "Could not set frame format\n");
> > > return ret;
> > > @@ -821,12 +847,6 @@ static int imx290_probe(struct i2c_client *client)
> > > goto free_err;
> > > }
> > > - if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
> >
> > This check needs to be modified to correspond to the driver's new
> > capabilities, not removed.
>
> Agreed.
> Do I understand correct that as the driver uses two link frequencies
> for a given number of lanes now, it must check that *the both* frequencies
> (for the given number of lanes) are listed in the device tree node?
Yes. The smiapp driver does this, for example.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Laurent Pinchart @ 2020-05-26 10:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Ricardo Cañuelo, Collabora Kernel ML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Geert Uytterhoeven, Rob Herring, Wei Xu
In-Reply-To: <CAMuHMdXinhY13us9rt9h7EvrT_8zhnQg6tmOBtA0nEQ=1G1O7Q@mail.gmail.com>
Hi Geert,
On Tue, May 26, 2020 at 09:03:09AM +0200, Geert Uytterhoeven wrote:
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
>
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.
Please note that we're not talking about runtime regressions, as drivers
are not updated. It's "only" dtbs_check that would produce new errors.
> FTR, hence patches 1-3 are already in v5.7-rc7.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
From: Maxime Ripard @ 2020-05-26 10:20 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
devicetree, linux-clk, linux-i2c, Linux Upstreaming Team
In-Reply-To: <CAPpJ_ed9TMJjN8xS1_3saf5obQhULJSLNgQSAFxgiWM2QX9A7Q@mail.gmail.com>
Hi,
On Mon, May 11, 2020 at 11:12:05AM +0800, Jian-Hong Pan wrote:
> Jian-Hong Pan <jian-hong@endlessm.com> 於 2020年5月8日 週五 下午2:20寫道：
> >
> > Maxime Ripard <maxime@cerno.tech> 於 2020年5月8日 週五 上午1:22寫道：
> > >
> > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道：
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > > > > Hi Maxime,
> > > > > >
> > > > > > Thanks for your V2 patch series! I'm testing it.
> > > > > >
> > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > > > > System can boot into console text mode, but no graphic UI.
> > > > > >
> > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > > > > >
> > > > > > [ 5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > > > > [ 5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > > > > [ 5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > > > > [ 5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > > > > [ 5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > > > > [ 5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > > > > [ 5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > > > > [ 5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > > > > [ 5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > > > > [ 5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > > > > [ 5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > > > > [ 5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > > > > [ 5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > > > > [ 5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [ 5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > > > > [ 5.589297] fb0: switching to vc4drmfb from simple
> > > > > > [ 5.589433] Console: switching to colour dummy device 80x25
> > > > > > [ 5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > > > > [ 5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > > > > [ 5.601079] ------------[ cut here ]------------
> > > > > > [ 5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [ 5.601097] Modules linked in:
> > > > > > [ 5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > > > > [ 5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > > > > [ 5.601112] Workqueue: events deferred_probe_work_func
> > > > > > [ 5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > > > > [ 5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [ 5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [ 5.601124] sp : ffff80001217b410
> > > > > > [ 5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > > > > [ 5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > > > > [ 5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > > > > [ 5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > > > > [ 5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > > > > [ 5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > > > > [ 5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > > > > [ 5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > > > > [ 5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > > > > [ 5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > > > > [ 5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > > > > [ 5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > > > > [ 5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > > > > [ 5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > > > > [ 5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > > > > [ 5.601164] Call trace:
> > > > > > [ 5.601169] vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [ 5.601172] vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [ 5.601176] drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > > > > [ 5.601179] vc4_atomic_complete_commit+0x400/0x558
> > > > > > [ 5.601182] vc4_atomic_commit+0x1e0/0x200
> > > > > > [ 5.601185] drm_atomic_commit+0x4c/0x60
> > > > > > [ 5.601190] drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > > > > [ 5.601192] drm_client_modeset_commit_locked+0x5c/0x198
> > > > > > [ 5.601195] drm_client_modeset_commit+0x30/0x58
> > > > > > [ 5.601201] drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > > > > [ 5.601204] drm_fb_helper_set_par+0x30/0x68
> > > > > > [ 5.601208] fbcon_init+0x3d4/0x598
> > > > > > [ 5.601212] visual_init+0xb0/0x108
> > > > > > [ 5.601214] do_bind_con_driver+0x1d0/0x3a8
> > > > > > [ 5.601217] do_take_over_console+0x144/0x208
> > > > > > [ 5.601219] do_fbcon_takeover+0x68/0xd8
> > > > > > [ 5.601222] fbcon_fb_registered+0x100/0x118
> > > > > > [ 5.601226] register_framebuffer+0x1f4/0x338
> > > > > > [ 5.601229] __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > > > > [ 5.601232] drm_fbdev_client_hotplug+0xd4/0x1b0
> > > > > > [ 5.601235] drm_fbdev_generic_setup+0xb0/0x130
> > > > > > [ 5.601238] vc4_drm_bind+0x184/0x1a0
> > > > > > [ 5.601241] try_to_bring_up_master+0x168/0x1c8
> > > > > > [ 5.601244] __component_add+0xa4/0x170
> > > > > > [ 5.601246] component_add+0x14/0x20
> > > > > > [ 5.601248] vc4_vec_dev_probe+0x20/0x30
> > > > > > [ 5.601252] platform_drv_probe+0x54/0xa8
> > > > > > [ 5.601254] really_probe+0xd8/0x320
> > > > > > [ 5.601256] driver_probe_device+0x58/0xf0
> > > > > > [ 5.601258] __device_attach_driver+0x84/0xc8
> > > > > > [ 5.601263] bus_for_each_drv+0x78/0xc8
> > > > > > [ 5.601265] __device_attach+0xe4/0x140
> > > > > > [ 5.601267] device_initial_probe+0x14/0x20
> > > > > > [ 5.601269] bus_probe_device+0x9c/0xa8
> > > > > > [ 5.601271] deferred_probe_work_func+0x74/0xb0
> > > > > > [ 5.601276] process_one_work+0x1bc/0x338
> > > > > > [ 5.601279] worker_thread+0x1f8/0x428
> > > > > > [ 5.601282] kthread+0x138/0x158
> > > > > > [ 5.601286] ret_from_fork+0x10/0x1c
> > > > > > [ 5.601288] ---[ end trace cfba0996218c3f3d ]---
> > > > >
> > > > > Thanks for testing!
> > > > >
> > > > > Do you have a bit more details regarding your setup? Was it connected to an
> > > > > external display?
> > > >
> > > > Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> > > >
> > > > > If so, do you know the resolution it was trying to setup?
> > > >
> > > > According to the log, I think it is 1920x1080:
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 connected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-2 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > Composite-1 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> > > > exact sizes for initial modes
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 using initial mode 1920x1080 +0+0
> > > >
> > > > https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94
> > >
> > > It looks to be fairly standard then, and I'm testing on the same resolution so
> > > it should be alright.
> > >
> > > Given from your log, it looks like you're running as arm64 though, while I stuck
> > > with arm32, so it could be the explanation.
> >
> > Yes, I build it as arm64.
> >
> > > Can you share your config.txt and .config so that I can try to reproduce it
> > > here?
> >
> > Here is the config
> > https://gist.github.com/starnight/320b757441b6769c36160704b401c98b
>
> Here is the only one line in config.txt:
> enable_uart=1
>
> Actually, we make the Raspberry Pi's firmware bring up U-Boot, then
> U-Boot boots kernel.
I gave it a try with U-Boot with my latest work and couldn't reproduce it, so it
seems that I fixed it along the way
Maxime
^ permalink raw reply
* Re: [PATCH 1/4] i2c: smbus: add core function handling SMBus host-notify
From: Alain Volmat @ 2020-05-26 10:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: Benjamin Tissoires, robh+dt@kernel.org, mark.rutland@arm.com,
Pierre Yves MORDRET, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Fabrice GASNIER
In-Reply-To: <20200523104624.GB3459@ninjato>
On Sat, May 23, 2020 at 10:46:25AM +0000, Wolfram Sang wrote:
>
> Adding Benjamin who mainly implemented this.
>
> On Tue, May 05, 2020 at 07:51:08AM +0200, Alain Volmat wrote:
> > SMBus Host-Notify protocol, from the adapter point of view
> > consist of receiving a message from a client, including the
> > client address and some other data.
> >
> > It can be simply handled by creating a new slave device
> > and registering a callback performing the parsing of the
> > message received from the client.
> >
> > This commit introduces two new core functions
> > * i2c_new_smbus_host_notify_device
> > * i2c_free_smbus_host_notify_device
> > that take care of registration of the new slave device and
> > callback and will call i2c_handle_smbus_host_notify once a
> > Host-Notify event is received.
>
> Yay, cool idea to use the slave interface. I like it a lot!
>
> > +static int i2c_smbus_host_notify_cb(struct i2c_client *client,
> > + enum i2c_slave_event event, u8 *val)
> > +{
> > + struct i2c_smbus_host_notify_status *status = client->dev.platform_data;
> > + int ret;
> > +
> > + switch (event) {
> > + case I2C_SLAVE_WRITE_REQUESTED:
> > + status->notify_start = true;
> > + break;
> > + case I2C_SLAVE_WRITE_RECEIVED:
> > + /* We only retrieve the first byte received (addr)
> > + * since there is currently no way to retrieve the data
> > + * parameter from the client.
>
> Maybe s/no way/no support/ ? I still wonder if we couldn't add it
> somehow. Once we find a device which needs this, of course.
Indeed. Such support can be added later on once such device is found. For the
time being I will state "no support"
>
> > + */
> > + if (!status->notify_start)
> > + break;
> > + status->addr = *val;
> > + status->notify_start = false;
> > + break;
> > + case I2C_SLAVE_STOP:
>
> What about setting 'notify_start' to false here as well? In the case of
> an incomplete write?
Ok. I will check that notify_start is false before calling host_notify
(since otherwise it will call i2c_handle_smbus_host_notify with a bad addr
value) and reset notify_start to false if it is still true.
>
> > + ret = i2c_handle_smbus_host_notify(client->adapter,
> > + status->addr);
> > + if (ret < 0) {
> > + dev_warn(&client->adapter->dev, "failed to handle host_notify (%d)\n",
> > + ret);
>
> I think we should rather add such error strings to the core if we think
> they are needed. I am not convinced they are, though.
Agreed, this error can be removed.
>
> > + return ret;
> > + }
> > + break;
> > + default:
> > + /* Only handle necessary events */
> > + break;
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> Rest of the code looks good. Maybe we should compile all this only when
> I2C_SLAVE is enabled?
>
Yes, I will enclose that around I2C_SLAVE support check.
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: i2c-stm32: add SMBus Alert bindings
From: Alain Volmat @ 2020-05-26 10:31 UTC (permalink / raw)
To: wsa@kernel.org
Cc: Rob Herring, mark.rutland@arm.com, Pierre Yves MORDRET,
mcoquelin.stm32@gmail.com, Alexandre TORGUE,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Fabrice GASNIER
In-Reply-To: <20200523103601.GA3459@ninjato>
On Sat, May 23, 2020 at 10:36:01AM +0000, wsa@kernel.org wrote:
>
> > > > + st,smbus-alert:
> > > > + description: Enable the SMBus Alert feature
> > > > + $ref: /schemas/types.yaml#/definitions/flag
> > > > +
> > >
> > > We already have smbus_alert interrupt. Can't you just check for this in
> > > the slave nodes and enable if found?
> >
> > My understanding reading the code (smbalert_probe within i2c-smbus.c, of_i2c_setup_smbus_alert called when
> > registering an adapter within i2c-core-smbus.c) is that smbus_alert refers to an interrupt on the
> > adapter side. That is an interrupt that would be triggered when the adapter is receiving an smbus_alert
> > message.
> > In our case (stm32f7), we do not have specific interrupt for that purpose. The interrupt triggered when
> > an SMBUS Alert is received (by the adapter) is the same interrupt as for other reasons and we check
> > within the irq handler within stm32f7 the reason before calling i2c_handle_smbus_alert if the status
> > register indicated an SMBUS Alert.
> > So my understanding is that we cannot rely on the mechanism of naming an interrupt smbus_alert.
> > Did I misunderstood something ?
>
> I just wonder what is bad about specifying the same interrupt twice in
> the interrupt properties? You could then check in probe if "smbus_alert"
> is populated and if it matches the main irq.
>
Here's my understanding of the current implementation.
During the adapter registration, the function of_i2c_setup_smbus_alert is called
and if a interrupt is named "smbus_alert" in the adapter node, a new device
"smbus_alert" will be created. This will leads to smbalert_probe to be called,
and a request_irq will be done with the irq value read from the adapter node.
This means that we will have both our handle (the handler of the main irq
of the stm32 i2c driver) and the smbus_alert handler on the same irq. Leading
to smbus_alert being called everytime there is a irq (most of the time not
smbus_alert related) coming from the stm32_i2c. (since this is our main irq).
So to me this approach can't work. I'd understand if the smbus_alert property
was on the client node in the same way as it is done for host-notify however
that's not the case.
This is why I was proposing to have our own st,smbus-alert property to decide
to enable or not the smbus_alert. In our case, we cannot rely on the mechanism
done by of_i2c_setup_smbus_alert since for us, smbus_alert irq is just one
case of all the other stm32 i2c irq. (this is the same irq, and we check after
by reading the interrupt status register).
^ permalink raw reply
* Re: [PATCH v5 6/8] drm/panel: Add ilitek ili9341 panel driver
From: Noralf Trønnes @ 2020-05-26 10:38 UTC (permalink / raw)
To: dillon min, Andy Shevchenko
Cc: Linus Walleij, Mark Brown, devicetree, linux-arm Mailing List,
Linux Kernel Mailing List, linux-spi, linux-stm32, dri-devel,
linux-clk, Sam Ravnborg
In-Reply-To: <CAL9mu0+jmcivC6zAXxK0-oXy3n44pAU1QGD7BDq=CT2D7twROQ@mail.gmail.com>
Den 26.05.2020 11.08, skrev dillon min:
> Hi Andy,
>
> Thanks for input.
>
> On Tue, May 26, 2020 at 3:46 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
>>
>> On Mon, May 25, 2020 at 6:46 AM <dillon.minfei@gmail.com> wrote:
>>>
>>> From: dillon min <dillon.minfei@gmail.com>
>>>
>>> This driver combine tiny/ili9341.c mipi_dbi_interface driver
>>> with mipi_dpi_interface driver, can support ili9341 with serial
>>> mode or parallel rgb interface mode by register configuration.
>>
>> Noralf told once that this driver should be unified with mi0283qt.c.
>>
>> So, what should we do here?
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>
> from sam's suggestion, we can't setup two drivers to support one panel
> in the tree. so, i copy the mipi dbi part from tiny/ili9341.c. to this driver
> from register settings and dts binding is keep the same to tiny/ili9341.c.
>
> so, in my opinion if tiny/ili9341.c is unified with mi0283qt.c, this
> driver should be
> too.
>
There's a discussion about MIPI DBI panels here:
MIPI DSI, DBI, and tinydrm drivers
https://lists.freedesktop.org/archives/dri-devel/2020-May/267031.html
Noralf.
> thanks.
>
> best regards,
>
> Dillon,
>
^ 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