* Re: [PATCH 0/3] Add WLAN/BT support
From: Geert Uytterhoeven @ 2019-07-12 13:52 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Simon Horman, Geert Uytterhoeven,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Paterson, Fabrizio Castro
In-Reply-To: <1562321720-18735-1-git-send-email-biju.das@bp.renesas.com>
Hi Biju,
On Fri, Jul 5, 2019 at 12:20 PM Biju Das <biju.das@bp.renesas.com> wrote:
> This series adds WLAN/BT support for the HiHope RZ/G2M platform.
>
> This patchset is based on renesas devel branch.
>
> Biju Das (3):
> arm64: dts: renesas: hihope-common: Add PCA9654 I/O expander
> arm64: dts: renesas: hihope-common: Add BT support
> arm64: dts: renesas: hihope-common: Add WLAN support
Thanks, applied and queued for v5.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: renesas: hihope-common: Add PCA9654 I/O expander
From: Geert Uytterhoeven @ 2019-07-12 13:43 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Simon Horman, Geert Uytterhoeven,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Paterson, Fabrizio Castro
In-Reply-To: <TYAPR01MB2111E5F445AC1CEA0C720BD9B8F20@TYAPR01MB2111.jpnprd01.prod.outlook.com>
Hi Biju,
On Fri, Jul 12, 2019 at 3:22 PM Biju Das <biju.das@bp.renesas.com> wrote:
> > Subject: Re: [PATCH 1/3] arm64: dts: renesas: hihope-common: Add PCA9654 I/O expander
> > On Fri, Jul 5, 2019 at 12:20 PM Biju Das <biju.das@bp.renesas.com> wrote:
> > > Enable PCA9654 GPIO expander, so that we can configure its GPIOs later.
> > >
> > > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> >
> > > --- a/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> > > @@ -162,6 +162,13 @@
> > > clock-frequency = <400000>;
> > > status = "okay";
> > >
> > > + gpio_expander: gpio@20 {
> > > + compatible = "onnn,pca9654";
> > > + reg = <0x20>;
> > > + gpio-controller;
> > > + #gpio-cells = <2>;
> >
> > You may want to describe that the interrupt output is tied to GP5_25?
>
> BT_REG_ON and WLAN_REG_ON are output pins. That is the reason, I haven't described the interrupt output.
> If needed, I can add this. Please let me know.
OK, it's fine for me (for now).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: renesas: hihope-common: Add HDMI audio support
From: Geert Uytterhoeven @ 2019-07-12 13:42 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Simon Horman,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Paterson, Biju Das, xu_shunji
In-Reply-To: <1562333979-28516-4-git-send-email-fabrizio.castro@bp.renesas.com>
Hi Fabrizio,
On Fri, Jul 5, 2019 at 3:40 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> This patch adds support for HDMI audio to the device tree
> common to the HiHope RZ/G2M and the HiHope RZ/G2N.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> @@ -168,6 +180,7 @@
>
> &hdmi0 {
> status = "okay";
> + #sound-dai-cells = <0>;
Why the above line?
With the above question answered:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 6/8] PCI: al: Add support for DW based driver type
From: Bjorn Helgaas @ 2019-07-12 13:42 UTC (permalink / raw)
To: Jonathan Chocron
Cc: lorenzo.pieralisi, jingoohan1, gustavo.pimentel, robh+dt,
mark.rutland, dwmw, benh, alisaidi, ronenk, barakw, talel,
hanochu, hhhawa, linux-pci, linux-kernel, devicetree
In-Reply-To: <20190710164519.17883-7-jonnyc@amazon.com>
On Thu, Jul 11, 2019 at 05:57:05PM +0300, Jonathan Chocron wrote:
> This driver is DT based and utilizes the DesignWare APIs.
> It allows using a smaller ECAM range for a larger bus range -
> usually an entire bus uses 1MB of address space, but the driver
> can use it for a larger number of buses.
>
> All link initializations are handled by the boot FW.
>
> Signed-off-by: Jonathan Chocron <jonnyc@amazon.com>
> ---
> drivers/pci/controller/dwc/Kconfig | 11 +
> drivers/pci/controller/dwc/pcie-al.c | 397 +++++++++++++++++++++++++++
> 2 files changed, 408 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
> index a6ce1ee51b4c..51da9cb219aa 100644
> --- a/drivers/pci/controller/dwc/Kconfig
> +++ b/drivers/pci/controller/dwc/Kconfig
> @@ -230,4 +230,15 @@ config PCIE_UNIPHIER
> Say Y here if you want PCIe controller support on UniPhier SoCs.
> This driver supports LD20 and PXs3 SoCs.
>
> +config PCIE_AL
> + bool "Amazon Annapurna Labs PCIe controller"
> + depends on OF && (ARM64 || COMPILE_TEST)
> + depends on PCI_MSI_IRQ_DOMAIN
> + select PCIE_DW_HOST
> + help
> + Say Y here to enable support of the Annapurna Labs PCIe controller IP
> + on Amazon SoCs.
> + The PCIe controller uses the DesignWare core plus
> + Amazon-specific hardware wrappers.
Is this one paragraph or two?
This should mention the fact that only DT platforms need
CONFIG_PCIE_AL. ACPI platforms with the Annapurna Labs PCIe
controller don't need this.
> +
> endmenu
> diff --git a/drivers/pci/controller/dwc/pcie-al.c b/drivers/pci/controller/dwc/pcie-al.c
> index 3ab58f0584a8..2742a0895aab 100644
> --- a/drivers/pci/controller/dwc/pcie-al.c
> +++ b/drivers/pci/controller/dwc/pcie-al.c
> @@ -91,3 +91,400 @@ struct pci_ecam_ops al_pcie_ops = {
> };
>
> #endif /* defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS) */
> +
> +#ifdef CONFIG_PCIE_AL
> +
> +#include <linux/of_pci.h>
> +#include "pcie-designware.h"
> +
> +#define AL_PCIE_REV_ID_2 2
> +#define AL_PCIE_REV_ID_3 3
> +#define AL_PCIE_REV_ID_4 4
> +
> +/* The AXI regs are always at the beginning of the PCIE controller reg space. */
> +#define AXI_BASE_OFFSET 0x0
> +
> +#define DEVICE_ID_OFFSET 0x16c
> +
> +#define DEVICE_REV_ID 0x0
> +#define DEVICE_REV_ID_DEV_ID_MASK 0xFFFF0000
> +#define DEVICE_REV_ID_DEV_ID_SHIFT 16
> +
> +#define DEVICE_REV_ID_DEV_ID_X4 (0 << DEVICE_REV_ID_DEV_ID_SHIFT)
> +#define DEVICE_REV_ID_DEV_ID_X8 (2 << DEVICE_REV_ID_DEV_ID_SHIFT)
> +#define DEVICE_REV_ID_DEV_ID_X16 (4 << DEVICE_REV_ID_DEV_ID_SHIFT)
> +
> +/* The ob_ctrl offset inside the axi regs is different between revisions.
> + */
s/axi/AXI/ to be consistent.
Fix comment style (either single-line with "/* ... */" or multi-line
with "/*" on first line and "*/" on last line).
> +#define OB_CTRL_REV1_2_OFFSET 0x0040
> +#define OB_CTRL_REV3_5_OFFSET 0x0030
> +
> +#define CFG_TARGET_BUS 0x0
> +#define CFG_TARGET_BUS_MASK_SHIFT 0
> +#define CFG_TARGET_BUS_BUSNUM_SHIFT 8
> +
> +#define CFG_CONTROL 0x4
> +#define CFG_CONTROL_SUBBUS_MASK 0x0000FF00
> +#define CFG_CONTROL_SUBBUS_SHIFT 8
> +#define CFG_CONTROL_SEC_BUS_MASK 0x00FF0000
> +#define CFG_CONTROL_SEC_BUS_SHIFT 16
> +
> +struct al_pcie_reg_offsets {
> + unsigned int ob_ctrl;
> +};
> +
> +struct al_pcie_target_bus_cfg {
> + u8 reg_val;
> + u8 reg_mask;
> + u8 ecam_mask;
> +};
> +
> +struct al_pcie {
> + struct dw_pcie *pci;
> + void __iomem *controller_base; /* base of PCIe unit (not DW core) */
> + void __iomem *dbi_base;
I *guess* this is different from the dw_pcie.dbi_base?
> + resource_size_t ecam_size;
> + struct device *dev;
> + unsigned int controller_rev_id;
> + struct al_pcie_reg_offsets reg_offsets;
> + struct al_pcie_target_bus_cfg target_bus_cfg;
> +};
> +
> +#define PCIE_ECAM_DEVFN(x) (((x) & 0xff) << 12)
> +
> +#define to_al_pcie(x) dev_get_drvdata((x)->dev)
> +
> +static int al_pcie_rev_id_get(struct al_pcie *pcie, unsigned int *rev_id)
I think al_pcie_rev_id_get() and al_pcie_reg_offsets_set() are more
complicated than necessary, at least for the current code. All you're
really using is something like this:
static void al_pcie_rev_id_get(...)
{
...
switch (dev_rev_id) {
case DEVICE_REV_ID_DEV_ID_X4:
pcie->reg_offsets.ob_ctrl = OB_CTRL_REV1_2_OFFSET;
break;
case DEVICE_REV_ID_DEV_ID_X8:
case DEVICE_REV_ID_DEV_ID_X16:
pcie->reg_offsets.ob_ctrl = OB_CTRL_REV3_5_OFFSET;
break;
default:
dev_err("unsupported rev_id\n");
break;
}
}
> +{
> + void __iomem *dev_rev_id_addr;
> + u32 dev_rev_id;
> +
> + dev_rev_id_addr = (void __iomem *)((uintptr_t)pcie->controller_base +
> + AXI_BASE_OFFSET + DEVICE_ID_OFFSET + DEVICE_REV_ID);
> +
> + dev_rev_id = readl(dev_rev_id_addr) & DEVICE_REV_ID_DEV_ID_MASK;
> +
> + switch (dev_rev_id) {
> + case DEVICE_REV_ID_DEV_ID_X4:
> + *rev_id = AL_PCIE_REV_ID_2;
> + break;
> + case DEVICE_REV_ID_DEV_ID_X8:
> + *rev_id = AL_PCIE_REV_ID_3;
> + break;
> + case DEVICE_REV_ID_DEV_ID_X16:
> + *rev_id = AL_PCIE_REV_ID_4;
> + break;
> + default:
> + dev_err(pcie->dev, "Unsupported dev_rev_id (0x%08x)\n",
> + dev_rev_id);
> + return -EINVAL;
> + }
> +
> + dev_dbg(pcie->dev, "dev_rev_id: 0x%08x\n", dev_rev_id);
> +
> + return 0;
> +}
> +
> +static int al_pcie_reg_offsets_set(struct al_pcie *pcie)
> +{
> + switch (pcie->controller_rev_id) {
> + case AL_PCIE_REV_ID_2:
> + pcie->reg_offsets.ob_ctrl = OB_CTRL_REV1_2_OFFSET;
> + break;
> + case AL_PCIE_REV_ID_3:
> + case AL_PCIE_REV_ID_4:
> + pcie->reg_offsets.ob_ctrl = OB_CTRL_REV3_5_OFFSET;
> + break;
> + default:
> + dev_err(pcie->dev, "Unsupported controller rev_id: 0x%x\n",
> + pcie->controller_rev_id);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static inline void al_pcie_target_bus_set(struct al_pcie *pcie,
> + u8 target_bus,
> + u8 mask_target_bus)
> +{
> + void __iomem *cfg_control_addr;
> + u32 reg = (target_bus << CFG_TARGET_BUS_BUSNUM_SHIFT) |
> + mask_target_bus;
> +
> + cfg_control_addr = (void __iomem *)((uintptr_t)pcie->controller_base +
> + AXI_BASE_OFFSET + pcie->reg_offsets.ob_ctrl +
> + CFG_TARGET_BUS);
> +
> + writel(reg, cfg_control_addr);
> +}
> +
> +static void __iomem *al_pcie_conf_addr_map(struct al_pcie *pcie,
> + unsigned int busnr,
> + unsigned int devfn)
> +{
> + void __iomem *pci_base_addr;
> + struct pcie_port *pp = &pcie->pci->pp;
> + struct al_pcie_target_bus_cfg *target_bus_cfg = &pcie->target_bus_cfg;
> + unsigned int busnr_ecam = busnr & target_bus_cfg->ecam_mask;
> + unsigned int busnr_reg = busnr & target_bus_cfg->reg_mask;
> +
> + pci_base_addr = (void __iomem *)((uintptr_t)pp->va_cfg0_base +
> + (busnr_ecam << 20) +
> + PCIE_ECAM_DEVFN(devfn));
> +
> + if (busnr_reg != target_bus_cfg->reg_val) {
> + dev_dbg(pcie->pci->dev, "Changing target bus busnum val from %d to %d\n",
> + target_bus_cfg->reg_val, busnr_reg);
> + target_bus_cfg->reg_val = busnr_reg;
> + al_pcie_target_bus_set(pcie,
> + target_bus_cfg->reg_val,
> + target_bus_cfg->reg_mask);
> + }
> +
> + return pci_base_addr;
> +}
> +
> +static int al_pcie_rd_other_conf(struct pcie_port *pp,
> + struct pci_bus *bus,
> + unsigned int devfn,
> + int where,
> + int size,
> + u32 *val)
Rewrap to use fewer lines.
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct al_pcie *pcie = to_al_pcie(pci);
> + unsigned int busnr = bus->number;
> + void __iomem *pci_addr;
> + int rc;
> +
> + pci_addr = al_pcie_conf_addr_map(pcie, busnr, devfn);
> +
> + rc = dw_pcie_read(pci_addr + where, size, val);
> +
> + dev_dbg(pci->dev, "%d-byte config read from %04x:%02x:%02x.%d offset %#x (pci_addr: 0x%p) - val:0x%x\n",
> + size, pci_domain_nr(bus), bus->number,
> + PCI_SLOT(devfn), PCI_FUNC(devfn), where,
> + (pci_addr + where), *val);
> +
> + return rc;
> +}
> +
> +static int al_pcie_wr_other_conf(struct pcie_port *pp,
> + struct pci_bus *bus,
> + unsigned int devfn,
> + int where,
> + int size,
> + u32 val)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct al_pcie *pcie = to_al_pcie(pci);
> + unsigned int busnr = bus->number;
> + void __iomem *pci_addr;
> + int rc;
> +
> + pci_addr = al_pcie_conf_addr_map(pcie, busnr, devfn);
> +
> + rc = dw_pcie_write(pci_addr + where, size, val);
> +
> + dev_dbg(pci->dev, "%d-byte config write to %04x:%02x:%02x.%d offset %#x (pci_addr: 0x%p) - val:0x%x\n",
> + size, pci_domain_nr(bus), bus->number,
> + PCI_SLOT(devfn), PCI_FUNC(devfn), where,
> + (pci_addr + where), val);
> +
> + return rc;
> +}
> +
> +static int al_pcie_config_prepare(struct al_pcie *pcie)
> +{
> + struct al_pcie_target_bus_cfg *target_bus_cfg;
> + struct pcie_port *pp = &pcie->pci->pp;
> + unsigned int ecam_bus_mask;
> + u8 secondary_bus;
> + u8 subordinate_bus;
> + void __iomem *cfg_control_addr;
> + u32 cfg_control;
> + u32 reg = 0;
Why is this initialized? It doesn't look like it can be used before
being set.
> + target_bus_cfg = &pcie->target_bus_cfg;
> +
> + ecam_bus_mask = (pcie->ecam_size >> 20) - 1;
> + if (ecam_bus_mask > 255) {
> + dev_warn(pcie->dev, "ECAM window size is larger than 256MB. Cutting off at 256\n");
> + ecam_bus_mask = 255;
> + }
> +
> + /* This portion is taken from the transaction address */
> + target_bus_cfg->ecam_mask = ecam_bus_mask;
> + /* This portion is taken from the cfg_target_bus reg */
> + target_bus_cfg->reg_mask = ~target_bus_cfg->ecam_mask;
> + target_bus_cfg->reg_val = pp->busn->start & target_bus_cfg->reg_mask;
> +
> + al_pcie_target_bus_set(pcie,
> + target_bus_cfg->reg_val,
> + target_bus_cfg->reg_mask);
> +
> + secondary_bus = pp->busn->start + 1;
> + subordinate_bus = pp->busn->end;
> +
> + /* Set the valid values of secondary and subordinate buses */
> + cfg_control_addr = pcie->controller_base +
> + AXI_BASE_OFFSET + pcie->reg_offsets.ob_ctrl + CFG_CONTROL;
> +
> + cfg_control = readl(cfg_control_addr);
> +
> + reg = (cfg_control & ~CFG_CONTROL_SEC_BUS_MASK) |
> + (secondary_bus << CFG_CONTROL_SEC_BUS_SHIFT);
> + reg = (reg & ~CFG_CONTROL_SUBBUS_MASK) |
> + (subordinate_bus << CFG_CONTROL_SUBBUS_SHIFT);
> +
> + writel(reg, cfg_control_addr);
> +
> + return 0;
> +}
> +
> +static int al_pcie_host_init(struct pcie_port *pp)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct al_pcie *pcie = to_al_pcie(pci);
> + int link_up = 0;
> + u32 reg = 0;
Why initialize link_up and reg?
> + int rc;
> +
> + reg = dw_pcie_readb_dbi(pci, PCI_HEADER_TYPE);
> + if (reg != PCI_HEADER_TYPE_BRIDGE) {
> + dev_err(pci->dev, "PCIe controller is not set to bridge type (%d)!\n",
> + reg);
> + return -EIO;
> + }
> +
> + link_up = dw_pcie_link_up(pci);
> + if (!link_up) {
> + dev_err(pci->dev, "link in not up!\n");
s/in/is/
> + return -ENOLINK;
> + }
> +
> + dev_info(pci->dev, "link is up\n");
> +
> + rc = al_pcie_rev_id_get(pcie, &pcie->controller_rev_id);
> + if (rc)
> + return rc;
> +
> + rc = al_pcie_reg_offsets_set(pcie);
> + if (rc)
> + return rc;
> +
> + rc = al_pcie_config_prepare(pcie);
> + if (rc)
> + return rc;
> +
> + return 0;
> +}
> +
> +static const struct dw_pcie_host_ops al_pcie_host_ops = {
> + .rd_other_conf = al_pcie_rd_other_conf,
> + .wr_other_conf = al_pcie_wr_other_conf,
> + .host_init = al_pcie_host_init,
> +};
> +
> +static int al_add_pcie_port(struct pcie_port *pp,
> + struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + int ret;
> +
> + pp->ops = &al_pcie_host_ops;
> +
> + ret = dw_pcie_host_init(pp);
> + if (ret) {
> + dev_err(dev, "failed to initialize host\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static const struct dw_pcie_ops dw_pcie_ops = {
> +};
> +
> +static int al_pcie_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct al_pcie *al_pcie;
> + struct dw_pcie *pci;
> + struct resource *dbi_res;
> + struct resource *controller_res;
> + struct resource *ecam_res;
> + int ret;
> +
> + al_pcie = devm_kzalloc(dev, sizeof(*al_pcie), GFP_KERNEL);
> + if (!al_pcie)
> + return -ENOMEM;
> +
> + pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> + if (!pci)
> + return -ENOMEM;
> +
> + pci->dev = dev;
> + pci->ops = &dw_pcie_ops;
> +
> + al_pcie->pci = pci;
> + al_pcie->dev = dev;
> +
> + dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
> + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_res);
> + if (IS_ERR(pci->dbi_base)) {
> + dev_err(dev, "couldn't remap dbi base %p\n", dbi_res);
%pR (see below).
> + return PTR_ERR(pci->dbi_base);
> + }
> +
> + ecam_res = platform_get_resource_byname(pdev,
> + IORESOURCE_MEM,
> + "config");
> + if (!ecam_res) {
> + dev_err(dev, "couldn't find 'config' reg in DT\n");
> + return -ENOENT;
> + }
> + al_pcie->ecam_size = resource_size(ecam_res);
> +
> + controller_res = platform_get_resource_byname(pdev,
> + IORESOURCE_MEM,
> + "controller");
> + al_pcie->controller_base = devm_ioremap_resource(dev,
> + controller_res);
Several of these function calls would fit on one line, or at least
fewer than they currently use.
> + if (IS_ERR(al_pcie->controller_base)) {
> + dev_err(dev, "couldn't remap controller base %p\n",
> + controller_res);
Use %pR. I think this %p prints the address of the struct resource,
not the address you tried to map.
> + return PTR_ERR(al_pcie->controller_base);
> + }
> +
> + dev_dbg(dev, "From DT: dbi_base: 0x%llx, controller_base: 0x%llx\n",
> + dbi_res->start, controller_res->start);
Use %pR instead of printing dbi_res->start, controller_res->start.
> +
> + platform_set_drvdata(pdev, al_pcie);
> +
> + ret = al_add_pcie_port(&pci->pp, pdev);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static const struct of_device_id al_pcie_of_match[] = {
> + { .compatible = "amazon,al-pcie",
> + .data = NULL,
".data = NULL" is unnecessary.
> + },
> + {},
> +};
> +
> +static struct platform_driver al_pcie_driver = {
> + .driver = {
> + .name = "al-pcie",
> + .of_match_table = al_pcie_of_match,
> + .suppress_bind_attrs = true,
> + },
> + .probe = al_pcie_probe,
> +};
> +builtin_platform_driver(al_pcie_driver);
> +
> +#endif /* CONFIG_PCIE_AL*/
> --
> 2.17.1
>
>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add SSIU support for sound
From: Geert Uytterhoeven @ 2019-07-12 13:27 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Simon Horman,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Paterson, Biju Das
In-Reply-To: <1562333979-28516-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Fri, Jul 5, 2019 at 3:39 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Add SSIU support to the SoC DT as the sound driver supports
> it now, and also since the sound driver can now handle
> BUSIF0-7 via SSIU remove the no longer needed "rxu" and "txu"
> properties.
>
> Based on similar work from Kuninori Morimoto and Simon Horman:
> 8d14bfa074db ("arm64: dts: renesas: r8a7796: add SSIU support for
> sound")
> 10bd03fa896e ("arm64: dts: renesas: r8a7796: remove BUSIF0 settings from
> rcar_sound,ssi")
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: crypto: Convert Allwinner A10 Security Engine to a schema
From: Rob Herring @ 2019-07-12 13:23 UTC (permalink / raw)
Cc: Mark Rutland, devicetree, Herbert Xu, Maxime Ripard, Chen-Yu Tsai,
linux-crypto, Frank Rowand, David S . Miller, linux-arm-kernel
In-Reply-To: <20190711122301.8193-1-maxime.ripard@bootlin.com>
On Thu, 11 Jul 2019 14:23:01 +0200, Maxime Ripard wrote:
> The older Allwinner SoCs have a crypto engine that is supported in Linux,
> with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../crypto/allwinner,sun4i-a10-crypto.yaml | 79 +++++++++++++++++++
> .../devicetree/bindings/crypto/sun4i-ss.txt | 23 ------
> 2 files changed, 79 insertions(+), 23 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
> delete mode 100644 Documentation/devicetree/bindings/crypto/sun4i-ss.txt
>
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: bus: Convert Allwinner DE2 bus to a schema
From: Rob Herring @ 2019-07-12 13:23 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Frank Rowand,
linux-arm-kernel
In-Reply-To: <20190711094036.21777-1-maxime.ripard@bootlin.com>
On Thu, Jul 11, 2019 at 11:40:36AM +0200, Maxime Ripard wrote:
> The Allwinner SoCs using the second generation of the display engine have a
> bus for that display engine. The bus is supported in Linux, with a matching
> Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../bus/allwinner,sun50i-a64-de2.yaml | 84 +++++++++++++++++++
> .../bindings/bus/sun50i-de2-bus.txt | 40 ---------
> 2 files changed, 84 insertions(+), 40 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
> delete mode 100644 Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
> new file mode 100644
> index 000000000000..b9734f8109c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
> @@ -0,0 +1,84 @@
> +# SPDX-License-Identifier: GPL2
I fixed this up.
Rob
^ permalink raw reply
* RE: [PATCH 1/3] arm64: dts: renesas: hihope-common: Add PCA9654 I/O expander
From: Biju Das @ 2019-07-12 13:21 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Mark Rutland, Simon Horman, Geert Uytterhoeven,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>, Chris Paterson,
Fabrizio Castro
In-Reply-To: <CAMuHMdU79JQfEH5hY=wjyknE+sLpS6i3GeXYZ5Z=uzWkWDC-DA@mail.gmail.com>
Hi Geert,
Thanks for the feedback.
> Subject: Re: [PATCH 1/3] arm64: dts: renesas: hihope-common: Add PCA9654
> I/O expander
>
> Hi Biju,
>
> On Fri, Jul 5, 2019 at 12:20 PM Biju Das <biju.das@bp.renesas.com> wrote:
> > Enable PCA9654 GPIO expander, so that we can configure its GPIOs later.
> >
> > Signed-off-by: Biju Das <biju.das@bp.renesas.com>
>
> > --- a/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> > @@ -162,6 +162,13 @@
> > clock-frequency = <400000>;
> > status = "okay";
> >
> > + gpio_expander: gpio@20 {
> > + compatible = "onnn,pca9654";
> > + reg = <0x20>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
>
> You may want to describe that the interrupt output is tied to GP5_25?
BT_REG_ON and WLAN_REG_ON are output pins. That is the reason, I haven't described the interrupt output.
If needed, I can add this. Please let me know.
> > + };
> > +
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: bus: Convert Allwinner DE2 bus to a schema
From: Rob Herring @ 2019-07-12 13:21 UTC (permalink / raw)
Cc: Mark Rutland, devicetree, Maxime Ripard, Chen-Yu Tsai,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20190711094036.21777-1-maxime.ripard@bootlin.com>
On Thu, 11 Jul 2019 11:40:36 +0200, Maxime Ripard wrote:
> The Allwinner SoCs using the second generation of the display engine have a
> bus for that display engine. The bus is supported in Linux, with a matching
> Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../bus/allwinner,sun50i-a64-de2.yaml | 84 +++++++++++++++++++
> .../bindings/bus/sun50i-de2-bus.txt | 40 ---------
> 2 files changed, 84 insertions(+), 40 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
> delete mode 100644 Documentation/devicetree/bindings/bus/sun50i-de2-bus.txt
>
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH] dt-bindings: input: Convert Allwinner LRADC to a schema
From: Rob Herring @ 2019-07-12 13:21 UTC (permalink / raw)
Cc: Mark Rutland, devicetree, Maxime Ripard, Dmitry Torokhov,
Chen-Yu Tsai, linux-input, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190711093835.20663-1-maxime.ripard@bootlin.com>
On Thu, 11 Jul 2019 11:38:35 +0200, Maxime Ripard wrote:
> The Allwinner SoCs have an LRADC used to report keys and supported in
> Linux, with a matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../input/allwinner,sun4i-a10-lradc-keys.yaml | 95 +++++++++++++++++++
> .../bindings/input/sun4i-lradc-keys.txt | 65 -------------
> 2 files changed, 95 insertions(+), 65 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
> delete mode 100644 Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
>
Applied, thanks.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: renesas: r8a774a1: Use extended audio dmac register
From: Geert Uytterhoeven @ 2019-07-12 13:14 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Simon Horman,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Paterson, Biju Das
In-Reply-To: <1562333979-28516-2-git-send-email-fabrizio.castro@bp.renesas.com>
On Fri, Jul 5, 2019 at 3:39 PM Fabrizio Castro
<fabrizio.castro@bp.renesas.com> wrote:
> Basic audio dmac register only supports busif from 0 to 3,
> in order to use busif4 ~ busif7 extended audio dmac registers
> need to be used.
>
> Based on similar work from Jiada Wang:
> 7a516e49d975 ("arm64: dts: renesas: use extended audio dmac register")
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Maxime Ripard @ 2019-07-12 13:10 UTC (permalink / raw)
To: Andrew Jeffery
Cc: linux-mmc, ulf.hansson, robh+dt, mark.rutland, joel,
adrian.hunter, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, ryanchen.aspeed
In-Reply-To: <20190712033214.24713-2-andrew@aj.id.au>
[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]
Hi,
On Fri, Jul 12, 2019 at 01:02:13PM +0930, Andrew Jeffery wrote:
> The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the
> SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> data bus if only a single slot is enabled.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> In v2:
>
> * Rename to aspeed,sdhci.yaml
> * Rename sd-controller compatible
> * Add `maxItems: 1` for reg properties
> * Move sdhci subnode description to patternProperties
> * Drop sdhci compatible requirement
> * #address-cells and #size-cells are required
> * Prevent additional properties
> * Implement explicit ranges in example
> * Remove slot property
>
> .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 90 +++++++++++++++++++
> 1 file changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
>
> diff --git a/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> new file mode 100644
> index 000000000000..67a691c3348c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: GPL-2.0-or-later
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mmc/aspeed,sdhci.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED SD/SDIO/eMMC Controller
> +
> +maintainers:
> + - Andrew Jeffery <andrew@aj.id.au>
> + - Ryan Chen <ryanchen.aspeed@gmail.com>
> +
> +description: |+
> + The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the SDIO
> + Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit data bus if
> + only a single slot is enabled.
> +
> + The two slots are supported by a common configuration area. As the SDHCIs for
> + the slots are dependent on the common configuration area, they are described
> + as child nodes.
> +
> +properties:
> + compatible:
> + enum: [ aspeed,ast2400-sd-controller, aspeed,ast2500-sd-controller ]
> + reg:
> + maxItems: 1
> + description: Common configuration registers
> + ranges: true
> + clocks:
> + maxItems: 1
> + description: The SD/SDIO controller clock gate
#address-cells and #size-cells have not been described here.
> +patternProperties:
> + "^sdhci@[0-9a-f]+$":
> + type: object
> + properties:
> + compatible:
> + enum: [ aspeed,ast2400-sdhci, aspeed,ast2500-sdhci ]
> + reg:
> + maxItems: 1
> + description: The SDHCI registers
> + clocks:
> + maxItems: 1
> + description: The SD bus clock
> + interrupts:
> + maxItems: 1
> + description: The SD interrupt shared between both slots
> + required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> +
> +additionalProperties: false
But that means that it will generate a warning in your DT if you ever
use them.
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
> + - clocks
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/aspeed-clock.h>
> + sdc@1e740000 {
> + compatible = "aspeed,ast2500-sd-controller";
> + reg = <0x1e740000 0x100>;
> + #address-cells = <1>;
> + #size-cells = <1>;
Starting with your example.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] PCI/VPD: Add VPD release quirk for Amazon Annapurna Labs host bridge
From: Bjorn Helgaas @ 2019-07-12 13:10 UTC (permalink / raw)
To: Jonathan Chocron
Cc: lorenzo.pieralisi, jingoohan1, gustavo.pimentel, robh+dt,
mark.rutland, dwmw, benh, alisaidi, ronenk, barakw, talel,
hanochu, hhhawa, linux-pci, linux-kernel, devicetree
In-Reply-To: <20190710164519.17883-4-jonnyc@amazon.com>
On Thu, Jul 11, 2019 at 05:55:56PM +0300, Jonathan Chocron wrote:
> The Amazon Annapurna Labs pcie host bridge exposes the VPD capability,
> but there is no actual support for it.
s/pcie/PCIe/
s/host bridge/Root Port/
> The reason for not using the already existing quirk_blacklist_vpd()
> is that, although this fails pci_vpd_read/write, the 'vpd' sysfs
> entry still exists. When running lspci -vv, for example, this
> results in the following error:
>
> pcilib: sysfs_read_vpd: read failed: Input/output error
>
> This quirk removes the sysfs entry, which avoids the error print.
>
> Signed-off-by: Jonathan Chocron <jonnyc@amazon.com>
> ---
> drivers/pci/vpd.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
> index 4963c2e2bd4c..b594b2895ffe 100644
> --- a/drivers/pci/vpd.c
> +++ b/drivers/pci/vpd.c
> @@ -644,4 +644,16 @@ static void quirk_chelsio_extend_vpd(struct pci_dev *dev)
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID,
> quirk_chelsio_extend_vpd);
>
> +static void quirk_al_vpd_release(struct pci_dev *dev)
> +{
> + if (dev->vpd) {
> + pci_vpd_release(dev);
> + dev->vpd = NULL;
> + pci_warn(dev, FW_BUG "Annapurna Labs pcie quirk - Releasing VPD capability (No support for VPD read/write transactions)\n");
The "Annapurna Labs pcie quirk" text is superfluous.
> + }
> +}
> +
> +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031,
> + PCI_CLASS_BRIDGE_PCI, 8, quirk_al_vpd_release);
Why DECLARE_PCI_FIXUP_CLASS_FINAL()? See comments on the MSI-X quirk
patch.
> +
> #endif
> --
> 2.17.1
>
>
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: dma: Convert Allwinner A10 DMA to a schema
From: Rob Herring @ 2019-07-12 13:09 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Vinod Koul,
open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190711092158.14678-2-maxime.ripard@bootlin.com>
On Thu, Jul 11, 2019 at 3:36 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> The older Allwinner SoCs have a DMA controller supported in Linux, with a
> matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../bindings/dma/allwinner,sun4i-a10-dma.yaml | 55 +++++++++++++++++++
> .../devicetree/bindings/dma/sun4i-dma.txt | 45 ---------------
> 2 files changed, 55 insertions(+), 45 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/allwinner,sun4i-a10-dma.yaml
> delete mode 100644 Documentation/devicetree/bindings/dma/sun4i-dma.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: dma: Convert Allwinner A31 and A64 DMA to a schema
From: Rob Herring @ 2019-07-12 13:07 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Vinod Koul,
open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190711092158.14678-3-maxime.ripard@bootlin.com>
On Thu, Jul 11, 2019 at 3:36 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> The newer Allwinner SoCs have a DMA controller supported in Linux, with a
> matching Device Tree binding.
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for that controller over to a YAML schemas.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> ---
> .../dma/allwinner,sun50i-a64-dma.yaml | 88 +++++++++++++++++++
> .../bindings/dma/allwinner,sun6i-a31-dma.yaml | 62 +++++++++++++
> .../devicetree/bindings/dma/sun6i-dma.txt | 81 -----------------
> 3 files changed, 150 insertions(+), 81 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml
> create mode 100644 Documentation/devicetree/bindings/dma/allwinner,sun6i-a31-dma.yaml
> delete mode 100644 Documentation/devicetree/bindings/dma/sun6i-dma.txt
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/8] PCI: Add Amazon's Annapurna Labs vendor ID
From: Bjorn Helgaas @ 2019-07-12 13:04 UTC (permalink / raw)
To: Jonathan Chocron
Cc: lorenzo.pieralisi, jingoohan1, gustavo.pimentel, robh+dt,
mark.rutland, dwmw, benh, alisaidi, ronenk, barakw, talel,
hanochu, hhhawa, linux-pci, linux-kernel, devicetree
In-Reply-To: <20190710164519.17883-2-jonnyc@amazon.com>
On Thu, Jul 11, 2019 at 05:53:31PM +0300, Jonathan Chocron wrote:
> Add Amazon's Annapurna Labs vendor ID to pci_ids.h.
>
> Signed-off-by: Jonathan Chocron <jonnyc@amazon.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> include/linux/pci_ids.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 0dd239f11e91..ed350fd522c6 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2568,6 +2568,8 @@
>
> #define PCI_VENDOR_ID_ASMEDIA 0x1b21
>
> +#define PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS 0x1c36
> +
> #define PCI_VENDOR_ID_CIRCUITCO 0x1cc8
> #define PCI_SUBSYSTEM_ID_CIRCUITCO_MINNOWBOARD 0x0001
>
> --
> 2.17.1
>
>
^ permalink raw reply
* Re: [PATCH 4/8] PCI: Add quirk to disable MSI support for Amazon's Annapurna Labs host bridge
From: Bjorn Helgaas @ 2019-07-12 13:04 UTC (permalink / raw)
To: Jonathan Chocron
Cc: lorenzo.pieralisi, jingoohan1, gustavo.pimentel, robh+dt,
mark.rutland, dwmw, benh, alisaidi, ronenk, barakw, talel,
hanochu, hhhawa, linux-pci, linux-kernel, devicetree
In-Reply-To: <20190710164519.17883-5-jonnyc@amazon.com>
On Thu, Jul 11, 2019 at 05:56:25PM +0300, Jonathan Chocron wrote:
> On some platforms, the host bridge exposes an MSI-X capability but
> doesn't actually support it.
> This causes a crash during initialization by the pcieport driver, since
> it tries to configure the MSI-X capability.
Nit: The formatting above is jarring to read because I can't tell
whether it's one paragraph or two.
Either rewrap it into a single paragraph or add a blank line to make
two paragraphs. I noticed this elsewhere, too, in a comment, I think.
s/host bridge/Root Port/, if I understand correctly.
I don't understand the "on some platforms..." part. Do you mean that
on *every* platform, this particular host bridge (identified by
[1c36:0031]) advertises an MSI-X capability that doesn't work?
Or are there some platforms that configure the bridge so it doesn't
advertise MSI-X at all, while other platforms configure it so it
*does* advertise MSI-X?
If there's a line or two of diagnostics from the crash you could
include here, that would help people who encounter the crash find
the solution.
> Signed-off-by: Jonathan Chocron <jonnyc@amazon.com>
> ---
> drivers/pci/quirks.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 11850b030637..0fb70d755977 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2925,6 +2925,14 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0x10a1,
> quirk_msi_intx_disable_qca_bug);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, 0xe091,
> quirk_msi_intx_disable_qca_bug);
> +
> +static void quirk_al_msi_disable(struct pci_dev *dev)
> +{
> + dev->no_msi = 1;
> + dev_warn(&dev->dev, "Annapurna Labs pcie quirk - disabling MSI\n");
s/pcie/PCIe/ in English text, comments, printk strings, etc.
Actually, I think the whole "Annapurna Labs pcie quirk" part is
probably unnecessary, since we can identify the device via the
dev_printk() info.
Speaking of which, you can use "pci_warn(dev)" here to be consistent
with the rest of the file.
> +}
> +DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031,
> + PCI_CLASS_BRIDGE_PCI, 8, quirk_al_msi_disable);
Why do you use the class fixup here instead of the simpler
DECLARE_PCI_FIXUP_FINAL()? Requiring the class to match
PCI_CLASS_BRIDGE_PCI suggests that there may be other [1c36:0031]
devices that are not Root Ports. If that's the case, please mention
it so it's clear why we need DECLARE_PCI_FIXUP_CLASS_FINAL(). If not,
just use DECLARE_PCI_FIXUP_FINAL().
> #endif /* CONFIG_PCI_MSI */
>
> /*
> --
> 2.17.1
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: mmc: Document Aspeed SD controller
From: Rob Herring @ 2019-07-12 13:03 UTC (permalink / raw)
To: Andrew Jeffery
Cc: linux-mmc, Ulf Hansson, Mark Rutland, Joel Stanley, Adrian Hunter,
devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-aspeed, linux-kernel@vger.kernel.org, Ryan Chen
In-Reply-To: <20190712033214.24713-2-andrew@aj.id.au>
On Thu, Jul 11, 2019 at 9:32 PM Andrew Jeffery <andrew@aj.id.au> wrote:
>
> The ASPEED SD/SDIO/eMMC controller exposes two slots implementing the
> SDIO Host Specification v2.00, with 1 or 4 bit data buses, or an 8 bit
> data bus if only a single slot is enabled.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> In v2:
>
> * Rename to aspeed,sdhci.yaml
> * Rename sd-controller compatible
> * Add `maxItems: 1` for reg properties
> * Move sdhci subnode description to patternProperties
> * Drop sdhci compatible requirement
> * #address-cells and #size-cells are required
> * Prevent additional properties
> * Implement explicit ranges in example
> * Remove slot property
>
> .../devicetree/bindings/mmc/aspeed,sdhci.yaml | 90 +++++++++++++++++++
> 1 file changed, 90 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/aspeed,sdhci.yaml
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: renesas: hihope-common: Add WLAN support
From: Geert Uytterhoeven @ 2019-07-12 12:54 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Simon Horman, Geert Uytterhoeven,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Paterson, Fabrizio Castro
In-Reply-To: <1562321720-18735-4-git-send-email-biju.das@bp.renesas.com>
On Fri, Jul 5, 2019 at 12:20 PM Biju Das <biju.das@bp.renesas.com> wrote:
> This patch enables WLAN support for the HiHope RZ/G2[MN] boards.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: renesas: hihope-common: Add BT support
From: Geert Uytterhoeven @ 2019-07-12 12:46 UTC (permalink / raw)
To: Biju Das
Cc: Rob Herring, Mark Rutland, Simon Horman, Geert Uytterhoeven,
Magnus Damm, Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Chris Paterson, Fabrizio Castro
In-Reply-To: <1562321720-18735-3-git-send-email-biju.das@bp.renesas.com>
On Fri, Jul 5, 2019 at 12:20 PM Biju Das <biju.das@bp.renesas.com> wrote:
> This patch enables BT support for the HiHope RZ/G2[MN] boards.
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] arm: dts: imx6qdl: add gpio expander pca9535
From: Gilles DOFFE @ 2019-07-12 12:45 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, festevam, s.hauer, robh+dt, linux-imx, kernel,
shawnguo
The pca9535 gpio expander is present on the Rex baseboard, but missing
from the dtsi.
Add the new gpio controller and the associated interrupt line
MX6QDL_PAD_NANDF_CS3__GPIO6_IO16.
Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com>
---
arch/arm/boot/dts/imx6qdl-rex.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-rex.dtsi b/arch/arm/boot/dts/imx6qdl-rex.dtsi
index 97f1659144ea..d5324c6761c1 100644
--- a/arch/arm/boot/dts/imx6qdl-rex.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-rex.dtsi
@@ -136,6 +136,19 @@
compatible = "atmel,24c02";
reg = <0x57>;
};
+
+ gpio8: pca9535@27 {
+ compatible = "nxp,pca9535";
+ reg = <0x27>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pca9535>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
};
&i2c3 {
@@ -237,6 +250,12 @@
>;
};
+ pinctrl_pca9535: pca9535 {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x00017059
+ >;
+ };
+
pinctrl_uart1: uart1grp {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v1 08/11] dt-bindings: display/bridge: Add bindings for ti949
From: Michael Drake @ 2019-07-12 12:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Andrzej Hajda, dri-devel, devicetree, linux-kernel, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, linux-kernel,
Patrick Glaser, Nate Case
In-Reply-To: <20190611181351.GW5016@pendragon.ideasonboard.com>
Hi Laurent,
On 11/06/2019 19:13, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:09PM +0100, Michael Drake wrote:
>> Adds device tree bindings for:
>>
>> TI DS90UB949-Q1 1080p HDMI to FPD-Link III bridge serializer
>>
>> It supports instantiation via device tree / ACPI table.
>>
>> The device has the compatible string "ti,ds90ub949", and
>> and allows an arrray of strings to be provided as regulator
>> names to enable for operation of the device.
>
> All the comments I made regarding the ds90ub948 DT bindings apply here
> too. Same for the comments related to the driver, they apply to the
> subsequent patches in this series.
OK, understood.
Thank you very much for the review.
>> Signed-off-by: Michael Drake <michael.drake@codethink.co.uk>
>> Cc: Patrick Glaser <pglaser@tesla.com>
>> Cc: Nate Case <ncase@tesla.com>
>> ---
>> .../bindings/display/bridge/ti,ds90ub949.txt | 24 +++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,ds90ub949.txt
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90ub949.txt b/Documentation/devicetree/bindings/display/bridge/ti,ds90ub949.txt
>> new file mode 100644
>> index 000000000000..3ba3897d5e81
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90ub949.txt
>> @@ -0,0 +1,24 @@
>> +TI DS90UB949-Q1 1080p HDMI to FPD-Link III bridge serializer
>> +============================================================
>> +
>> +This is the binding for Texas Instruments DS90UB949-Q1 bridge serializer.
>> +
>> +This device supports I2C only.
>> +
>> +Required properties:
>> +
>> +- compatible: "ti,ds90ub949"
>> +
>> +Optional properties:
>> +
>> +- regulators: List of regulator name strings to enable for operation of device.
>> +
>> +Example
>> +-------
>> +
>> +ti949: ds90ub949@0 {
>> + compatible = "ti,ds90ub949";
>> +
>> + regulators: "vcc",
>> + "vcc_hdmi";
>> +};
>
--
Michael Drake https://www.codethink.co.uk/
^ permalink raw reply
* Re: [PATCH v1 07/11] ti948: Add sysfs node for alive attribute
From: Michael Drake @ 2019-07-12 12:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Andrzej Hajda, dri-devel, devicetree, linux-kernel, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, linux-kernel,
Patrick Glaser, Nate Case
In-Reply-To: <20190611181144.GV5016@pendragon.ideasonboard.com>
Hi Laurent,
On 11/06/2019 19:11, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:08PM +0100, Michael Drake wrote:
>> This may be used by userspace to determine the state
>> of the device.
>
> Why is this needed ? Userspace shouldn't even be aware that this device
> exists.
The display (containing the ti948) could be unplugged. (See my
response to the feedback on the previous commit in the series.)
If you can suggest a better or more standard way of doing this
I would be very happy to learn of it.
>> Signed-off-by: Michael Drake <michael.drake@codethink.co.uk>
>> Cc: Patrick Glaser <pglaser@tesla.com>
>> Cc: Nate Case <ncase@tesla.com>
>> ---
>> drivers/gpu/drm/bridge/ti948.c | 28 ++++++++++++++++++++++++++--
>> 1 file changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti948.c b/drivers/gpu/drm/bridge/ti948.c
>> index b5c766711c4b..b624eaeabb43 100644
>> --- a/drivers/gpu/drm/bridge/ti948.c
>> +++ b/drivers/gpu/drm/bridge/ti948.c
>> @@ -412,6 +412,16 @@ static void ti948_alive_check(struct work_struct *work)
>> schedule_delayed_work(&ti948->alive_check, TI948_ALIVE_CHECK_DELAY);
>> }
>>
>> +static ssize_t alive_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct ti948_ctx *ti948 = ti948_ctx_from_dev(dev);
>> +
>> + return scnprintf(buf, PAGE_SIZE, "%u\n", (unsigned int)ti948->alive);
>> +}
>> +
>> +static DEVICE_ATTR_RO(alive);
>> +
>> static int ti948_pm_resume(struct device *dev)
>> {
>> struct ti948_ctx *ti948 = ti948_ctx_from_dev(dev);
>> @@ -614,17 +624,31 @@ static int ti948_probe(struct i2c_client *client,
>>
>> i2c_set_clientdata(client, ti948);
>>
>> + ret = device_create_file(&client->dev, &dev_attr_alive);
>> + if (ret) {
>> + dev_err(&client->dev, "Could not create alive attr\n");
>> + return ret;
>> + }
>> +
>> ret = ti948_pm_resume(&client->dev);
>> - if (ret != 0)
>> - return -EPROBE_DEFER;
>> + if (ret != 0) {
>> + ret = -EPROBE_DEFER;
>> + goto error;
>> + }
>>
>> dev_info(&ti948->i2c->dev, "End probe (addr: %x)\n", ti948->i2c->addr);
>>
>> return 0;
>> +
>> +error:
>> + device_remove_file(&client->dev, &dev_attr_alive);
>> + return ret;
>> }
>>
>> static int ti948_remove(struct i2c_client *client)
>> {
>> + device_remove_file(&client->dev, &dev_attr_alive);
>> +
>> return ti948_pm_suspend(&client->dev);
>> }
>>
>
--
Michael Drake https://www.codethink.co.uk/
^ permalink raw reply
* Re: [PATCH v1 06/11] ti948: Reconfigure in the alive check when device returns
From: Michael Drake @ 2019-07-12 12:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Andrzej Hajda, dri-devel, devicetree, linux-kernel, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, linux-kernel,
Patrick Glaser, Nate Case
In-Reply-To: <20190611181046.GU5016@pendragon.ideasonboard.com>
Hi Laurent,
On 11/06/2019 19:10, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:07PM +0100, Michael Drake wrote:
>> If the alive check detects a transition to the alive state,
>> the device configuration is rewritten.
>
> This seems like a big hack. You will have at the very least to explain
> why this is needed, and why you can't configure the device in response
> to drm_bridge operation calls.
The ti948 device is situated inside the housing of the LCD
panel. The ti949 is a normal i2c device on the system i2c
bus. In order for the ti948 to appear on the system's i2c
bus, the ti949 must be powered up and configured.
The panel is connected to the system via the FPD-Link III.
If a connector for the wire to the display is unplugged and
re-inserted, then the ti948 will drop out and come back.
Application note AN-2173, "I2C Communication Over
FPD-LinkIII with Bidirectional Control Channel" describes
this:
http://www.ti.com/lit/an/snla131a/snla131a.pdf
Perhaps I need to expand the commit message to explain this?
Alternatively is there a more standard way of dealing with
remotely connected i2c devices?
>> Signed-off-by: Michael Drake <michael.drake@codethink.co.uk>
>> Cc: Patrick Glaser <pglaser@tesla.com>
>> Cc: Nate Case <ncase@tesla.com>
>> ---
>> drivers/gpu/drm/bridge/ti948.c | 19 ++++++++++++++++++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti948.c b/drivers/gpu/drm/bridge/ti948.c
>> index 86daa3701b91..b5c766711c4b 100644
>> --- a/drivers/gpu/drm/bridge/ti948.c
>> +++ b/drivers/gpu/drm/bridge/ti948.c
>> @@ -132,6 +132,8 @@ struct ti948_reg_val {
>> * @reg_names: Array of regulator names, or NULL.
>> * @regs: Array of regulators, or NULL.
>> * @reg_count: Number of entries in reg_names and regs arrays.
>> + * @alive_check: Context for the alive checking work item.
>> + * @alive: Whether the device is alive or not (alive_check).
>> */
>> struct ti948_ctx {
>> struct i2c_client *i2c;
>> @@ -141,6 +143,8 @@ struct ti948_ctx {
>> const char **reg_names;
>> struct regulator **regs;
>> size_t reg_count;
>> + struct delayed_work alive_check;
>> + bool alive;
>> };
>>
>> static bool ti948_readable_reg(struct device *dev, unsigned int reg)
>> @@ -346,6 +350,8 @@ static int ti948_power_on(struct ti948_ctx *ti948)
>> if (ret != 0)
>> return ret;
>>
>> + ti948->alive = true;
>> +
>> msleep(500);
>>
>> return 0;
>> @@ -356,6 +362,8 @@ static int ti948_power_off(struct ti948_ctx *ti948)
>> int i;
>> int ret;
>>
>> + ti948->alive = false;
>> +
>> for (i = ti948->reg_count; i > 0; i--) {
>> dev_info(&ti948->i2c->dev, "Disabling %s regulator\n",
>> ti948->reg_names[i - 1]);
>> @@ -388,8 +396,17 @@ static void ti948_alive_check(struct work_struct *work)
>> {
>> struct delayed_work *dwork = to_delayed_work(work);
>> struct ti948_ctx *ti948 = delayed_work_to_ti948_ctx(dwork);
>> + int ret = ti948_device_check(ti948);
>>
>> - dev_info(&ti948->i2c->dev, "%s Alive check!\n", __func__);
>> + if (ti948->alive == false && ret == 0) {
>> + dev_info(&ti948->i2c->dev, "Device has come back to life!\n");
>> + ti948_write_config_seq(ti948);
>> + ti948->alive = true;
>> +
>> + } else if (ti948->alive == true && ret != 0) {
>> + dev_info(&ti948->i2c->dev, "Device has stopped responding\n");
>> + ti948->alive = false;
>> + }
>>
>> /* Reschedule ourself for the next check. */
>> schedule_delayed_work(&ti948->alive_check, TI948_ALIVE_CHECK_DELAY);
>
--
Michael Drake https://www.codethink.co.uk/
^ permalink raw reply
* Re: [PATCH v1 03/11] dt-bindings: display/bridge: Add config property for ti948
From: Michael Drake @ 2019-07-12 12:43 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Andrzej Hajda, dri-devel, devicetree, linux-kernel, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, linux-kernel,
Patrick Glaser, Nate Case
In-Reply-To: <20190611180710.GT5016@pendragon.ideasonboard.com>
Hi Laurent,
On 11/06/2019 19:07, Laurent Pinchart wrote:
> Hi Michael,
>
> Thank you for the patch.
My pleasure, and thank you for the feedback!
> On Tue, Jun 11, 2019 at 03:04:04PM +0100, Michael Drake wrote:
>> The config property can be used to provide an array of
>> register addresses and values to be written to configure
>> the device for the board.
>
> Please don't. DT describes the hardware (or more accurately the system),
> it's not meant to store arbitrary configuration data. All the registers
> specified below should instead be set by the driver based on a
> combination of hardware description and information obtained at runtime.
OK, understood. I'll work on this. For some of them
explicit firmware properties would be appropriate.
I'll go through it to ascertain what can be determined
at runtime.
>> Signed-off-by: Michael Drake <michael.drake@codethink.co.uk>
>> Cc: Patrick Glaser <pglaser@tesla.com>
>> Cc: Nate Case <ncase@tesla.com>
>> ---
>> .../bindings/display/bridge/ti,ds90ub948.txt | 21 +++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90ub948.txt b/Documentation/devicetree/bindings/display/bridge/ti,ds90ub948.txt
>> index f9e86cb22900..1e7033b0f3b7 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/ti,ds90ub948.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90ub948.txt
>> @@ -12,6 +12,8 @@ Required properties:
>> Optional properties:
>>
>> - regulators: List of regulator name strings to enable for operation of device.
>> +- config: List of <register address>,<value> pairs to be set to configure
>> + device on powerup. The register addresses and values are 8bit.
>>
>> Example
>> -------
>> @@ -21,4 +23,23 @@ ti948: ds90ub948@0 {
>>
>> regulators: "vcc",
>> "vcc_disp";
>> + config:
>> + /* set error count to max */
>> + <0x41>, <0x1f>,
>> + /* sets output mode, no change noticed */
>> + <0x49>, <0xe0>,
>> + /* speed up I2C, 0xE is around 480KHz */
>> + <0x26>, <0x0e>,
>> + /* speed up I2C, 0xE is around 480KHz */
>> + <0x27>, <0x0e>,
>> + /* sets GPIO0 as an input */
>> + <0x1D>, <0x13>,
>> + /* set GPIO2 high, backlight PWM (set to 0x50 for normal use) */
>> + <0x1E>, <0x50>,
>> + /* sets GPIO3 as an output with remote control for touch XRES */
>> + <0x1F>, <0x05>,
>> + /* set GPIO5 high, backlight enable on new display */
>> + <0x20>, <0x09>,
>> + /* set GPIO7 and GPIO8 high to enable touch power and prox sense */
>> + <0x21>, <0x91>;
>> };
>
--
Michael Drake https://www.codethink.co.uk/
^ 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