* Re: [PATCH 1/3] arm64: defconfig: Enable Qualcomm GENI based I2C controller
From: Bjorn Andersson @ 2019-09-03 3:21 UTC (permalink / raw)
To: Lee Jones
Cc: arnd, catalin.marinas, linux-kernel, olof, will, linux-arm-kernel
In-Reply-To: <20190902130724.12030-1-lee.jones@linaro.org>
On Mon 02 Sep 06:07 PDT 2019, Lee Jones wrote:
> Tested on the Lenovo Yoga C630 where this patch enables the
> keyboard, touchpad and touchscreen.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index facf19cc275d..0fe943ac53b5 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -366,6 +366,7 @@ CONFIG_I2C_IMX_LPI2C=y
> CONFIG_I2C_MESON=y
> CONFIG_I2C_MV64XXX=y
> CONFIG_I2C_PXA=y
> +CONFIG_I2C_QCOM_GENI=m
> CONFIG_I2C_QUP=y
> CONFIG_I2C_RK3X=y
> CONFIG_I2C_SH_MOBILE=y
> --
> 2.17.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support
From: Anson Huang @ 2019-09-03 3:11 UTC (permalink / raw)
To: Fabio Estevam
Cc: Mark Rutland, Ulf Hansson, Jacky Bai, Catalin Marinas, Peng Fan,
Stefan Agner, Bjorn Andersson, Leonard Crestez, will@kernel.org,
yuehaibing@huawei.com, marcin.juszkiewicz@linaro.org, Jagan Teki,
linux-input@vger.kernel.org, ronald@innovation.ch, dl-linux-imx,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, Sascha Hauer, mripard@kernel.org, Marco Felsch,
Rob Herring, Thomas Gleixner, Andy Shevchenko, Daniel Baluta,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Aisheng Dong, Andy Duan, Greg Kroah-Hartman, Dmitry Torokhov,
linux-kernel, Dinh Nguyen, Sascha Hauer, Olof Johansson,
Shawn Guo
In-Reply-To: <CAOMZO5CHmvrbVG_h8hOb7hMjXasV_QwtNoXpEw9kqY=4Jj5HAg@mail.gmail.com>
Hi, Fabio
> On Mon, Sep 2, 2019 at 11:05 PM Anson Huang <Anson.Huang@nxp.com>
> wrote:
>
> > + ret = input_register_device(input);
> > + if (ret < 0) {
> > + dev_err(&pdev->dev, "failed to register input device\n");
> > + return ret;
> > + }
> > +
> > + pdata->input = input;
> > + platform_set_drvdata(pdev, pdata);
> > +
> > + ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE,
> SC_IRQ_BUTTON, true);
> > + if (ret) {
> > + dev_warn(&pdev->dev, "enable scu group irq failed\n");
> > + return ret;
>
> Better do a 'goto input_unregister' here instead and call
> input_unregister_device().
Agreed, will fix in V3 later.
Thanks,
Anson.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v1] clk: core: support clocks that need to be enabled during re-parent
From: Weiyi Lu @ 2019-09-03 3:08 UTC (permalink / raw)
To: Stephen Boyd
Cc: James Liao, srv_heupstream, Biao Huang, linux-kernel, Fan Chen,
linux-mediatek, Matthias Brugger, linux-clk, linux-arm-kernel
In-Reply-To: <20190626035246.4591A20659@mail.kernel.org>
On Tue, 2019-06-25 at 20:52 -0700, Stephen Boyd wrote:
> Quoting Weiyi Lu (2019-06-25 18:05:22)
> > On Tue, 2019-06-25 at 15:14 -0700, Stephen Boyd wrote:
> > > Quoting Weiyi Lu (2019-06-09 20:44:53)
> > > > When using property assigned-clock-parents to assign parent clocks,
> > > > core clocks might still be disabled during re-parent.
> > > > Add flag 'CLK_OPS_CORE_ENABLE' for those clocks must be enabled
> > > > during re-parent.
> > > >
> > > > Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
> > >
> > > Can you further describe the scenario where this is a problem? Is it
> > > some sort of clk that is enabled by default out of the bootloader and is
> > > then configured to have an 'assigned-clock-parents' property to change
> > > the parent, but that clk needs to be "enabled" so that the framework
> > > turns on the parents for the parent switch?
> >
> > When driver is built as module(.ko) and install at runtime after the
> > whole initialization stage. Clk might already be turned off before
> > configuring by assigned-clock-parents. For such clock design that need
> > to have clock enabled during re-parent, the configuration of
> > assigned-clock-parents might be failed. That's the problem we have now.
>
> Great. Please put this sort of information in the commit text.
>
OK, I'll do when sending next version.
> > Do you have any suggestion for such usage of clocks? Many thanks.
> >
>
> Ok, and in this case somehow CLK_OPS_PARENT_ENABLE flag doesn't work? Is
> that because the clk itself doesn't do anything unless it's enabled? I
> seem to recall that we usually work around this by caching the state of
> the clk parents or frequencies and then when the clk prepare or enable
> op is called we actually write the hardware to change the state. There
> are some qcom clks like this and we basically just use the hardware
> itself to cache the state of the clk while it hasn't actually changed to
> be at that rate, because the clk is not enabled yet.
>
Hi Stephen,
Will you recommend if we cache the state in the platform driver instead
of the hardware itself and then change the state when clk enable op is
called if we don't have such hardware design on MTK clocks?
> The main concern is that we're having to turn on clks to make things
> work, when it would be best to not turn on clks just so that register
> writes actually make a difference to what the hardware does.
>
In my view, it's a safe operation to enable clock shortly to make things
work when its child clock is still disabled. What do you think?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] iommu/arm-smmu-v3: Fix build error without CONFIG_PCI_ATS
From: YueHaibing @ 2019-09-03 2:42 UTC (permalink / raw)
To: will, robin.murphy, joro
Cc: iommu, YueHaibing, linux-kernel, linux-arm-kernel
If CONFIG_PCI_ATS is not set, building fails:
drivers/iommu/arm-smmu-v3.c: In function arm_smmu_ats_supported:
drivers/iommu/arm-smmu-v3.c:2325:35: error: struct pci_dev has no member named ats_cap; did you mean msi_cap?
return !pdev->untrusted && pdev->ats_cap;
^~~~~~~
ats_cap should only used when CONFIG_PCI_ATS is defined,
so use #ifdef block to guard this.
Fixes: bfff88ec1afe ("iommu/arm-smmu-v3: Rework enabling/disabling of ATS for PCI masters")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/iommu/arm-smmu-v3.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 66bf641..44ac9ac 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2313,7 +2313,7 @@ static void arm_smmu_install_ste_for_dev(struct arm_smmu_master *master)
static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
{
- struct pci_dev *pdev;
+ struct pci_dev *pdev __maybe_unused;
struct arm_smmu_device *smmu = master->smmu;
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(master->dev);
@@ -2321,8 +2321,10 @@ static bool arm_smmu_ats_supported(struct arm_smmu_master *master)
!(fwspec->flags & IOMMU_FWSPEC_PCI_RC_ATS) || pci_ats_disabled())
return false;
+#ifdef CONFIG_PCI_ATS
pdev = to_pci_dev(master->dev);
return !pdev->untrusted && pdev->ats_cap;
+#endif
}
static void arm_smmu_enable_ats(struct arm_smmu_master *master)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support
From: Fabio Estevam @ 2019-09-03 2:38 UTC (permalink / raw)
To: Anson Huang
Cc: Mark Rutland, Ulf Hansson, Ping Bai, Catalin Marinas, Peng Fan,
Stefan Agner, Bjorn Andersson, Leonard Crestez, will, yuehaibing,
marcin.juszkiewicz, Jagan Teki, linux-input, ronald,
NXP Linux Team,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Arnd Bergmann, Sascha Hauer, mripard, Marco Felsch, Rob Herring,
Thomas Gleixner, Andy Shevchenko, Daniel Baluta,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Dong Aisheng, Fugang Duan, Greg Kroah-Hartman, Dmitry Torokhov,
linux-kernel, Dinh Nguyen, Sascha Hauer, Olof Johansson,
Shawn Guo
In-Reply-To: <1567519424-32271-2-git-send-email-Anson.Huang@nxp.com>
Hi Anson,
On Mon, Sep 2, 2019 at 11:05 PM Anson Huang <Anson.Huang@nxp.com> wrote:
> + ret = input_register_device(input);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to register input device\n");
> + return ret;
> + }
> +
> + pdata->input = input;
> + platform_set_drvdata(pdev, pdata);
> +
> + ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, true);
> + if (ret) {
> + dev_warn(&pdev->dev, "enable scu group irq failed\n");
> + return ret;
Better do a 'goto input_unregister' here instead and call
input_unregister_device().
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 04/11] PCI: designware-ep: Modify MSI and MSIX CAP way of finding
From: Xiaowei Bao @ 2019-09-03 2:33 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <20190902150720.GO9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 23:07
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: Re: [PATCH v3 04/11] PCI: designware-ep: Modify MSI and MSIX CAP
> way of finding
>
> On Mon, Sep 02, 2019 at 11:17:09AM +0800, Xiaowei Bao wrote:
> > Each PF of EP device should have it's own MSI or MSIX capabitily
> > struct, so create a dw_pcie_ep_func struct and remover the msi_cap
>
> remover?
Sorry. ^_^
>
> > and msix_cap to this struce, and manage the PFs with a list.
>
> struce?
>
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v1:
> > - This is a new patch, to fix the issue of MSI and MSIX CAP way of
> > finding.
> > v2:
> > - No change.
> > v3:
> > - No change.
>
> This makes it look like you introduced the patch in v1 and haven't changed it
> since.
>
> I think it's more common to have a history like this:
>
> ---
> v3:
> - Introduced new patch, to fix the issue of MSI and MSIX CAP way of
> finding.
OK, thanks, I am not clear the rules, thanks a lot for your help.
Thanks
Xiaowei
>
>
> >
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 135
> +++++++++++++++++++++---
> > drivers/pci/controller/dwc/pcie-designware.h | 18 +++-
> > 2 files changed, 134 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index c3bc7bd..144eb12 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -19,6 +19,19 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > pci_epc_linkup(epc);
> > }
> >
> > +struct dw_pcie_ep_func *
> > +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no) {
> > + struct dw_pcie_ep_func *ep_func;
> > +
> > + list_for_each_entry(ep_func, &ep->func_list, list) {
> > + if (ep_func->func_no == func_no)
> > + return ep_func;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8
> > func_no) {
> > unsigned int func_offset = 0;
> > @@ -59,6 +72,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci,
> enum pci_barno bar)
> > __dw_pcie_ep_reset_bar(pci, func_no, bar, 0); }
> >
> > +static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8
> func_no,
> > + u8 cap_ptr, u8 cap)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
> > + u8 cap_id, next_cap_ptr;
> > + u16 reg;
> > +
> > + if (!cap_ptr)
> > + return 0;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
> > + cap_id = (reg & 0x00ff);
> > +
> > + if (cap_id > PCI_CAP_ID_MAX)
> > + return 0;
> > +
> > + if (cap_id == cap)
> > + return cap_ptr;
> > +
> > + next_cap_ptr = (reg & 0xff00) >> 8;
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
>
> Which tree have you based this patchset on? v5.3-rc3 and pci/dwc both
> already have this function (without the func_no). See beb4641a787d
> ("PCI: dwc: Add MSI-X callbacks handler").
There is a commit 7a6854f68 in the latest kernel.
Thanks
Xiaowei
>
> > +
> > +static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8
> > +func_no, u8 cap) {
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
> > + u8 next_cap_ptr;
> > + u16 reg;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
> > + next_cap_ptr = (reg & 0x00ff);
> > +
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
> > +
> > static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> > struct pci_epf_header *hdr)
> > {
> > @@ -246,13 +300,18 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> *epc, u8 func_no)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > unsigned int func_offset = 0;
> > + struct dw_pcie_ep_func *ep_func;
> >
> > - if (!ep->msi_cap)
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > + if (!ep_func)
> > + return -EINVAL;
> > +
> > + if (!ep_func->msi_cap)
> > return -EINVAL;
> >
> > func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > - reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > + reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
> > val = dw_pcie_readw_dbi(pci, reg);
> > if (!(val & PCI_MSI_FLAGS_ENABLE))
> > return -EINVAL;
> > @@ -268,13 +327,18 @@ static int dw_pcie_ep_set_msi(struct pci_epc
> *epc, u8 func_no, u8 interrupts)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > unsigned int func_offset = 0;
> > + struct dw_pcie_ep_func *ep_func;
> > +
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > + if (!ep_func)
> > + return -EINVAL;
> >
> > - if (!ep->msi_cap)
> > + if (!ep_func->msi_cap)
> > return -EINVAL;
> >
> > func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > - reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > + reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
> > val = dw_pcie_readw_dbi(pci, reg);
> > val &= ~PCI_MSI_FLAGS_QMASK;
> > val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK; @@ -291,13 +355,18
> > @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > unsigned int func_offset = 0;
> > + struct dw_pcie_ep_func *ep_func;
> > +
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > + if (!ep_func)
> > + return -EINVAL;
> >
> > - if (!ep->msix_cap)
> > + if (!ep_func->msix_cap)
> > return -EINVAL;
> >
> > func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > - reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> > + reg = ep_func->msix_cap + func_offset + PCI_MSIX_FLAGS;
> > val = dw_pcie_readw_dbi(pci, reg);
> > if (!(val & PCI_MSIX_FLAGS_ENABLE))
> > return -EINVAL;
> > @@ -313,13 +382,18 @@ static int dw_pcie_ep_set_msix(struct pci_epc
> *epc, u8 func_no, u16 interrupts)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > unsigned int func_offset = 0;
> > + struct dw_pcie_ep_func *ep_func;
> >
> > - if (!ep->msix_cap)
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > + if (!ep_func)
> > + return -EINVAL;
> > +
> > + if (!ep_func->msix_cap)
> > return -EINVAL;
> >
> > func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > - reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> > + reg = ep_func->msix_cap + func_offset + PCI_MSIX_FLAGS;
> > val = dw_pcie_readw_dbi(pci, reg);
> > val &= ~PCI_MSIX_FLAGS_QSIZE;
> > val |= interrupts;
> > @@ -404,6 +478,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep
> *ep, u8 func_no,
> > u8 interrupt_num)
> > {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct dw_pcie_ep_func *ep_func;
> > struct pci_epc *epc = ep->epc;
> > unsigned int aligned_offset;
> > unsigned int func_offset = 0;
> > @@ -413,25 +488,29 @@ int dw_pcie_ep_raise_msi_irq(struct
> dw_pcie_ep *ep, u8 func_no,
> > bool has_upper;
> > int ret;
> >
> > - if (!ep->msi_cap)
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > + if (!ep_func)
> > + return -EINVAL;
> > +
> > + if (!ep_func->msi_cap)
> > return -EINVAL;
> >
> > func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > - reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > + reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
> > msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> > has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > - reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> > + reg = ep_func->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> > msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> > if (has_upper) {
> > - reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> > + reg = ep_func->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> > msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> > - reg = ep->msi_cap + func_offset + PCI_MSI_DATA_64;
> > + reg = ep_func->msi_cap + func_offset + PCI_MSI_DATA_64;
> > msg_data = dw_pcie_readw_dbi(pci, reg);
> > } else {
> > msg_addr_upper = 0;
> > - reg = ep->msi_cap + func_offset + PCI_MSI_DATA_32;
> > + reg = ep_func->msi_cap + func_offset + PCI_MSI_DATA_32;
> > msg_data = dw_pcie_readw_dbi(pci, reg);
> > }
> > aligned_offset = msg_addr_lower & (epc->mem->page_size - 1); @@
> > -467,6 +546,7 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep,
> u8 func_no,
> > u16 interrupt_num)
> > {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct dw_pcie_ep_func *ep_func;
> > struct pci_epc *epc = ep->epc;
> > u16 tbl_offset, bir;
> > unsigned int func_offset = 0;
> > @@ -477,9 +557,16 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep
> *ep, u8 func_no,
> > void __iomem *msix_tbl;
> > int ret;
> >
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > + if (!ep_func)
> > + return -EINVAL;
> > +
> > + if (!ep_func->msix_cap)
> > + return -EINVAL;
> > +
> > func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > - reg = ep->msix_cap + func_offset + PCI_MSIX_TABLE;
> > + reg = ep_func->msix_cap + func_offset + PCI_MSIX_TABLE;
> > tbl_offset = dw_pcie_readl_dbi(pci, reg);
> > bir = (tbl_offset & PCI_MSIX_TABLE_BIR);
> > tbl_offset &= PCI_MSIX_TABLE_OFFSET; @@ -558,6 +645,7 @@ int
> > dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > int i;
> > int ret;
> > u32 reg;
> > + u8 func_no;
> > void *addr;
> > unsigned int nbars;
> > unsigned int offset;
> > @@ -565,6 +653,9 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct device *dev = pci->dev;
> > struct device_node *np = dev->of_node;
> > + struct dw_pcie_ep_func *ep_func;
> > +
> > + INIT_LIST_HEAD(&ep->func_list);
> >
> > if (!pci->dbi_base || !pci->dbi_base2) {
> > dev_err(dev, "dbi_base/dbi_base2 is not populated\n"); @@ -624,9
> > +715,19 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > if (ret < 0)
> > epc->max_functions = 1;
> >
> > - ep->msi_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> > + for (func_no = 0; func_no < epc->max_functions; func_no++) {
> > + ep_func = devm_kzalloc(dev, sizeof(*ep_func), GFP_KERNEL);
> > + if (!ep_func)
> > + return -ENOMEM;
> >
> > - ep->msix_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSIX);
> > + ep_func->func_no = func_no;
> > + ep_func->msi_cap = dw_pcie_ep_find_capability(ep, func_no,
> > + PCI_CAP_ID_MSI);
> > + ep_func->msix_cap = dw_pcie_ep_find_capability(ep, func_no,
> > + PCI_CAP_ID_MSIX);
> > +
> > + list_add_tail(&ep_func->list, &ep->func_list);
> > + }
>
> Whilst your patch addresses the issue of giving each function the ability to
> have differing capabilities - I feel that this solution doesn't go deep enough.
>
> In my view the root issue here is that 'struct dw_pcie_ep' represents both a
> EP controller and a *single* EP function. I think that there should be a
> representation for an EP controller and a representation for a EP function (i.e.
> some separation). Thus allowing one EP controller to have many EP functions.
> This isn't too dissimilar to host bridges and their functions.
> Others here may have different views.
>
> It may be unlikely now, but EP functions belonging to the same bit of IP may
> have differing functionality - your approach addresses that for MSI/MSI
> capabilities, but what about other differences?
Sorry, I am not clear about the other differences is? are there have any defect?
>
> (It would be really nice as well if an EP controller could provide config
> read/write ops such that existing functions in the core such as
> __pci_find_next_capability could be reused - instead of copying them like
> dw_pcie_ep_find_capability. However I don't think this is feasible.)
Yes, agree you viewpoint, but this is the best way that I can thought ^_^,
may be others can give the best solution.
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> >
> > if (ep->ops->ep_init)
> > ep->ops->ep_init(ep);
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index 56789be..a57743c 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -221,8 +221,16 @@ struct dw_pcie_ep_ops {
> > unsigned int (*func_conf_select)(struct dw_pcie_ep *ep, u8 func_no);
> > };
> >
> > +struct dw_pcie_ep_func {
> > + struct list_head list;
> > + u8 func_no;
> > + u8 msi_cap; /* MSI capability offset */
> > + u8 msix_cap; /* MSI-X capability offset */
> > +};
> > +
> > struct dw_pcie_ep {
> > struct pci_epc *epc;
> > + struct list_head func_list;
> > const struct dw_pcie_ep_ops *ops;
> > phys_addr_t phys_base;
> > size_t addr_size;
> > @@ -235,8 +243,6 @@ struct dw_pcie_ep {
> > u32 num_ob_windows;
> > void __iomem *msi_mem;
> > phys_addr_t msi_mem_phys;
> > - u8 msi_cap; /* MSI capability offset */
> > - u8 msix_cap; /* MSI-X capability offset */
> > };
> >
> > struct dw_pcie_ops {
> > @@ -425,6 +431,8 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep
> > *ep, u8 func_no, int dw_pcie_ep_raise_msix_irq_doorbell(struct
> dw_pcie_ep *ep, u8 func_no,
> > u16 interrupt_num);
> > void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> > +struct dw_pcie_ep_func *
> > +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no);
> > #else
> > static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep) { @@
> > -466,5 +474,11 @@ static inline int
> > dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, static
> > inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
> > bar) { }
> > +
> > +struct dw_pcie_ep_func *
> > +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no) {
> > + return NULL;
> > +}
> > #endif
> > #endif /* _PCIE_DESIGNWARE_H */
> > --
> > 2.9.5
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 07/11] PCI: layerscape: Modify the way of getting capability with different PEX
From: Xiaowei Bao @ 2019-09-03 2:13 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <20190902133747.GN9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 21:38
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: Re: [PATCH v3 07/11] PCI: layerscape: Modify the way of getting
> capability with different PEX
>
> On Mon, Sep 02, 2019 at 11:17:12AM +0800, Xiaowei Bao wrote:
> > The different PCIe controller in one board may be have different
> > capability of MSI or MSIX, so change the way of getting the MSI
> > capability, make it more flexible.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
>
> Please see the comments I just made to Kishon's feedback in the thread for
> this patch in series v2.
I have reply the comments in series v2, expect Kishon's feedback.
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> > ---
> > v2:
> > - Remove the repeated assignment code.
> > v3:
> > - Use ep_func msi_cap and msix_cap to decide the msi_capable and
> > msix_capable of pci_epc_features struct.
> >
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 31
> > +++++++++++++++++++-------
> > 1 file changed, 23 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index a9c552e..1e07287 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -22,6 +22,7 @@
> >
> > struct ls_pcie_ep {
> > struct dw_pcie *pci;
> > + struct pci_epc_features *ls_epc;
> > };
> >
> > #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > @@ -40,26 +41,31 @@ static const struct of_device_id
> ls_pcie_ep_of_match[] = {
> > { },
> > };
> >
> > -static const struct pci_epc_features ls_pcie_epc_features = {
> > - .linkup_notifier = false,
> > - .msi_capable = true,
> > - .msix_capable = false,
> > - .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > -};
> > -
> > static const struct pci_epc_features* ls_pcie_ep_get_features(struct
> > dw_pcie_ep *ep) {
> > - return &ls_pcie_epc_features;
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > +
> > + return pcie->ls_epc;
> > }
> >
> > static void ls_pcie_ep_init(struct dw_pcie_ep *ep) {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > + struct dw_pcie_ep_func *ep_func;
> > enum pci_barno bar;
> >
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, 0);
> > + if (!ep_func)
> > + return;
> > +
> > for (bar = BAR_0; bar <= BAR_5; bar++)
> > dw_pcie_ep_reset_bar(pci, bar);
> > +
> > + pcie->ls_epc->msi_capable = ep_func->msi_cap ? true : false;
> > + pcie->ls_epc->msix_capable = ep_func->msix_cap ? true : false;
> > }
> >
> > static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no, @@
> > -119,6 +125,7 @@ static int __init ls_pcie_ep_probe(struct platform_device
> *pdev)
> > struct device *dev = &pdev->dev;
> > struct dw_pcie *pci;
> > struct ls_pcie_ep *pcie;
> > + struct pci_epc_features *ls_epc;
> > struct resource *dbi_base;
> > int ret;
> >
> > @@ -130,6 +137,10 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> > if (!pci)
> > return -ENOMEM;
> >
> > + ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
> > + if (!ls_epc)
> > + return -ENOMEM;
> > +
> > dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "regs");
> > pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > if (IS_ERR(pci->dbi_base))
> > @@ -140,6 +151,10 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> > pci->ops = &ls_pcie_ep_ops;
> > pcie->pci = pci;
> >
> > + ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > +
> > + pcie->ls_epc = ls_epc;
> > +
> > platform_set_drvdata(pdev, pcie);
> >
> > ret = ls_add_pcie_ep(pcie, pdev);
> > --
> > 2.9.5
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v2 06/10] PCI: layerscape: Modify the way of getting capability with different PEX
From: Xiaowei Bao @ 2019-09-03 2:11 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.co,
arnd@arndb.de, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org, gustavo.pimentel@synopsys.com,
jingoohan1@gmail.com, bhelgaas@google.com, Kishon Vijay Abraham I,
shawnguo@kernel.org, Mingkai Hu,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190902133637.GM9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 21:37
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>; bhelgaas@google.com;
> robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo Li
> <leoyang.li@nxp.com>; lorenzo.pieralisi@arm.co
> <lorenzo.pieralisi@arm.com>; arnd@arndb.de; gregkh@linuxfoundation.org;
> M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>;
> Roy Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of getting
> capability with different PEX
>
> On Fri, Aug 23, 2019 at 04:13:30AM +0000, Xiaowei Bao wrote:
> >
> >
> > > -----Original Message-----
> > > From: Kishon Vijay Abraham I <kishon@ti.com>
> > > Sent: 2019年8月23日 11:40
> > > To: Xiaowei Bao <xiaowei.bao@nxp.com>; bhelgaas@google.com;
> > > robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> > > robh+Li
> > > <leoyang.li@nxp.com>; lorenzo.pieralisi@arm.co
> > > <lorenzo.pieralisi@arm.com>; arnd@arndb.de;
> > > gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>;
> > > Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> > > jingoohan1@gmail.com; gustavo.pimentel@synopsys.com;
> > > linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > > linuxppc-dev@lists.ozlabs.org; andrew.murray@arm.com
> > > Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of
> > > getting capability with different PEX
> > >
> > > Hi,
> > >
> > > (Fixed Lorenzo's email address. All the patches in the series have
> > > wrong email
> > > id)
> > >
> > > On 23/08/19 8:09 AM, Xiaowei Bao wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Kishon Vijay Abraham I <kishon@ti.com>
> > > >> Sent: 2019年8月22日 19:44
> > > >> To: Xiaowei Bao <xiaowei.bao@nxp.com>; bhelgaas@google.com;
> > > >> robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org;
> > > >> robh+Leo
> > > Li
> > > >> <leoyang.li@nxp.com>; lorenzo.pieralisi@arm.co; arnd@arndb.de;
> > > >> gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>;
> > > >> Mingkai Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> > > >> jingoohan1@gmail.com; gustavo.pimentel@synopsys.com;
> > > >> linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> > > >> linux-kernel@vger.kernel.org;
> > > >> linux-arm-kernel@lists.infradead.org;
> > > >> linuxppc-dev@lists.ozlabs.org; andrew.murray@arm.com
> > > >> Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of
> > > >> getting capability with different PEX
> > > >>
> > > >> Hi,
> > > >>
> > > >> On 22/08/19 4:52 PM, Xiaowei Bao wrote:
> > > >>> The different PCIe controller in one board may be have different
> > > >>> capability of MSI or MSIX, so change the way of getting the MSI
> > > >>> capability, make it more flexible.
> > > >>
> > > >> please use different pci_epc_features table for different boards.
> > > > Thanks, I think that it will be more flexible to dynamically get
> > > > MSI or MSIX capability, Thus, we will not need to define the
> > > > pci_epc_feature for
> > > different boards.
> > >
> > > Is the restriction because you cannot have different compatible for
> > > different boards?
> > Sorry, I am not very clear what your mean, I think even if I use the
> > same compatible with different boards, each boards will enter the
> > probe function, in there I will get the MSI or MSIX PCIe capability of
> > the current controller in this board. Why do I need to define the
> pci_epc_feature for different boards?
>
> At present you determine how to set the [msi,msix]_capable flags of
> pci_epc_features based on reading the function capabilities at probe time.
> Instead of doing this, is it possible that you can determine the flags based on
> the compatible type alone? For example, is the MSI/MSIX capability the same
> for all fsl,ls2088a-pcie-ep devices?
>
> If it isn't *necessary* to probe for this information at probe time, then you
> could instead create a static pci_epc_features structure and assign it to
> something in your drvdata. This may provide some benefits.
>
> The dw_pcie_ep_get_features function would then look like:
>
> static const struct pci_epc_features*
> ls_pcie_ep_get_features(struct dw_pcie_ep *ep) {
> struct dw_pcie *pci = to_dw_pcie_from_pp(ep);
> struct ls_pcie_ep *pcie = dev_get_drvdata(pci->dev);
> return pcie->epc_features;
> }
>
> This also means you can revert "[v3,03/11] PCI: designware-ep: Move the".
>
> Is this what you had in mind Kishon?
Yes, I consider this scheme, but there is a issue with my board, e.g. my board have
three PCIE controllers, but only two controllers support MSI, I can't said that the
board support the MSI feature, so I only set the msi_capabitily by reading the MSI
capability struct the current PCIE controller, I am also very entangled in this issue.
so, do you have better advice? Thanks a lot.
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> > >
> > > Thanks
> > > Kishon
> > >
> > > >>
> > > >> Thanks
> > > >> Kishon
> > > >>>
> > > >>> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > >>> ---
> > > >>> v2:
> > > >>> - Remove the repeated assignment code.
> > > >>>
> > > >>> drivers/pci/controller/dwc/pci-layerscape-ep.c | 26
> > > >>> +++++++++++++++++++-------
> > > >>> 1 file changed, 19 insertions(+), 7 deletions(-)
> > > >>>
> > > >>> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> index 4e92a95..8461f62 100644
> > > >>> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > >>> @@ -22,6 +22,7 @@
> > > >>>
> > > >>> struct ls_pcie_ep {
> > > >>> struct dw_pcie *pci;
> > > >>> + struct pci_epc_features *ls_epc;
> > > >>> };
> > > >>>
> > > >>> #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > >>> @@ -40,25 +41,26 @@ static const struct of_device_id
> > > >> ls_pcie_ep_of_match[] = {
> > > >>> { },
> > > >>> };
> > > >>>
> > > >>> -static const struct pci_epc_features ls_pcie_epc_features = {
> > > >>> - .linkup_notifier = false,
> > > >>> - .msi_capable = true,
> > > >>> - .msix_capable = false,
> > > >>> -};
> > > >>> -
> > > >>> static const struct pci_epc_features*
> > > >>> ls_pcie_ep_get_features(struct dw_pcie_ep *ep) {
> > > >>> - return &ls_pcie_epc_features;
> > > >>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > >>> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > >>> +
> > > >>> + return pcie->ls_epc;
> > > >>> }
> > > >>>
> > > >>> static void ls_pcie_ep_init(struct dw_pcie_ep *ep) {
> > > >>> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > >>> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > >>> enum pci_barno bar;
> > > >>>
> > > >>> for (bar = BAR_0; bar <= BAR_5; bar++)
> > > >>> dw_pcie_ep_reset_bar(pci, bar);
> > > >>> +
> > > >>> + pcie->ls_epc->msi_capable = ep->msi_cap ? true : false;
> > > >>> + pcie->ls_epc->msix_capable = ep->msix_cap ? true : false;
> > > >>> }
> > > >>>
> > > >>> static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8
> > > >>> func_no, @@
> > > >>> -118,6 +120,7 @@ static int __init ls_pcie_ep_probe(struct
> > > >>> platform_device
> > > >> *pdev)
> > > >>> struct device *dev = &pdev->dev;
> > > >>> struct dw_pcie *pci;
> > > >>> struct ls_pcie_ep *pcie;
> > > >>> + struct pci_epc_features *ls_epc;
> > > >>> struct resource *dbi_base;
> > > >>> int ret;
> > > >>>
> > > >>> @@ -129,6 +132,10 @@ static int __init ls_pcie_ep_probe(struct
> > > >> platform_device *pdev)
> > > >>> if (!pci)
> > > >>> return -ENOMEM;
> > > >>>
> > > >>> + ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
> > > >>> + if (!ls_epc)
> > > >>> + return -ENOMEM;
> > > >>> +
> > > >>> dbi_base = platform_get_resource_byname(pdev,
> > > IORESOURCE_MEM,
> > > >> "regs");
> > > >>> pci->dbi_base = devm_pci_remap_cfg_resource(dev,
> dbi_base);
> > > >>> if (IS_ERR(pci->dbi_base))
> > > >>> @@ -139,6 +146,11 @@ static int __init ls_pcie_ep_probe(struct
> > > >> platform_device *pdev)
> > > >>> pci->ops = &ls_pcie_ep_ops;
> > > >>> pcie->pci = pci;
> > > >>>
> > > >>> + ls_epc->linkup_notifier = false,
> > > >>> + ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > > >>> +
> > > >>> + pcie->ls_epc = ls_epc;
> > > >>> +
> > > >>> platform_set_drvdata(pdev, pcie);
> > > >>>
> > > >>> ret = ls_add_pcie_ep(pcie, pdev);
> > > >>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* "Rework enabling/disabling of ATS for PCI masters" failed to compile on arm64
From: Qian Cai @ 2019-09-03 2:10 UTC (permalink / raw)
To: Will Deacon
Cc: iommu, Joerg Roedel, Robin Murphy, linux-kernel, linux-arm-kernel
The linux-next commit “iommu/arm-smmu-v3: Rework enabling/disabling of ATS for PCI masters” [1] causes a compilation error when PCI_ATS=n on arm64.
[1] https://lore.kernel.org/linux-iommu/20190820154549.17018-3-will@kernel.org/
drivers/iommu/arm-smmu-v3.c:2325:35: error: no member named 'ats_cap' in 'struct pci_dev'
return !pdev->untrusted && pdev->ats_cap;
~~~~ ^
For example,
Symbol: PCI_ATS [=n]
│ Type : bool
│ Defined at drivers/pci/Kconfig:118
│ Depends on: PCI [=y]
│ Selected by [n]:
│ - PCI_IOV [=n] && PCI [=y]
│ - PCI_PRI [=n] && PCI [=y]│
│ - PCI_PASID [=n] && PCI [=y] │
│ - AMD_IOMMU [=n] && IOMMU_SUPPORT [=y] && X86_64 && PCI [=y] && ACPI [=y]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Anson Huang @ 2019-09-03 2:05 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, ulf.hansson@linaro.org, Jacky Bai,
catalin.marinas@arm.com, Peng Fan, stefan@agner.ch,
bjorn.andersson@linaro.org, Leonard Crestez, will@kernel.org,
dinguyen@kernel.org, festevam@gmail.com,
marcin.juszkiewicz@linaro.org, jagan@amarulasolutions.com,
linux-input@vger.kernel.org, ronald@innovation.ch, dl-linux-imx,
devicetree@vger.kernel.org, arnd@arndb.de, s.hauer@pengutronix.de,
mripard@kernel.org, m.felsch@pengutronix.de, tglx@linutronix.de,
andriy.shevchenko@linux.intel.com, Daniel Baluta,
linux-arm-kernel@lists.infradead.org, Aisheng Dong, Andy Duan,
gregkh@linuxfoundation.org, dmitry.torokhov@gmail.com,
linux-kernel@vger.kernel.org, hsweeten@visionengravers.com,
kernel@pengutronix.de, olof@lixom.net, shawnguo@kernel.org
In-Reply-To: <20190902043521.GA14143@bogus>
Hi, Rob
> On Fri, Aug 30, 2019 at 04:53:45PM -0400, Anson Huang wrote:
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and power key event etc. management, Linux kernel has to communicate
> > with system controller via MU (message unit) IPC to get power key
> > event, add binding doc for i.MX system controller power key driver.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 18
> ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index c149fad..001d0b7 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -157,6 +157,17 @@ Required properties:
> > Optional properties:
> > - timeout-sec: contains the watchdog timeout in seconds.
> >
> > +Power key bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +Required properties:
> > +- compatible: should be:
> > + "fsl,imx8qxp-sc-pwrkey"
> > + followed by "fsl,imx-sc-pwrkey";
> > +- linux,keycodes: See
> > +Documentation/devicetree/bindings/input/keys.txt
> > +Optional Properties:
> > +- wakeup-source: See
> > +Documentation/devicetree/bindings/power/wakeup-source.txt
> > +
> > Example (imx8qxp):
> > -------------
> > aliases {
> > @@ -220,6 +231,13 @@ firmware {
> > compatible = "fsl,imx8qxp-sc-rtc";
> > };
> >
> > + scu_pwrkey: scu-pwrkey {
> > + compatible = "fsl,imx8qxp-sc-pwrkey", "fsl,imx-sc-
> pwrkey";
> > + linux,keycode = <KEY_POWER>;
> > + wakeup-source;
>
> wakeup-source implies an interrupt property.
After further check, I confirm this "wakeup-source" property is NOT needed for SCU general interrupt
wakeup, remove it in V2.
>
> > + status = "disabled";
>
> Don't should status in examples.
Removed it in V2, please help review, thanks.
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 4/5] arm64: dts: imx8qxp-mek: Enable scu power key
From: Anson Huang @ 2019-09-03 14:03 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
catalin.marinas, will, dmitry.torokhov, aisheng.dong, ulf.hansson,
fugang.duan, peng.fan, daniel.baluta, leonard.crestez, mripard,
olof, arnd, jagan, bjorn.andersson, dinguyen, marcin.juszkiewicz,
stefan, gregkh, andriy.shevchenko, yuehaibing, tglx, ronald,
m.felsch, ping.bai, devicetree, linux-kernel, linux-arm-kernel,
linux-input
Cc: Linux-imx
In-Reply-To: <1567519424-32271-1-git-send-email-Anson.Huang@nxp.com>
Enable scu power key for i.MX8QXP MEK board.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805..f3df5c4 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -234,3 +234,7 @@
&adma_dsp {
status = "okay";
};
+
+&scu_pwrkey {
+ status = "okay";
+};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V2 5/5] arm64: defconfig: Enable CONFIG_KEYBOARD_IMX_SC_PWRKEY as module
From: Anson Huang @ 2019-09-03 14:03 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
catalin.marinas, will, dmitry.torokhov, aisheng.dong, ulf.hansson,
fugang.duan, peng.fan, daniel.baluta, leonard.crestez, mripard,
olof, arnd, jagan, bjorn.andersson, dinguyen, marcin.juszkiewicz,
stefan, gregkh, andriy.shevchenko, yuehaibing, tglx, ronald,
m.felsch, ping.bai, devicetree, linux-kernel, linux-arm-kernel,
linux-input
Cc: Linux-imx
In-Reply-To: <1567519424-32271-1-git-send-email-Anson.Huang@nxp.com>
Select CONFIG_KEYBOARD_IMX_SC_PWRKEY as module by default to
support i.MX8QXP power key driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
No changes.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 49bb3d4..8178737 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -313,6 +313,7 @@ CONFIG_INPUT_EVDEV=y
CONFIG_KEYBOARD_ADC=m
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_SNVS_PWRKEY=m
+CONFIG_KEYBOARD_IMX_SC_PWRKEY=m
CONFIG_KEYBOARD_CROS_EC=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ATMEL_MXT=m
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V2 3/5] arm64: dts: imx8qxp: Add scu power key node
From: Anson Huang @ 2019-09-03 14:03 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
catalin.marinas, will, dmitry.torokhov, aisheng.dong, ulf.hansson,
fugang.duan, peng.fan, daniel.baluta, leonard.crestez, mripard,
olof, arnd, jagan, bjorn.andersson, dinguyen, marcin.juszkiewicz,
stefan, gregkh, andriy.shevchenko, yuehaibing, tglx, ronald,
m.felsch, ping.bai, devicetree, linux-kernel, linux-arm-kernel,
linux-input
Cc: Linux-imx
In-Reply-To: <1567519424-32271-1-git-send-email-Anson.Huang@nxp.com>
Add scu power key node for i.MX8QXP, disabled by default as it
depends on board design.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- remove "wakeup-source" property, as it is NOT needed for scu mu interrupt;
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 1133b41..85c5534 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -8,6 +8,7 @@
#include <dt-bindings/clock/imx8-clock.h>
#include <dt-bindings/firmware/imx/rsrc.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/pinctrl/pads-imx8qxp.h>
@@ -174,6 +175,12 @@
#power-domain-cells = <1>;
};
+ scu_pwrkey: scu-pwrkey {
+ compatible = "fsl,imx8qxp-sc-pwrkey", "fsl,imx-sc-pwrkey";
+ linux,keycode = <KEY_POWER>;
+ status = "disabled";
+ };
+
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support
From: Anson Huang @ 2019-09-03 14:03 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
catalin.marinas, will, dmitry.torokhov, aisheng.dong, ulf.hansson,
fugang.duan, peng.fan, daniel.baluta, leonard.crestez, mripard,
olof, arnd, jagan, bjorn.andersson, dinguyen, marcin.juszkiewicz,
stefan, gregkh, andriy.shevchenko, yuehaibing, tglx, ronald,
m.felsch, ping.bai, devicetree, linux-kernel, linux-arm-kernel,
linux-input
Cc: Linux-imx
In-Reply-To: <1567519424-32271-1-git-send-email-Anson.Huang@nxp.com>
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and power key etc..
Adds i.MX system controller power key driver support, Linux kernel
has to communicate with system controller via MU (message unit) IPC
to get power key's status.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- remove "wakeup-source" property operation, scu power key uses generic scu irq,
no need to have this property for device wakeup operation.
---
drivers/input/keyboard/Kconfig | 7 ++
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/imx_sc_pwrkey.c | 169 +++++++++++++++++++++++++++++++++
3 files changed, 177 insertions(+)
create mode 100644 drivers/input/keyboard/imx_sc_pwrkey.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 2e6d288..3aaeb9c 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -469,6 +469,13 @@ config KEYBOARD_IMX
To compile this driver as a module, choose M here: the
module will be called imx_keypad.
+config KEYBOARD_IMX_SC_PWRKEY
+ tristate "IMX SCU Power Key Driver"
+ depends on IMX_SCU
+ help
+ This is the system controller powerkey driver for NXP i.MX SoCs with
+ system controller inside.
+
config KEYBOARD_NEWTON
tristate "Newton keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 9510325..9ea5585 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
+obj-$(CONFIG_KEYBOARD_IMX_SC_PWRKEY) += imx_sc_pwrkey.o
obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
diff --git a/drivers/input/keyboard/imx_sc_pwrkey.c b/drivers/input/keyboard/imx_sc_pwrkey.c
new file mode 100644
index 0000000..53aa9a4
--- /dev/null
+++ b/drivers/input/keyboard/imx_sc_pwrkey.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/firmware/imx/sci.h>
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/jiffies.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+
+#define DEBOUNCE_TIME 100
+#define REPEAT_INTERVAL 60
+
+#define SC_IRQ_BUTTON 1
+#define SC_IRQ_GROUP_WAKE 3
+#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
+
+struct imx_pwrkey_drv_data {
+ int keycode;
+ bool keystate; /* 1: pressed, 0: release */
+ bool delay_check;
+ struct delayed_work check_work;
+ struct input_dev *input;
+};
+
+struct imx_sc_msg_pwrkey {
+ struct imx_sc_rpc_msg hdr;
+ u8 state;
+};
+static struct imx_pwrkey_drv_data *pdata;
+static struct imx_sc_ipc *pwrkey_ipc_handle;
+
+static int imx_sc_pwrkey_notify(struct notifier_block *nb,
+ unsigned long event, void *group)
+{
+ if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)
+ && !pdata->delay_check) {
+ pdata->delay_check = 1;
+ schedule_delayed_work(&pdata->check_work,
+ msecs_to_jiffies(REPEAT_INTERVAL));
+ }
+
+ return 0;
+}
+
+static void imx_sc_check_for_events(struct work_struct *work)
+{
+ struct input_dev *input = pdata->input;
+ struct imx_sc_msg_pwrkey msg;
+ struct imx_sc_rpc_msg *hdr = &msg.hdr;
+ bool state;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
+ hdr->size = 1;
+
+ /*
+ * Current SCU firmware does NOT have return value for
+ * this API, that means it is always successful.
+ */
+ imx_scu_call_rpc(pwrkey_ipc_handle, &msg, true);
+ state = msg.state;
+
+ if (!state && !pdata->keystate)
+ state = true;
+
+ if (state ^ pdata->keystate) {
+ pm_wakeup_event(input->dev.parent, 0);
+ pdata->keystate = !!state;
+ input_event(input, EV_KEY, pdata->keycode, !!state);
+ input_sync(input);
+ if (!state)
+ pdata->delay_check = 0;
+ pm_relax(pdata->input->dev.parent);
+ }
+
+ if (state)
+ schedule_delayed_work(&pdata->check_work,
+ msecs_to_jiffies(DEBOUNCE_TIME));
+}
+
+static struct notifier_block imx_sc_pwrkey_notifier = {
+ .notifier_call = imx_sc_pwrkey_notify,
+};
+
+static int imx_sc_pwrkey_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct input_dev *input;
+ int ret;
+
+ ret = imx_scu_get_handle(&pwrkey_ipc_handle);
+ if (ret)
+ return ret;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ if (of_property_read_u32(np, "linux,keycode", &pdata->keycode)) {
+ pdata->keycode = KEY_POWER;
+ dev_warn(&pdev->dev, "KEY_POWER without setting in dts\n");
+ }
+
+ INIT_DELAYED_WORK(&pdata->check_work, imx_sc_check_for_events);
+
+ input = devm_input_allocate_device(&pdev->dev);
+ if (!input) {
+ dev_err(&pdev->dev, "failed to allocate the input device\n");
+ return -ENOMEM;
+ }
+
+ input->name = pdev->name;
+ input->phys = "imx-sc-pwrkey/input0";
+ input->id.bustype = BUS_HOST;
+
+ input_set_capability(input, EV_KEY, pdata->keycode);
+
+ ret = input_register_device(input);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to register input device\n");
+ return ret;
+ }
+
+ pdata->input = input;
+ platform_set_drvdata(pdev, pdata);
+
+ ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, true);
+ if (ret) {
+ dev_warn(&pdev->dev, "enable scu group irq failed\n");
+ return ret;
+ }
+
+ ret = imx_scu_irq_register_notifier(&imx_sc_pwrkey_notifier);
+ if (ret) {
+ imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, false);
+ dev_warn(&pdev->dev, "register scu notifier failed\n");
+ }
+
+ return ret;
+}
+
+static const struct of_device_id imx_sc_pwrkey_ids[] = {
+ { .compatible = "fsl,imx-sc-pwrkey" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, imx_sc_pwrkey_ids);
+
+static struct platform_driver imx_sc_pwrkey_driver = {
+ .driver = {
+ .name = "imx-sc-pwrkey",
+ .of_match_table = imx_sc_pwrkey_ids,
+ },
+ .probe = imx_sc_pwrkey_probe,
+};
+module_platform_driver(imx_sc_pwrkey_driver);
+
+MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
+MODULE_DESCRIPTION("i.MX System Controller Power Key Driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Anson Huang @ 2019-09-03 14:03 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
catalin.marinas, will, dmitry.torokhov, aisheng.dong, ulf.hansson,
fugang.duan, peng.fan, daniel.baluta, leonard.crestez, mripard,
olof, arnd, jagan, bjorn.andersson, dinguyen, marcin.juszkiewicz,
stefan, gregkh, andriy.shevchenko, yuehaibing, tglx, ronald,
m.felsch, ping.bai, devicetree, linux-kernel, linux-arm-kernel,
linux-input
Cc: Linux-imx
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and power key event etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get power key event, add binding doc for i.MX system
controller power key driver.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- remove "wakeup-source" property, as it is NOT needed for SCU interrupt;
- remove "status" in example.
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index c149fad..f93e2e4 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -157,6 +157,15 @@ Required properties:
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
+Power key bindings based on SCU Message Protocol
+------------------------------------------------------------
+
+Required properties:
+- compatible: should be:
+ "fsl,imx8qxp-sc-pwrkey"
+ followed by "fsl,imx-sc-pwrkey";
+- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
+
Example (imx8qxp):
-------------
aliases {
@@ -220,6 +229,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-rtc";
};
+ scu_pwrkey: scu-pwrkey {
+ compatible = "fsl,imx8qxp-sc-pwrkey", "fsl,imx-sc-pwrkey";
+ linux,keycode = <KEY_POWER>;
+ };
+
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a
From: Xiaowei Bao @ 2019-09-03 2:01 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <20190902130628.GL9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 21:06
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: Re: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for
> ls1088a
>
> On Mon, Sep 02, 2019 at 11:17:15AM +0800, Xiaowei Bao wrote:
> > Add PCIe EP node for ls1088a to support EP mode.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - Remove the pf-offset proparty.
> > v3:
> > - No change.
> >
> > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> ++++++++++++++++++++++++++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > index c676d07..da246ab 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > @@ -483,6 +483,17 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep@3400000 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
>
> Here you specify a fallback "fsl,ls-pcie-ep" that is removed by this series.
>
> Besides that, this looks OK.
As explained, the "fsl,ls-pcie-ep" is needed, due to the u-boot will fixup the status
property base on this compatible, I think we reserve this compatible is helpfully,
if delate this compatible, I have to modify the code of bootloader.
Thanks
XIaowei
>
> Thanks,
>
> Andrew Murray
>
> > + reg = <0x00 0x03400000 0x0 0x00100000
> > + 0x20 0x00000000 0x8 0x00000000>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <24>;
> > + num-ob-windows = <128>;
> > + max-functions = /bits/ 8 <2>;
> > + status = "disabled";
> > + };
> > +
> > pcie@3500000 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x03500000 0x0 0x00100000 /* controller
> registers */
> > @@ -508,6 +519,16 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep@3500000 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > + reg = <0x00 0x03500000 0x0 0x00100000
> > + 0x28 0x00000000 0x8 0x00000000>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <6>;
> > + num-ob-windows = <8>;
> > + status = "disabled";
> > + };
> > +
> > pcie@3600000 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x03600000 0x0 0x00100000 /* controller
> registers */
> > @@ -533,6 +554,16 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep@3600000 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > + reg = <0x00 0x03600000 0x0 0x00100000
> > + 0x30 0x00000000 0x8 0x00000000>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <6>;
> > + num-ob-windows = <8>;
> > + status = "disabled";
> > + };
> > +
> > smmu: iommu@5000000 {
> > compatible = "arm,mmu-500";
> > reg = <0 0x5000000 0 0x800000>;
> > --
> > 2.9.5
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table
From: Xiaowei Bao @ 2019-09-03 1:52 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <20190902125454.GK9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 20:55
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: Re: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in
> pci_device_id table
>
> On Mon, Sep 02, 2019 at 11:17:16AM +0800, Xiaowei Bao wrote:
> > Add LS1088a in pci_device_id table so that pci-epf-test can be used
> > for testing PCIe EP in LS1088a.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - No change.
> > v3:
> > - No change.
> >
> > drivers/misc/pci_endpoint_test.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/misc/pci_endpoint_test.c
> > b/drivers/misc/pci_endpoint_test.c
> > index 6e208a0..d531951 100644
> > --- a/drivers/misc/pci_endpoint_test.c
> > +++ b/drivers/misc/pci_endpoint_test.c
> > @@ -793,6 +793,7 @@ static const struct pci_device_id
> pci_endpoint_test_tbl[] = {
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
> > { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
> > + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x80c0) },
>
> The Freescale PCI devices are the only devices in this table that don't have a
> define for their device ID. I think a define should be created for both of the
> device IDs above.
OK, but I only define in this file, I am not sure this can define in include/linux/pci_ids.h
file
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> > { PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
> > .driver_data = (kernel_ulong_t)&am654_data
> > --
> > 2.9.5
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-09-03 1:47 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <20190902124603.GJ9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 20:46
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
>
> On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> > Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > difference between LS1 and LS2 platform, so refactor the code of the
> > EP driver.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - This is a new patch for supporting the ls1088a and ls2088a platform.
> > v3:
> > - Adjust the some struct assignment order in probe function.
> >
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 72
> > +++++++++++++++++++-------
> > 1 file changed, 53 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index 5f0cb99..723bbe5 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -20,27 +20,29 @@
> >
> > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> >
> > -struct ls_pcie_ep {
> > - struct dw_pcie *pci;
> > - struct pci_epc_features *ls_epc;
> > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > +
> > +struct ls_pcie_ep_drvdata {
> > + u32 func_offset;
> > + const struct dw_pcie_ep_ops *ops;
> > + const struct dw_pcie_ops *dw_pcie_ops;
> > };
> >
> > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > +struct ls_pcie_ep {
> > + struct dw_pcie *pci;
> > + struct pci_epc_features *ls_epc;
> > + const struct ls_pcie_ep_drvdata *drvdata; };
> >
> > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > return 0;
> > }
> >
> > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > .start_link = ls_pcie_establish_link, };
> >
> > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > - { .compatible = "fsl,ls-pcie-ep",},
> > - { },
> > -};
> > -
> > static const struct pci_epc_features* ls_pcie_ep_get_features(struct
> > dw_pcie_ep *ep) { @@ -87,10 +89,39 @@ static int
> > ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > }
> > }
> >
> > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > + u8 func_no)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > +
> > + WARN_ON(func_no && !pcie->drvdata->func_offset);
> > + return pcie->drvdata->func_offset * func_no; }
> > +
> > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > .ep_init = ls_pcie_ep_init,
> > .raise_irq = ls_pcie_ep_raise_irq,
> > .get_features = ls_pcie_ep_get_features,
> > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > +
> > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > + .ops = &ls_pcie_ep_ops,
> > + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
> > +};
> > +
> > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > + .func_offset = 0x20000,
> > + .ops = &ls_pcie_ep_ops,
> > + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
> > +};
> > +
> > +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > + { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
> > + { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> > + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
> > + { },
>
> This removes support for "fsl,ls-pcie-ep" - was that intentional? If you do plan
> to drop it please make sure you explain why in the commit message. See also
> my comments in your dt-binding patch.
In fact, the u-boot will fixup the status property to 'status = enabled' in PCI node of
the DTS base on "fsl,ls-pcie-ep" compatible, so "fsl,ls-pcie-ep" is used, I used this
compatible before, because the driver only support the LS1046a, but this time, I add
the LS1088a and LS2088a support, and these two boards have some difference form
LS1046a, so I changed the compatible. I am not sure whether need to add "fsl,ls-pcie-ep"
in there, could you give some advice, thanks a lot.
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> > };
> >
> > static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@ -103,7
> > +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> > int ret;
> >
> > ep = &pci->ep;
> > - ep->ops = &pcie_ep_ops;
> > + ep->ops = pcie->drvdata->ops;
> >
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "addr_space");
> > if (!res)
> > @@ -142,20 +173,23 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> > if (!ls_epc)
> > return -ENOMEM;
> >
> > - dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "regs");
> > - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > - if (IS_ERR(pci->dbi_base))
> > - return PTR_ERR(pci->dbi_base);
> > + pcie->drvdata = of_device_get_match_data(dev);
> >
> > - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > pci->dev = dev;
> > - pci->ops = &ls_pcie_ep_ops;
> > - pcie->pci = pci;
> > + pci->ops = pcie->drvdata->dw_pcie_ops;
> >
> > ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> >
> > + pcie->pci = pci;
> > pcie->ls_epc = ls_epc;
> >
> > + dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "regs");
> > + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > + if (IS_ERR(pci->dbi_base))
> > + return PTR_ERR(pci->dbi_base);
> > +
> > + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > +
> > platform_set_drvdata(pdev, pcie);
> >
> > ret = ls_add_pcie_ep(pcie, pdev);
> > --
> > 2.9.5
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: mt8183: Add gce setting in display node
From: Bibby Hsieh @ 2019-09-03 1:39 UTC (permalink / raw)
To: David Airlie, Matthias Brugger, Daniel Vetter, dri-devel,
linux-mediatek
Cc: drinkcat, Bibby Hsieh, Yongqiang Niu, linux-kernel, tfiga, CK Hu,
Thierry Reding, Philipp Zabel, YT Shen, linux-arm-kernel
In order to use GCE function, we need add some informations
into display node (mboxes, mediatek,gce-client-reg, mediatek,gce-events).
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
index 5616d158a4fa..b7d294c1c5b4 100644
--- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
@@ -485,6 +485,11 @@
compatible = "mediatek,mt8183-display";
reg = <0 0x14000000 0 0x1000>;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
+ mboxes = <&gce 0 CMDQ_THR_PRIO_HIGHEST 1>,
+ <&gce 1 CMDQ_THR_PRIO_HIGHEST 1>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0 0x1000>;
+ mediatek,gce-events = <CMDQ_EVENT_MUTEX_STREAM_DONE0>,
+ <CMDQ_EVENT_MUTEX_STREAM_DONE1>;
};
ovl0: ovl@14008000 {
@@ -494,6 +499,7 @@
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_OVL0>;
mediatek,larb = <&larb0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x8000 0x1000>;
};
ovl_2l0: ovl@14009000 {
@@ -503,6 +509,7 @@
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_OVL0_2L>;
mediatek,larb = <&larb0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>;
};
ovl_2l1: ovl@1400a000 {
@@ -512,6 +519,7 @@
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_OVL1_2L>;
mediatek,larb = <&larb0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xa000 0x1000>;
};
rdma0: rdma@1400b000 {
@@ -522,6 +530,7 @@
clocks = <&mmsys CLK_MM_DISP_RDMA0>;
mediatek,larb = <&larb0>;
mediatek,rdma_fifo_size = <5>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xb000 0x1000>;
};
rdma1: rdma@1400c000 {
@@ -532,6 +541,7 @@
clocks = <&mmsys CLK_MM_DISP_RDMA1>;
mediatek,larb = <&larb0>;
mediatek,rdma_fifo_size = <2>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>;
};
color0: color@1400e000 {
@@ -541,6 +551,7 @@
interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_COLOR0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>;
};
ccorr0: ccorr@1400f000 {
@@ -549,6 +560,7 @@
interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_CCORR0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>;
};
aal0: aal@14010000 {
@@ -558,6 +570,7 @@
interrupts = <GIC_SPI 233 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_AAL0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0 0x1000>;
};
gamma0: gamma@14011000 {
@@ -567,6 +580,7 @@
interrupts = <GIC_SPI 234 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_GAMMA0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>;
};
dither0: dither@14012000 {
@@ -575,6 +589,7 @@
interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
clocks = <&mmsys CLK_MM_DISP_DITHER0>;
+ mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>;
};
mutex: mutex@14016000 {
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a
From: Xiaowei Bao @ 2019-09-03 1:33 UTC (permalink / raw)
To: Andrew Murray
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <20190902123140.GI9720@e119886-lin.cambridge.arm.com>
> -----Original Message-----
> From: Andrew Murray <andrew.murray@arm.com>
> Sent: 2019年9月2日 20:32
> To: Xiaowei Bao <xiaowei.bao@nxp.com>
> Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> <zhiqiang.hou@nxp.com>
> Subject: Re: [PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible
> strings for ls1088a and ls2088a
>
> On Mon, Sep 02, 2019 at 11:17:10AM +0800, Xiaowei Bao wrote:
> > Add compatible strings for ls1088a and ls2088a.
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > ---
> > v2:
> > - No change.
> > v3:
> > - Use one valid combination of compatible strings.
> >
> > Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index e20ceaa..762ae41 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -22,7 +22,9 @@ Required properties:
> > "fsl,ls1043a-pcie"
> > "fsl,ls1012a-pcie"
> > EP mode:
> > - "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
> > + "fsl,ls1046a-pcie-ep" "fsl,ls-pcie-ep"
> > + "fsl,ls1088a-pcie-ep" "fsl,ls-pcie-ep"
> > + "fsl,ls2088a-pcie-ep" "fsl,ls-pcie-ep"
>
> This isn't consistent with "[PATCH v3 09/11] PCI: layerscape: Add EP mode..."
> as that patch drops the fallback "fsl,ls-pcie-ep". Either the fallback must be
> preserved in the driver, or you need to drop it here.
>
> What if there are existing users that depend on the fallback?
>
> (I'm also not sure if that comma should have been dropped).
Hi Andrew,
Thanks for your comments, I lose the comma.
Thanks
Xiaowei
>
> Thanks,
>
> Andrew Murray
>
> > - reg: base addresses and lengths of the PCIe controller register blocks.
> > - interrupts: A list of interrupt outputs of the controller. Must contain an
> > entry for each entry in the interrupt-names property.
> > --
> > 2.9.5
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] arm64: dts: imx8mn-ddr4-evk: Enable GPIO LED
From: Anson Huang @ 2019-09-03 1:30 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
shawnguo@kernel.org, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, dl-linux-imx,
kernel@pengutronix.de, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190902203144.GA4787@bug>
Hi, Pavel
> On Mon 2019-09-02 16:45:38, Anson Huang wrote:
> > i.MX8MN DDR4 EVK board has a GPIO LED to indicate status, add support
> > for it.
>
> LED maintainers want to be on the cc list...
The get_maintainer.pl does NOT show the LED maintainers...But I have added it
in V2.
>
> > @@ -15,6 +15,18 @@
> > stdout-path = &uart2;
> > };
> >
> > + leds {
> > + compatible = "gpio-leds";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_gpio_led>;
> > +
> > + status {
> > + label = "status";
> > + gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
> > + default-state = "on";
> > + };
>
> And we should really standardize labels for user-controlled status LEDs.
> Mentioning color would be nice, for a start.
OK, I change the label to "yellow:status" in V2, please help review, thanks.
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2] arm64: dts: imx8mn-ddr4-evk: Enable GPIO LED
From: Anson Huang @ 2019-09-03 13:27 UTC (permalink / raw)
To: robh+dt, mark.rutland, shawnguo, s.hauer, kernel, festevam,
linux-leds, devicetree, linux-arm-kernel, linux-kernel
Cc: dmurphy, Linux-imx, pavel, jacek.anaszewski
i.MX8MN DDR4 EVK board has a GPIO LED to indicate status,
add support for it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Changes since V1:
- Mention color in the label.
---
arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index b698061..bf1c097 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -15,6 +15,18 @@
stdout-path = &uart2;
};
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_led>;
+
+ status {
+ label = "yellow:status";
+ gpios = <&gpio3 16 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+ };
+
reg_usdhc2_vmmc: regulator-usdhc2 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -54,6 +66,12 @@
>;
};
+ pinctrl_gpio_led: gpioledgrp {
+ fsl,pins = <
+ MX8MN_IOMUXC_NAND_READY_B_GPIO3_IO16 0x19
+ >;
+ };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MN_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH 1/7] iommu/arm-smmu: add Nvidia SMMUv2 implementation
From: Krishna Reddy @ 2019-09-03 1:07 UTC (permalink / raw)
To: Robin Murphy
Cc: Timo Alho, Thierry Reding, Mikko Perttunen,
linux-kernel@vger.kernel.org, joro@8bytes.org,
will.deacon@arm.com, iommu@lists.linux-foundation.org,
Pritesh Raithatha, Thomas Zeng (SW-TEGRA), Sachin Nikam,
linux-tegra@vger.kernel.org, Yu-Huan Hsu, Juha Tukkinen,
Alexander Van Brunt, linux-arm-kernel@lists.infradead.org
In-Reply-To: <3f2cbbe2-f6d7-07e3-3fef-18af518dedef@arm.com>
>>> +ARM_SMMU_MATCH_DATA(nvidia_smmuv2, ARM_SMMU_V2, NVIDIA_SMMUV2);
>> The ARM MMU-500 implementation is unmodified. It is the way the are integrated and used together(for interleaved accesses) is different from regular ARM MMU-500.
>> I have added it to get the model number and to be able differentiate the SMMU implementation in arm-smmu-impl.c.
>In that case, I would rather keep smmu->model representing the MMU-500 microarchitecture -
>since you'll still want to pick up errata workarounds etc. for that - and detect the Tegra integration via an explicit of_device_is_compatible()
> check in arm_smmu_impl_init().
Looks good to me.
>For comparison, under ACPI we'd probably have to detect integration details by looking at table headers, separately
> from the IORT "Model" field, so I'd prefer if the DT vs. ACPI handling didn't diverge more than necessary.
ACPI support for T194 can be added based on need in subsequent patches. For now, I am updating it for DT support.
-KR
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND v2 1/6] dt-bindings: watchdog: Add YAML schemas for the generic watchdog bindings
From: Guenter Roeck @ 2019-09-03 0:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, linux-watchdog, linux-kernel,
Chen-Yu Tsai, Rob Herring, wim, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190902114650.w65ya7mgfsyu275x@flea>
On 9/2/19 4:46 AM, Maxime Ripard wrote:
> Hi Guenther,
>
> On Fri, Aug 30, 2019 at 09:48:11AM -0700, Guenter Roeck wrote:
>> On Wed, Aug 21, 2019 at 04:38:30PM +0200, Maxime Ripard wrote:
>>> From: Maxime Ripard <maxime.ripard@bootlin.com>
>>>
>>> The watchdogs have a bunch of generic properties that are needed in a
>>> device tree. Add a YAML schemas for those.
>>>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>
>> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
> Thanks for reviewing this, which tree should this go through? Yours or Rob's?
>
I added the watchdog patches to my watchdog-next tree, where Wim
usually pick them up. I would be ok with Rob picking them up too
if he wants to.
Guenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] power: reset: make reboot-mode user selectable
From: Sebastian Reichel @ 2019-09-03 0:04 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartosz Golaszewski, Linux PM list, linux-kernel@vger.kernel.org,
Linux ARM, Nandor Han
In-Reply-To: <CAK8P3a3uNPepYweCN9+_cQNQyiSGdidwNGL0+xhti2vm8g9O_g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 604 bytes --]
Hi,
On Mon, Sep 02, 2019 at 11:16:27PM +0200, Arnd Bergmann wrote:
> On Mon, Sep 2, 2019 at 10:39 PM Sebastian Reichel <sre@kernel.org> wrote:
> > This patch does not look good to me. Better patch would be to
> > allow compiling CONFIG_REBOOT_MODE without CONFIG_OF. Obviously
> > the configuration would not be useful for anything except compile
> > testing, but that is also true for this patch.
>
> Ok, I'd suggest we leave it with the bugfix you already applied then.
> [caa2b55784, power: reset: nvmem-reboot-mode: add CONFIG_OF dependency]
That's also fine with me.
-- Sebastian
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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