* [PATCH 2/3] Documentation: DT: add LS1012A compatible for SCFG and DCFG
From: Rob Herring @ 2016-11-15 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478714679-12724-1-git-send-email-harninder.rai@nxp.com>
On Wed, Nov 09, 2016 at 11:34:39PM +0530, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai@nxp.com>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: socfpga: fix spelling mistake in error message
From: Dinh Nguyen @ 2016-11-14 23:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114230400.5352-1-colin.king@canonical.com>
On Mon, Nov 14, 2016 at 5:04 PM, Colin King <colin.king@canonical.com> wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake "Mananger" to "Manager"
> in error message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> arch/arm/mach-socfpga/l2_cache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Applied!
Thanks,
DInh
^ permalink raw reply
* [PATCH 1/3] Documentation: DT: Add entry for FSL LS1012A RDB, FRDM, QDS boards
From: Rob Herring @ 2016-11-14 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478714651-12679-1-git-send-email-harninder.rai@nxp.com>
On Wed, Nov 09, 2016 at 11:34:11PM +0530, Harninder Rai wrote:
> Signed-off-by: Harninder Rai <harninder.rai@nxp.com>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Auger Eric @ 2016-11-14 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f93ebfd-edf4-0b5a-b54a-b96937a588b8@arm.com>
Hi Robin,
On 14/11/2016 13:36, Robin Murphy wrote:
> On 04/11/16 11:24, Eric Auger wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. With the relevant infrastructure now in
>> place for managed DMA domains, it's actually really simple for other
>> users to piggyback off that and reap the benefits without giving up
>> their own IOVA management, and without having to reinvent their own
>> wheel in the MSI layer.
>>
>> Allow such users to opt into automatic MSI remapping by dedicating a
>> region of their IOVA space to a managed cookie.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> OK, following the discussion elsewhere I've had a go at the less stupid,
> but more involved, version. Thoughts?
Conceptually I don't have any major objection with the minimalist
allocation scheme all the more so it follows Joerg's guidance. Maybe the
only thing is we do not check we don't overshoot the reserved msi-region.
Besides there are 2 issues reported below.
>
> Robin.
>
> ----->8-----
> From: Robin Murphy <robin.murphy@arm.com>
> Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie, and extend the mapping
> routine to implement a trivial linear allocator in such cases, to avoid
> the needless overhead of a full-blown IOVA domain.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
> include/linux/dma-iommu.h | 6 +++
> 2 files changed, 100 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab8667e6f2..33d66a8273c6 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
> phys_addr_t phys;
> };
>
> +enum iommu_dma_cookie_type {
> + IOMMU_DMA_IOVA_COOKIE,
> + IOMMU_DMA_MSI_COOKIE,
> +};
> +
> struct iommu_dma_cookie {
> - struct iova_domain iovad;
> - struct list_head msi_page_list;
> - spinlock_t msi_lock;
> + union {
> + struct iova_domain iovad;
> + dma_addr_t msi_iova;
> + };
> + struct list_head msi_page_list;
> + spinlock_t msi_lock;
> + enum iommu_dma_cookie_type type;
> };
>
> static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
> @@ -53,6 +62,19 @@ int iommu_dma_init(void)
> return iova_cache_get();
> }
>
> +static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> + if (cookie) {
> + spin_lock_init(&cookie->msi_lock);
> + INIT_LIST_HEAD(&cookie->msi_page_list);
> + cookie->type = type;
> + }
> + return cookie;
> +}
> +
> /**
> * iommu_get_dma_cookie - Acquire DMA-API resources for a domain
> * @domain: IOMMU domain to prepare for DMA-API usage
> @@ -62,25 +84,53 @@ int iommu_dma_init(void)
> */
> int iommu_get_dma_cookie(struct iommu_domain *domain)
> {
> - struct iommu_dma_cookie *cookie;
> -
> if (domain->iova_cookie)
> return -EEXIST;
>
> - cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
> - if (!cookie)
> + domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
> + if (!domain->iova_cookie)
> return -ENOMEM;
>
> - spin_lock_init(&cookie->msi_lock);
> - INIT_LIST_HEAD(&cookie->msi_page_list);
> - domain->iova_cookie = cookie;
> return 0;
> }
> EXPORT_SYMBOL(iommu_get_dma_cookie);
>
> /**
> + * iommu_get_msi_cookie - Acquire just MSI remapping resources
> + * @domain: IOMMU domain to prepare
> + * @base: Start address of IOVA region for MSI mappings
> + *
> + * Users who manage their own IOVA allocation and do not want DMA API support,
> + * but would still like to take advantage of automatic MSI remapping, can use
> + * this to initialise their own domain appropriately. Users should reserve a
> + * contiguous IOVA region, starting at @base, large enough to accommodate the
> + * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
> + * used by the devices attached to @domain.
> + */
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + struct iommu_dma_cookie *cookie;
> +
> + if (domain->type != IOMMU_DOMAIN_UNMANAGED)
> + return -EINVAL;
> +
> + if (domain->iova_cookie)
> + return -EEXIST;
> +
> + cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
must be IOMMU_DMA_MSI_COOKIE else it has bad consequences.
> + if (!cookie)
> + return -ENOMEM;
> +
> + cookie->msi_iova = base;
> + domain->iova_cookie = cookie;
> + return 0;
> +}
> +EXPORT_SYMBOL(iommu_get_msi_cookie);
> +
> +/**
> * iommu_put_dma_cookie - Release a domain's DMA mapping resources
> - * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> + * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
> + * iommu_get_msi_cookie()
> *
> * IOMMU drivers should normally call this from their domain_free callback.
> */
> @@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
> if (!cookie)
> return;
>
> - if (cookie->iovad.granule)
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
> put_iova_domain(&cookie->iovad);
>
> list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
> @@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
> int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> u64 size, struct device *dev)
> {
> - struct iova_domain *iovad = cookie_iovad(domain);
> + struct iommu_dma_cookie *cookie = domain->iova_cookie;
> + struct iova_domain *iovad = &cookie->iovad;
> unsigned long order, base_pfn, end_pfn;
>
> - if (!iovad)
> - return -ENODEV;
> + if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
> + return -EINVAL;
>
> /* Use the smallest supported page size for IOVA granularity */
> order = __ffs(domain->pgsize_bitmap);
> @@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> {
> struct iommu_dma_cookie *cookie = domain->iova_cookie;
> struct iommu_dma_msi_page *msi_page;
> - struct iova_domain *iovad = &cookie->iovad;
> + struct iova_domain *iovad;
> struct iova *iova;
> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> + size_t size;
> +
> + if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
> + iovad = &cookie->iovad;
> + size = iovad->granule;
> + } else {
> + iovad = NULL;
> + size = PAGE_SIZE;
> + }
> +
> + msi_addr &= ~(phys_addr_t)(size - 1);
>
> - msi_addr &= ~(phys_addr_t)iova_mask(iovad);
> list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> if (msi_page->phys == msi_addr)
> return msi_page;
> @@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> if (!msi_page)
> return NULL;
>
> - iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
> - if (!iova)
> - goto out_free_page;
> -
> msi_page->phys = msi_addr;
> - msi_page->iova = iova_dma_addr(iovad, iova);
> - if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
> + if (iovad) {
> + iova = __alloc_iova(domain, size, dma_get_mask(dev));
> + if (!iova)
> + goto out_free_page;
> + msi_page->iova = iova_dma_addr(iovad, iova);
> + } else {
> + msi_page->iova = cookie->msi_iova;
> + cookie->msi_iova += size;
> + }
> +
> + if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
> goto out_free_iova;
>
> INIT_LIST_HEAD(&msi_page->list);
> @@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> return msi_page;
>
> out_free_iova:
> - __free_iova(iovad, iova);
> + if (iovad)
> + __free_iova(iovad, iova);
> + else
> + cookie->msi_iova -= size;
> out_free_page:
> kfree(msi_page);
> return NULL;
> @@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
> msg->address_lo += lower_32_bits(msi_page->iova);
> }
> }
in iommu_dma_map_msi_msg there is another issue at:
msg->address_lo &= iova_mask(&cookie->iovad);
iovad might not exist
Thanks
Eric
> +
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 32c589062bd9..d69932474576 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -27,6 +27,7 @@ int iommu_dma_init(void);
>
> /* Domain management interface for IOMMU drivers */
> int iommu_get_dma_cookie(struct iommu_domain *domain);
> +int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
> void iommu_put_dma_cookie(struct iommu_domain *domain);
>
> /* Setup call for arch DMA mapping code */
> @@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
> return -ENODEV;
> }
>
> +static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
> +{
> + return -ENODEV;
> +}
> +
> static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
> {
> }
>
^ permalink raw reply
* [PATCH 1/4] fpga mgr: Introduce FPGA capabilities
From: atull @ 2016-11-14 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHeX08ZxGceXvqkdNwsVHdOpczxx5fvFapLy74n1_4R-CA@mail.gmail.com>
On Mon, 14 Nov 2016, Moritz Fischer wrote:
Hi Moritz,
> Hi Alan,
>
> On Mon, Nov 14, 2016 at 6:06 AM, atull <atull@opensource.altera.com> wrote:
> > On Mon, 7 Nov 2016, Moritz Fischer wrote:
> >
> >> Add FPGA capabilities as a way to express the capabilities
> >> of a given FPGA manager.
> >>
> >> Removes code duplication by comparing the low-level driver's
> >> capabilities at the framework level rather than having each driver
> >> check for supported operations in the write_init() callback.
> >>
> >> This allows for extending with additional capabilities, similar
> >> to the the dmaengine framework's implementation.
> >>
> >> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> >> Cc: Alan Tull <atull@opensource.altera.com>
> >> Cc: Michal Simek <michal.simek@xilinx.com>
> >> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> >> Cc: linux-kernel at vger.kernel.org
> >> Cc: linux-arm-kernel at lists.infradead.org
> >> ---
> >>
> >> Changes from RFC:
> >> * in the RFC the caps weren't actually stored into the struct fpga_mgr
> >>
> >> Note:
> >>
> >> If people disagree on the typedef being a 'false positive' I can fix
> >> that in a future rev of the patchset.
> >>
> >> Thanks,
> >>
> >> Moritz
> >>
> >> ---
> >> drivers/fpga/fpga-mgr.c | 15 ++++++++++++++
> >> drivers/fpga/socfpga.c | 10 +++++-----
> >> drivers/fpga/zynq-fpga.c | 7 ++++++-
> >> include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
> >> 4 files changed, 71 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> >> index 953dc91..ed57c17 100644
> >> --- a/drivers/fpga/fpga-mgr.c
> >> +++ b/drivers/fpga/fpga-mgr.c
> >> @@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
> >> struct device *dev = &mgr->dev;
> >> int ret;
> >>
> >> + if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
> >> + !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
> >> + dev_err(dev, "Partial reconfiguration not supported\n");
> >> + return -ENOTSUPP;
> >> + }
> >> +
> >> + if (flags & FPGA_MGR_FULL_RECONFIG &&
> >> + !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
> >> + dev_err(dev, "Full reconfiguration not supported\n");
> >> + return -ENOTSUPP;
> >> + }
> >> +
> >
> > Could you move the checks to their own function like
> > 'fpga_mgr_check_caps()' or something? I really like it if we can keep
> > the functions short, like a screen or so where it's practicle to do
> > so and I could see the number of caps growing here.
>
> Absolutely. Great suggestion.
>
> > The only counter argument I could think of is if a cap affects the sequence
> > in this function. Hmmm...
>
> Oh you mean the cap being there affecting the sequence in *this* function?
> I'd suggest we address that when we run into a cap that requires this.
Yes, I agree.
Alan
>
> Cheers,
>
> Moritz
>
^ permalink raw reply
* [PATCH 2/2] ARM: davinci: PM: rework init: cleanup
From: Kevin Hilman @ 2016-11-14 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114230441.356-1-khilman@baylibre.com>
A follow-on cleanup renaming 'pdata' since it is no longer
platform_data.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/pm.c | 61 +++++++++++++++++++++++-----------------------
1 file changed, 30 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index fc6a5710b3fa..1f2ac36efe11 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -34,7 +34,6 @@
static void (*davinci_sram_suspend) (struct davinci_pm_config *);
static struct davinci_pm_config pm_config;
-static struct davinci_pm_config *pdata = &pm_config;
static void davinci_sram_push(void *dest, void *src, unsigned int size)
{
@@ -46,58 +45,58 @@ static void davinci_pm_suspend(void)
{
unsigned val;
- if (pdata->cpupll_reg_base != pdata->ddrpll_reg_base) {
+ if (pm_config.cpupll_reg_base != pm_config.ddrpll_reg_base) {
/* Switch CPU PLL to bypass mode */
- val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
+ val = __raw_readl(pm_config.cpupll_reg_base + PLLCTL);
val &= ~(PLLCTL_PLLENSRC | PLLCTL_PLLEN);
- __raw_writel(val, pdata->cpupll_reg_base + PLLCTL);
+ __raw_writel(val, pm_config.cpupll_reg_base + PLLCTL);
udelay(PLL_BYPASS_TIME);
/* Powerdown CPU PLL */
- val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
+ val = __raw_readl(pm_config.cpupll_reg_base + PLLCTL);
val |= PLLCTL_PLLPWRDN;
- __raw_writel(val, pdata->cpupll_reg_base + PLLCTL);
+ __raw_writel(val, pm_config.cpupll_reg_base + PLLCTL);
}
/* Configure sleep count in deep sleep register */
- val = __raw_readl(pdata->deepsleep_reg);
+ val = __raw_readl(pm_config.deepsleep_reg);
val &= ~DEEPSLEEP_SLEEPCOUNT_MASK,
- val |= pdata->sleepcount;
- __raw_writel(val, pdata->deepsleep_reg);
+ val |= pm_config.sleepcount;
+ __raw_writel(val, pm_config.deepsleep_reg);
/* System goes to sleep in this call */
- davinci_sram_suspend(pdata);
+ davinci_sram_suspend(&pm_config);
- if (pdata->cpupll_reg_base != pdata->ddrpll_reg_base) {
+ if (pm_config.cpupll_reg_base != pm_config.ddrpll_reg_base) {
/* put CPU PLL in reset */
- val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
+ val = __raw_readl(pm_config.cpupll_reg_base + PLLCTL);
val &= ~PLLCTL_PLLRST;
- __raw_writel(val, pdata->cpupll_reg_base + PLLCTL);
+ __raw_writel(val, pm_config.cpupll_reg_base + PLLCTL);
/* put CPU PLL in power down */
- val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
+ val = __raw_readl(pm_config.cpupll_reg_base + PLLCTL);
val &= ~PLLCTL_PLLPWRDN;
- __raw_writel(val, pdata->cpupll_reg_base + PLLCTL);
+ __raw_writel(val, pm_config.cpupll_reg_base + PLLCTL);
/* wait for CPU PLL reset */
udelay(PLL_RESET_TIME);
/* bring CPU PLL out of reset */
- val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
+ val = __raw_readl(pm_config.cpupll_reg_base + PLLCTL);
val |= PLLCTL_PLLRST;
- __raw_writel(val, pdata->cpupll_reg_base + PLLCTL);
+ __raw_writel(val, pm_config.cpupll_reg_base + PLLCTL);
/* Wait for CPU PLL to lock */
udelay(PLL_LOCK_TIME);
/* Remove CPU PLL from bypass mode */
- val = __raw_readl(pdata->cpupll_reg_base + PLLCTL);
+ val = __raw_readl(pm_config.cpupll_reg_base + PLLCTL);
val &= ~PLLCTL_PLLENSRC;
val |= PLLCTL_PLLEN;
- __raw_writel(val, pdata->cpupll_reg_base + PLLCTL);
+ __raw_writel(val, pm_config.cpupll_reg_base + PLLCTL);
}
}
@@ -130,23 +129,23 @@ int __init davinci_pm_init(void)
if (ret)
return ret;
- pdata->sleepcount = DEEPSLEEP_SLEEPCOUNT;
- pdata->ddr2_ctlr_base = da8xx_get_mem_ctlr();
- pdata->deepsleep_reg = DA8XX_SYSCFG1_VIRT(DA8XX_DEEPSLEEP_REG);
- pdata->ddrpsc_num = DA8XX_LPSC1_EMIF3C;
+ pm_config.sleepcount = DEEPSLEEP_SLEEPCOUNT;
+ pm_config.ddr2_ctlr_base = da8xx_get_mem_ctlr();
+ pm_config.deepsleep_reg = DA8XX_SYSCFG1_VIRT(DA8XX_DEEPSLEEP_REG);
+ pm_config.ddrpsc_num = DA8XX_LPSC1_EMIF3C;
- pdata->cpupll_reg_base = ioremap(DA8XX_PLL0_BASE, SZ_4K);
- if (!pdata->cpupll_reg_base)
+ pm_config.cpupll_reg_base = ioremap(DA8XX_PLL0_BASE, SZ_4K);
+ if (!pm_config.cpupll_reg_base)
return -ENOMEM;
- pdata->ddrpll_reg_base = ioremap(DA850_PLL1_BASE, SZ_4K);
- if (!pdata->ddrpll_reg_base) {
+ pm_config.ddrpll_reg_base = ioremap(DA850_PLL1_BASE, SZ_4K);
+ if (!pm_config.ddrpll_reg_base) {
ret = -ENOMEM;
goto no_ddrpll_mem;
}
- pdata->ddrpsc_reg_base = ioremap(DA8XX_PSC1_BASE, SZ_4K);
- if (!pdata->ddrpsc_reg_base) {
+ pm_config.ddrpsc_reg_base = ioremap(DA8XX_PSC1_BASE, SZ_4K);
+ if (!pm_config.ddrpsc_reg_base) {
ret = -ENOMEM;
goto no_ddrpsc_mem;
}
@@ -163,8 +162,8 @@ int __init davinci_pm_init(void)
suspend_set_ops(&davinci_pm_ops);
no_ddrpsc_mem:
- iounmap(pdata->ddrpll_reg_base);
+ iounmap(pm_config.ddrpll_reg_base);
no_ddrpll_mem:
- iounmap(pdata->cpupll_reg_base);
+ iounmap(pm_config.cpupll_reg_base);
return ret;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] ARM: davinci: PM: rework init, support DT platforms
From: Kevin Hilman @ 2016-11-14 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114230441.356-1-khilman@baylibre.com>
Remove fake platform device used for PM init. Move pdata values which
are common across all current platforms into pm.c.
Also add PM support for DT platforms (vi da8xx-dt.c)
Suggested-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 17 +-------
arch/arm/mach-davinci/board-mityomapl138.c | 16 +-------
arch/arm/mach-davinci/common.c | 1 -
arch/arm/mach-davinci/da850.c | 38 ------------------
arch/arm/mach-davinci/da8xx-dt.c | 1 +
arch/arm/mach-davinci/include/mach/da8xx.h | 1 -
arch/arm/mach-davinci/pm.c | 64 ++++++++++++++++++------------
7 files changed, 41 insertions(+), 97 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index 8e4539f69fdc..4e88723c23c7 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -196,18 +196,6 @@ static struct platform_device da850_evm_norflash_device = {
.resource = da850_evm_norflash_resource,
};
-static struct davinci_pm_config da850_pm_pdata = {
- .sleepcount = 128,
-};
-
-static struct platform_device da850_pm_device = {
- .name = "pm-davinci",
- .dev = {
- .platform_data = &da850_pm_pdata,
- },
- .id = -1,
-};
-
/* DA850/OMAP-L138 EVM includes a 512 MByte large-page NAND flash
* (128K blocks). It may be used instead of the (default) SPI flash
* to boot, using TI's tools to install the secondary boot loader
@@ -1453,10 +1441,7 @@ static __init void da850_evm_init(void)
if (ret)
pr_warn("%s: cpuidle registration failed: %d\n", __func__, ret);
- ret = da850_register_pm(&da850_pm_device);
- if (ret)
- pr_warn("%s: suspend registration failed: %d\n", __func__, ret);
-
+ davinci_pm_init();
da850_vpif_init();
ret = spi_register_board_info(da850evm_spi_info,
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c b/arch/arm/mach-davinci/board-mityomapl138.c
index bc4e63fa9808..9e7388ba413c 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++ b/arch/arm/mach-davinci/board-mityomapl138.c
@@ -498,18 +498,6 @@ static void __init mityomapl138_config_emac(void)
pr_warn("emac registration failed: %d\n", ret);
}
-static struct davinci_pm_config da850_pm_pdata = {
- .sleepcount = 128,
-};
-
-static struct platform_device da850_pm_device = {
- .name = "pm-davinci",
- .dev = {
- .platform_data = &da850_pm_pdata,
- },
- .id = -1,
-};
-
static void __init mityomapl138_init(void)
{
int ret;
@@ -555,9 +543,7 @@ static void __init mityomapl138_init(void)
if (ret)
pr_warn("cpuidle registration failed: %d\n", ret);
- ret = da850_register_pm(&da850_pm_device);
- if (ret)
- pr_warn("suspend registration failed: %d\n", ret);
+ davinci_pm_init();
}
#ifdef CONFIG_SERIAL_8250_CONSOLE
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 049025f6d531..9f9fbfa6da0d 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -118,6 +118,5 @@ void __init davinci_common_init(struct davinci_soc_info *soc_info)
void __init davinci_init_late(void)
{
davinci_cpufreq_init();
- davinci_pm_init();
davinci_clk_disable_unused();
}
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index ed3d0e9f72ac..28771923199f 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1172,44 +1172,6 @@ static int da850_round_armrate(struct clk *clk, unsigned long rate)
}
#endif
-int __init da850_register_pm(struct platform_device *pdev)
-{
- int ret;
- struct davinci_pm_config *pdata = pdev->dev.platform_data;
-
- ret = davinci_cfg_reg(DA850_RTC_ALARM);
- if (ret)
- return ret;
-
- pdata->ddr2_ctlr_base = da8xx_get_mem_ctlr();
- pdata->deepsleep_reg = DA8XX_SYSCFG1_VIRT(DA8XX_DEEPSLEEP_REG);
- pdata->ddrpsc_num = DA8XX_LPSC1_EMIF3C;
-
- pdata->cpupll_reg_base = ioremap(DA8XX_PLL0_BASE, SZ_4K);
- if (!pdata->cpupll_reg_base)
- return -ENOMEM;
-
- pdata->ddrpll_reg_base = ioremap(DA850_PLL1_BASE, SZ_4K);
- if (!pdata->ddrpll_reg_base) {
- ret = -ENOMEM;
- goto no_ddrpll_mem;
- }
-
- pdata->ddrpsc_reg_base = ioremap(DA8XX_PSC1_BASE, SZ_4K);
- if (!pdata->ddrpsc_reg_base) {
- ret = -ENOMEM;
- goto no_ddrpsc_mem;
- }
-
- return platform_device_register(pdev);
-
-no_ddrpsc_mem:
- iounmap(pdata->ddrpll_reg_base);
-no_ddrpll_mem:
- iounmap(pdata->cpupll_reg_base);
- return ret;
-}
-
/* VPIF resource, platform data */
static u64 da850_vpif_dma_mask = DMA_BIT_MASK(32);
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index c9f7e9274aa8..aed44dcdfd30 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -46,6 +46,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
static void __init da850_init_machine(void)
{
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
+ davinci_pm_init();
}
static const char *const da850_boards_compat[] __initconst = {
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index f9f9713aacdd..3d7a13789661 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -101,7 +101,6 @@ int da8xx_register_gpio(void *pdata);
int da850_register_cpufreq(char *async_clk);
int da8xx_register_cpuidle(void);
void __iomem *da8xx_get_mem_ctlr(void);
-int da850_register_pm(struct platform_device *pdev);
int da850_register_sata(unsigned long refclkpn);
int da850_register_vpif(void);
int da850_register_vpif_display
diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index 8929569b1f8a..fc6a5710b3fa 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -23,13 +23,18 @@
#include <mach/da8xx.h>
#include "sram.h"
#include <mach/pm.h>
+#include <mach/mux.h>
#include "clock.h"
+#include "psc.h"
+#define DA850_PLL1_BASE 0x01e1a000
#define DEEPSLEEP_SLEEPCOUNT_MASK 0xFFFF
+#define DEEPSLEEP_SLEEPCOUNT 128
static void (*davinci_sram_suspend) (struct davinci_pm_config *);
-static struct davinci_pm_config *pdata;
+static struct davinci_pm_config pm_config;
+static struct davinci_pm_config *pdata = &pm_config;
static void davinci_sram_push(void *dest, void *src, unsigned int size)
{
@@ -117,17 +122,38 @@ static const struct platform_suspend_ops davinci_pm_ops = {
.valid = suspend_valid_only_mem,
};
-static int __init davinci_pm_probe(struct platform_device *pdev)
+int __init davinci_pm_init(void)
{
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(&pdev->dev, "cannot get platform data\n");
- return -ENOENT;
+ int ret;
+
+ ret = davinci_cfg_reg(DA850_RTC_ALARM);
+ if (ret)
+ return ret;
+
+ pdata->sleepcount = DEEPSLEEP_SLEEPCOUNT;
+ pdata->ddr2_ctlr_base = da8xx_get_mem_ctlr();
+ pdata->deepsleep_reg = DA8XX_SYSCFG1_VIRT(DA8XX_DEEPSLEEP_REG);
+ pdata->ddrpsc_num = DA8XX_LPSC1_EMIF3C;
+
+ pdata->cpupll_reg_base = ioremap(DA8XX_PLL0_BASE, SZ_4K);
+ if (!pdata->cpupll_reg_base)
+ return -ENOMEM;
+
+ pdata->ddrpll_reg_base = ioremap(DA850_PLL1_BASE, SZ_4K);
+ if (!pdata->ddrpll_reg_base) {
+ ret = -ENOMEM;
+ goto no_ddrpll_mem;
+ }
+
+ pdata->ddrpsc_reg_base = ioremap(DA8XX_PSC1_BASE, SZ_4K);
+ if (!pdata->ddrpsc_reg_base) {
+ ret = -ENOMEM;
+ goto no_ddrpsc_mem;
}
davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
if (!davinci_sram_suspend) {
- dev_err(&pdev->dev, "cannot allocate SRAM memory\n");
+ pr_err("PM: cannot allocate SRAM memory\n");
return -ENOMEM;
}
@@ -136,23 +162,9 @@ static int __init davinci_pm_probe(struct platform_device *pdev)
suspend_set_ops(&davinci_pm_ops);
- return 0;
-}
-
-static int __exit davinci_pm_remove(struct platform_device *pdev)
-{
- sram_free(davinci_sram_suspend, davinci_cpu_suspend_sz);
- return 0;
-}
-
-static struct platform_driver davinci_pm_driver = {
- .driver = {
- .name = "pm-davinci",
- },
- .remove = __exit_p(davinci_pm_remove),
-};
-
-int __init davinci_pm_init(void)
-{
- return platform_driver_probe(&davinci_pm_driver, davinci_pm_probe);
+no_ddrpsc_mem:
+ iounmap(pdata->ddrpll_reg_base);
+no_ddrpll_mem:
+ iounmap(pdata->cpupll_reg_base);
+ return ret;
}
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM: davinci: cleanup and rework PM initializaion
From: Kevin Hilman @ 2016-11-14 23:04 UTC (permalink / raw)
To: linux-arm-kernel
This series removes the fake platform_device used to initialize PM on
legacy davinci platforms, and adds PM support for DT platforms.
Sekhar: the 2nd patch should probably be squashed into the first upon
approval, but was kept separated in order to make the functional
changes in the first patch more readable.
Tested with legacy boot on da850-evm, and DT boot on da850-lcdk. Used
RTC to wake from suspend-to-RAM: e.g. rtcwake -m mem -s 4 -d /dev/rtc0
Kevin Hilman (2):
ARM: davinci: PM: rework init, support DT platforms
ARM: davinci: PM: rework init: cleanup
arch/arm/mach-davinci/board-da850-evm.c | 17 +----
arch/arm/mach-davinci/board-mityomapl138.c | 16 +----
arch/arm/mach-davinci/common.c | 1 -
arch/arm/mach-davinci/da850.c | 38 ------------
arch/arm/mach-davinci/da8xx-dt.c | 1 +
arch/arm/mach-davinci/include/mach/da8xx.h | 1 -
arch/arm/mach-davinci/pm.c | 99 +++++++++++++++++-------------
7 files changed, 58 insertions(+), 115 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH fpga 5/9] fpga zynq: Remove priv->dev
From: Jason Gunthorpe @ 2016-11-14 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAtXAHe60QjyitDxkEzc9+Zr99mj0SeWFUOW0SOexGnBvuqGjw@mail.gmail.com>
On Mon, Nov 14, 2016 at 09:20:38AM -0800, Moritz Fischer wrote:
> this one could be independent of the other patches, this is cleanup and
> could be merged before the rest (that's still in discussion) if you pull it out.
As I said in the cover letter, several of the patches are just fixes
and can be applied, but they are all linked by patch context so are
presented as a series.
Lets get as many reviewed as possible and then I can repost them in a
different order if necessary.
The first 5 are all straigtfoward and should be no problem to get
ackd. We've talked about the sanity check patch enough, lets just go
ahead with it now.
Jason
^ permalink raw reply
* [PATCH] ARM: socfpga: fix spelling mistake in error message
From: Colin King @ 2016-11-14 23:04 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake "Mananger" to "Manager"
in error message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/arm/mach-socfpga/l2_cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/l2_cache.c b/arch/arm/mach-socfpga/l2_cache.c
index 4267c95f..bb359d7 100644
--- a/arch/arm/mach-socfpga/l2_cache.c
+++ b/arch/arm/mach-socfpga/l2_cache.c
@@ -74,7 +74,7 @@ void socfpga_init_arria10_l2_ecc(void)
}
if (!sys_manager_base_addr) {
- pr_err("System Mananger not mapped for L2 ECC\n");
+ pr_err("System Manager not mapped for L2 ECC\n");
goto exit;
}
/* Clear any pending IRQs */
--
2.10.2
^ permalink raw reply related
* [PATCH v2 0/6] mm: fix the "counter.sh" failure for libhugetlbfs
From: Andrew Morton @ 2016-11-14 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-1-git-send-email-shijie.huang@arm.com>
On Mon, 14 Nov 2016 15:07:33 +0800 Huang Shijie <shijie.huang@arm.com> wrote:
> (1) Background
> For the arm64, the hugetlb page size can be 32M (PMD + Contiguous bit).
> In the 4K page environment, the max page order is 10 (max_order - 1),
> so 32M page is the gigantic page.
>
> The arm64 MMU supports a Contiguous bit which is a hint that the TTE
> is one of a set of contiguous entries which can be cached in a single
> TLB entry. Please refer to the arm64v8 mannul :
> DDI0487A_f_armv8_arm.pdf (in page D4-1811)
>
> (2) The bug
> After I tested the libhugetlbfs, I found the test case "counter.sh"
> will fail with the gigantic page (32M page in arm64 board).
>
> This patch set adds support for gigantic surplus hugetlb pages,
> allowing the counter.sh unit test to pass.
I'm not really seeing a description of the actual bug. I don't know
what counter.sh is, there is no copy of counter.sh included in the
changelogs and there is no description of the kernel error which
counter.sh demonstrates.
So can you pleaser send to me a copy of counter.sh as well as a
suitable description of the kernel error which counter.sh triggers?
^ permalink raw reply
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-11-14 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108115129.f315ca5feefd22614859bbe3@free.fr>
On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens@csie.org> wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > >
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> >
> > That's weird, because regmap's regmap_field should make that much
> > easier.
>
> #define field_relaxed(addr, mask, val) \
> writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
I'm not sure what you mean here.
> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > >
> > > I better think that streaming should be simply stopped on suspend.
> >
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> >
> > (And real suspend isn't supported anyway)
>
> Is it time to remove this useless code?
Which useless code?
> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > >
> > > May I go this way?
> >
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
>
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.
For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).
It just works with debugfs.
> Also, is a register access trace really needed in this driver?
Yes.
> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.
This is only needed if you want to use caching, and caching is
optional.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/5cda6589/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: sun8i: sina33: Enable USB gadget
From: Maxime Ripard @ 2016-11-14 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104144439.4469-1-maxime.ripard@free-electrons.com>
On Fri, Nov 04, 2016 at 03:44:39PM +0100, Maxime Ripard wrote:
> The micro-USB on the SinA33 has a somewhat interesting design in the sense
> that it has a micro USB connector, but the VBUS is (supposed to be)
> controlled through an (unpopulated) jumper.
>
> Obviously, that doesn't work really well, and only the peripheral mode
> really works. Still enable it.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/9b9d417b/attachment-0001.sig>
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-14 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114201640.rr32iyjf5a53v33t@perseus.defre.kleine-koenig.org>
>
> + i2c at 7 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <7>;
> +
> + pcawan: gpio at 71 {
> + compatible = "nxp,pca9538";
> + reg = <0x71>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcawan_pins>;
> +
> + interrupt-parent = <&gpio1>;
> + interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> +
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> + };
>
> The interrupt-controller part doesn't seem to work though, at least
>
> + interrupt-parent = <&pcawan>;
> + interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
>
> in the phy node gives an error.
Interrupts don't seem to work very well with the nxp,pca9538. Which
is probably why it is disabled by default.
Andrew
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-14 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126185.15557.5@smtp.gmail.com>
Hello Tomas,
On Mon, Nov 14, 2016 at 01:23:05PM +0100, tomas.hlavacek at nic.cz wrote:
> On Sat, Nov 5, 2016 at 9:38 PM, Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> wrote:
> > This machine is an open hardware router by cz.nic driven by a
> > Marvell Armada 385.
> >
> > Signed-off-by: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> > ---
> >
> > Hello,
> >
> > the following components are working:
> >
> > - WAN port
> > - eMMC
>
> But I not not sure about DDR50 mode. At least with kernel 4.4, that we use
> in production, we had to limit to SDR50 to overcome I/O errors and
> communication instability, if I can remember it correctly. So it might need
> more testing with the current kernel.
I didn't test that extensively, but the eMMC serves my rootfs and I
didn't had any problems so far.
> > Still missing is support for the switch. Wireless fails to probe, didn't
> > debug this up to now. SFP is untested as is UART1.
>
> Actually SFP is connected to SGMII interface of eth1, which is routed
> through SERDES 5. The SGMII line is shared between the SFP and metallic PHY
> 88E1514. There is a autonomous high-speed switch connected to the SFPDET
> signal from SFP cage. It disconnects the metallic SFP and connects SGMII to
> SFP once the module is connected.
>
> The SFP is also connected to the I2C mux port 4 and to GPIO expander for
> reading/driving SFPDET, LOS, TXFLT, TXDIS signals:
>
> &i2c0 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins>;
> status = "okay";
> clock-frequency = <100000>;
>
> i2cmux at 70 {
> compatible = "nxp,pca9547";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x70>;
> status = "okay";
>
> ...
>
> i2c at 7 {
> /* SFP+ GPIO expander */
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <7>;
>
> sfpgpio: gpio at 71 {
> compatible = "nxp,pca9538";
> reg = <0x71>;
> interrupt-parent = <&gpio1>;
> interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> gpio-controller;
> #gpio-cells = <2>;
> };
I have authored a nearly identical snippet, mine looks as follows:
+ i2c at 7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ pcawan: gpio at 71 {
+ compatible = "nxp,pca9538";
+ reg = <0x71>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcawan_pins>;
+
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
The interrupt-controller part doesn't seem to work though, at least
+ interrupt-parent = <&pcawan>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
in the phy node gives an error.
> };
> };
> };
>
> We have our proprietary support hacked onto mvneta driver for disconnecting
> PHY on the fly. It is a bit nasty, so I suggest to ignore SFP in this DTS
> altogether and let's wait till "phylink based SFP module support" or
> something alike hits upstream, so we can base the SFP support on solid code;
> unless somebody has a better idea, of course.
>
> >
> >
> > diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > new file mode 100644
> > index 000000000000..d3cd8a4d713d
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> > @@ -0,0 +1,246 @@
> ...
> > +
> > + /* USB part of the eSATA/USB 2.0 port */
>
> This comment is perhaps some error inherited from my development DTS. We do
> not have any eSATA, perhaps PCIe/USB 2.0 slot.
oh right. I changed it for v3.
> >
> > + usb at 58000 {
> > + status = "okay";
> > + };
> > +
> > +
> > +ð0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ge0_rgmii_pins>;
> > + status = "okay";
> > + phy-mode = "rgmii-id";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > +};
> > +
> > +ð1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&ge1_rgmii_pins>;
> > + status = "okay";
> > + phy-mode = "rgmii-id";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > +};
> > +
>
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176 switch.
> The problem is that from what I have read so far the switch can not operate
> in DSA mode with two CPU ports. We currently operate the switch in "normal
> mode" with the eth0 and eth1 set to fixed-link 1000/full and with
> proprietary driver (derived from OpenWRT switch drivers). I would say that
> these records for eth0 and eth1 are therefore redundant, because it does
> nothing without the switch support and it would most likely change once we
> have DSA driver (using only eth0).
Right. They do nothing currently. In my local tree I have a
specification for the switch which allows to read the phy registers of
the lan ports, but communication isn't possible yet. For this AFAIK I
need at least one of these. I mailed a few iterations with Andrew here,
but no success so far. Also dropping one cpu port from the definition
didn't help.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/a783ea53/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: sun8i: reference-design-tablet: ldo_io1 is vcc-touchscreen
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-2-hdegoede@redhat.com>
On Sun, Nov 13, 2016 at 08:22:03PM +0100, Hans de Goede wrote:
> On some Q8 and other tablets ldo_io1 is used as vcc-touchscreen,
> config at as such in sun8i-reference-design-tablet.dtsi.
>
> Note that it will only be enabled when it us actually referenced by
> a foo-supply property in the touchscreen node, so for tablets which
> do not use ldo_io1 as vcc-touchscreen, it will be disabled.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4197396f/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun5i: Add touchscreen node to reference-design-tablet.dtsi
From: Maxime Ripard @ 2016-11-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113192203.7101-1-hdegoede@redhat.com>
Hi,
On Sun, Nov 13, 2016 at 08:22:02PM +0100, Hans de Goede wrote:
> Just like on sun8i all sun5i tablets use the same interrupt and power
> gpios for their touchscreens. I've checked all known a13 fex files and
> only the UTOO P66 uses a different gpio for the interrupt.
>
> Add a touchscreen node to sun5i-reference-design-tablet.dtsi, which
> fills in the necessary gpios to avoid duplication in the tablet dts files,
> just like we do in sun8i-reference-design-tablet.dtsi.
>
> This will make future patches adding touchscreen nodes to a13 tablets
> simpler.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 38 ++++++++--------------
> .../boot/dts/sun5i-reference-design-tablet.dtsi | 25 ++++++++++++++
> 2 files changed, 39 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> index a8b0bcc..3d7ff10 100644
> --- a/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> +++ b/arch/arm/boot/dts/sun5i-a13-utoo-p66.dts
> @@ -83,22 +83,6 @@
> allwinner,pins = "PG3";
> };
>
> -&i2c1 {
> - icn8318: touchscreen at 40 {
> - compatible = "chipone,icn8318";
> - reg = <0x40>;
> - interrupt-parent = <&pio>;
> - interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> - pinctrl-names = "default";
> - pinctrl-0 = <&ts_wake_pin_p66>;
> - wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> - touchscreen-size-x = <800>;
> - touchscreen-size-y = <480>;
> - touchscreen-inverted-x;
> - touchscreen-swapped-x-y;
> - };
> -};
> -
> &mmc2 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc2_pins_a>;
> @@ -121,20 +105,26 @@
> allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
> -
> - ts_wake_pin_p66: ts_wake_pin at 0 {
> - allwinner,pins = "PB3";
> - allwinner,function = "gpio_out";
> - allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> - allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> - };
> -
> };
>
> ®_usb0_vbus {
> gpio = <&pio 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
> };
>
> +&touchscreen {
> + compatible = "chipone,icn8318";
> + reg = <0x40>;
> + /* The P66 uses a different EINT then the reference design */
> + interrupts = <6 9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
> + /* The icn8318 binding expects wake-gpios instead of power-gpios */
> + wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + touchscreen-size-x = <800>;
> + touchscreen-size-y = <480>;
> + touchscreen-inverted-x;
> + touchscreen-swapped-x-y;
> + status = "okay";
> +};
> +
> &uart1 {
> /* The P66 uses the uart pins as gpios */
> status = "disabled";
> diff --git a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> index 20cc940..7af488a 100644
> --- a/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> +++ b/arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi
> @@ -41,6 +41,7 @@
> */
> #include "sunxi-reference-design-tablet.dtsi"
>
> +#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pwm/pwm.h>
>
> / {
> @@ -84,6 +85,23 @@
> };
>
> &i2c1 {
> + /*
> + * The gsl1680 is rated at 400KHz and it will not work reliable at
> + * 100KHz, this has been confirmed on multiple different q8 tablets.
> + * All other devices on this bus are also rated for 400KHz.
> + */
> + clock-frequency = <400000>;
> +
> + touchscreen: touchscreen {
> + interrupt-parent = <&pio>;
> + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING>; /* EINT11 (PG11) */
> + pinctrl-names = "default";
> + pinctrl-0 = <&ts_power_pin>;
> + power-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
> + /* Tablet dts must provide reg and compatible */
> + status = "disabled";
> + };
> +
> pcf8563: rtc at 51 {
> compatible = "nxp,pcf8563";
> reg = <0x51>;
> @@ -125,6 +143,13 @@
> allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
> };
>
> + ts_power_pin: ts_power_pin {
> + allwinner,pins = "PB3";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> +
For the next release, we'll switch to the generic pin mux properties
("pins" and "function"), and we actually implemented the fact that the
drive and pull properties are optional, so you can drop them both.
You'll need next + http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/467123.html
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/7e78a172/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sun8i: replace enable-sdio-wakeup with wakeup-source for BananaPi M1+
From: Maxime Ripard @ 2016-11-14 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479138250-17780-4-git-send-email-sudeep.holla@arm.com>
On Mon, Nov 14, 2016 at 03:44:10PM +0000, Sudeep Holla wrote:
> Though the mmc core driver will continue to support the legacy
> "enable-sdio-wakeup" property to enable SDIO as the wakeup source,
> "wakeup-source" is the new standard binding.
>
> This patch replaces the legacy "enable-sdio-wakeup" with the unified
> "wakeup-source" property in order to avoid any further copy-paste
> duplication.
>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/a2450401/attachment.sig>
^ permalink raw reply
* [PATCH V2] dmaengine: qcom_hidma: cleanup sysfs entries during remove
From: Sinan Kaya @ 2016-11-14 19:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <457a0a58-fcb5-26d6-99e6-7192dd071e1c@codeaurora.org>
Hi Vinod,
On 11/13/2016 10:10 PM, Sinan Kaya wrote:
> On 11/13/2016 10:04 PM, Vinod Koul wrote:
>> On Wed, Oct 19, 2016 at 02:42:46PM -0400, Sinan Kaya wrote:
>>> The 4.8-rc8 kernel is printing duplicate file entry warnings while removing
>>> the HIDMA object. This is caused by stale sysfs entries remaining from the
>>> previous execution.
>>>
>>> _sysfs_warn_dup+0x5c/0x78
>>> sysfs_add_file_mode_ns+0x13c/0x1c0
>>> sysfs_create_file_ns+0x2c/0x40
>>> device_create_file+0x54/0xa0
>>> hidma_probe+0x7c8/0x808
>>>
>>> Create hidma_sysfs_init and hidma_sysfs_uninit functions and call them from
>>> the probe and remove path. To do proper clean up, adding the attrs object
>>> to the device data structure to keep it around until remove call is made.
>>
>> This doesnt apply for me, I think due to other patches applied..
>>
>
> OK. Let me rebase.
>
I fetched your topic/qcom branch and applied this patch on top.
This is what I see at this moment.
22f20f5 dmaengine: qcom_hidma: cleanup sysfs entries during remove
8cc12b2 dmaengine: qcom_hidma: hide MSI handler when unused
87ffcea dmaengine: qcom_hidma: remove unneeded of_node_put()
1c0e3e8 dmaengine: qcom_hidma: add MSI support for interrupts
I posted V3 a minute ago with the contents of 22f20f5.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114185621.GC27931@tuxbot>
On 14/11/16 18:56, Bjorn Andersson wrote:
> On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
>
>> This patch adds support to PM8821 PMIC and interrupt support.
>> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>> Changes from v1:
>> - Removed unnessary locking spotted by Bjorn
>> - updated register naming to reflect PM8821
>> - lot of cleanups suggested by Bjorn
>> - rebased on top of Linus Walleij's pm8xxx namespace
>> cleanup patch.
>
> Looks good, just some minor style nits below.
Thanks, I will address all the comments in next version.
>
>>
>> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
>> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
>> 2 files changed, 238 insertions(+), 10 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> index 37a088f..8f1b4ec 100644
>> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
>> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
>> Definition: must be one of:
>> "qcom,pm8058"
>> "qcom,pm8921"
>> + "qcom,pm8821"
>
> 8 < 9, so move it one step up please.
sure.. makes sense.
>
>>
>> - #address-cells:
>> Usage: required
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> [..]
>> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
>> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
>> +#define PM8821_SSBI_REG(m, b, offset) \
>> + ((m == 0) ? \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
>> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
>> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
>> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
>> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
>> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
>
> I like how this cleaned up the rest of the implementation.
>
> [..]
>
>> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
>> + int master, int block)
>> +{
>> + int pmirq, irq, i, ret;
>> + unsigned int bits;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
>> + if (ret) {
>> + pr_err("Failed reading %d block ret=%d", block, ret);
>
> "Reading block %d failed ret=%d"
yep.
>
>> + return;
>> + }
>> + if (!bits) {
>> + pr_err("block bit set in master but no irqs: %d", block);
>
> This seems more like a debug thing, either showing missbehaving hardware
> or something odd in the driver. I think you should drop the print or
> make it pr_debug().
okay.
>
>> + return;
>> + }
>
> I would prefer that you just drop the entire if statement, it's just an
> corner case optimization with a info print.
>
i will have a closer look at this part once again.
>> +
>> + /* Convert block offset to global block number */
>> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
>> +
>> + /* Check IRQ bits */
>> + for (i = 0; i < 8; i++) {
>> + if (bits & BIT(i)) {
>> + pmirq = block * 8 + i;
>> + irq = irq_find_mapping(chip->irqdomain, pmirq);
>> + generic_handle_irq(irq);
>> + }
>> + }
>> +
>
> Empty line
will fix all the empty lines in next version.
>
>> +}
>> +
>> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
>> + int master, u8 master_val)
>> +{
>> + int block;
>> +
>> + for (block = 1; block < 8; block++)
>> + if (master_val & BIT(block))
>> + pm8821_irq_block_handler(chip, master, block);
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
> ^
> |
> I see you're using vim :)
>
>> + return;
>> + }
>> +
>> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
>
> Indentation
>
>> + if (master & GENMASK(7, 1))
>> + pm8821_irq_master_handler(chip, 0, master);
>> +
>> + /* bit 0 marks if master 1 contains any bits */
>
> Dito
yep.
>
>> + if (!(master & BIT(0)))
>> + goto done;
>> +
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
>> + if (ret) {
>> + pr_err("Failed to read master 1 ret=%d\n", ret);
>> + return;
>
> "goto done;" so that we pass chained_irq_exit()
yes,
>
>> + }
>> +
>> + pm8821_irq_master_handler(chip, 1, master);
>> +
>> +done:
>> + chained_irq_exit(irq_chip, desc);
>> +}
>> +
>
> [..]
>
>> +static void pm8821_irq_mask_ack(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + u8 block, master;
>> + int irq_bit, rc;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to mask IRQ %d rc=%d\n"
>
>> + return;
>> + }
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
>> + BIT(irq_bit), BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc) {
>> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
>> + pmirq, rc);
>
> "Failed to clear IRQ %d rc=%d\n"
>
>> + }
>> +
>
> Empty line
>
>> +}
>> +
>> +static void pm8821_irq_unmask(struct irq_data *d)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + unsigned int pmirq = irqd_to_hwirq(d);
>> + int irq_bit, rc;
>> + u8 block, master;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_update_bits(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
>> + BIT(irq_bit), ~BIT(irq_bit));
>> +
>
> Empty line
>
>> + if (rc)
>> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
>
> "Failed to unmask IRQ %d rc=%d\n"
will update it in next version.
>
>> +
>
> Empty line
>
>> +}
>> +
>> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
>> + enum irqchip_irq_state which,
>> + bool *state)
>> +{
>> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
>> + int rc, pmirq = irqd_to_hwirq(d);
>> + u8 block, irq_bit, master;
>> + unsigned int bits;
>> +
>> + block = pmirq / 8;
>> + master = block / PM8821_BLOCKS_PER_MASTER;
>> + irq_bit = pmirq % 8;
>> + block %= PM8821_BLOCKS_PER_MASTER;
>> +
>> + rc = regmap_read(chip->regmap,
>> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
>> + if (rc) {
>> + pr_err("Failed Reading Status rc=%d\n", rc);
>
> Odd capitalization, I suggest that you match it to the other functions
> by:
>
> "Reading status of IRQ %d failed rc=%d\n"
>
Okay
>> + return rc;
>> + }
>> +
>> + *state = !!(bits & BIT(irq_bit));
>> +
>> + return rc;
>> +}
>> +
>
> [..]
>
>>
>> static int pm8xxx_probe(struct platform_device *pdev)
>> {
>> + const struct of_device_id *match;
>> + const struct pm_irq_data *data;
>> struct regmap *regmap;
>> int irq, rc;
>> unsigned int val;
>> u32 rev;
>> struct pm_irq_chip *chip;
>> - unsigned int nirqs = PM8XXX_NR_IRQS;
>> +
>> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
>> + if (!match) {
>> + dev_err(&pdev->dev, "No matching driver data found\n");
>> + return -EINVAL;
>> + }
>> +
>> + data = match->data;
>
> data = of_device_get_match_data(&pdev->dev); (from of_device.h)
This is good one.. I will use it in next version.
> Regards,
> Bjorn
>
^ permalink raw reply
* [PATCH v5 00/23] Support qcom's HSIC USB and rewrite USB2 HS support
From: Stephen Boyd @ 2016-11-14 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111074017.GA21045@b29397-desktop>
Quoting Peter Chen (2016-11-10 23:40:17)
> On Tue, Oct 18, 2016 at 01:51:39PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-10-18 02:31:40)
> > > On Mon, Oct 17, 2016 at 06:56:13PM -0700, Stephen Boyd wrote:
> > > > I've also sent separate patches for other minor pieces to make this
> > > > all work. The full tree can be found here[2], hacks and all to get
> > > > things working. I've tested this on the db410c, apq8074 dragonboard,
> > > > and ifc6410 with configfs gadgets and otg cables.
> > > >
> > > > Patches based on v4.8-rc1
> >
> > Oops should be v4.9-rc1 here.
> >
> > > >
> > > > Changes from v4:
> > > > * Picked up Acks from Rob
> > > > * Updated HS phy init sequence DT property to restrict it to offsets
> > >
> > > I remembered that you got all my acks for chipidea patches, right? I did
> > > not check for this series.
> >
> > Sorry I've added in one more patch
> >
> > usb: chipidea: Emulate OTGSC interrupt enable path
> >
> > to fix extcon interrupt emulation even further.
> >
> > >
> > > Besides, the patch "gpu: Remove depends on RESET_CONTROLLER when not a
> > > provider" [1] still not be accepted, I need this patch to be merged
> > > first, then apply your chipidea part, otherwise, there is a building
> > > warning.
> > >
> > > [1] https://patchwork.kernel.org/patch/9322583/
> >
> > Yes, I'm going to resend that patch now. I hope that David will apply it
> > for -rc2.
>
> Stephen, just a mind. I have rebased Greg's usb-next tree (v4.9-rc3 on
> it), your GPU fix is still not there.
>
It looks like the patch is in drm-misc. I think they're going to hold
off on merging it until the next merge window though. fb80016af071 is
the commit in drm-misc tree and in linux-next. I'm not sure anything can
be done here besides a cross tree merge or ignore the warning?
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a1116e3f-32d2-aa2d-9404-1d8147bd8500@codeaurora.org>
On 14/11/16 18:40, Stephen Boyd wrote:
> On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
>> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
>> index 7f9620e..dc347d3 100644
>> --- a/drivers/mfd/qcom-pm8xxx.c
>> +++ b/drivers/mfd/qcom-pm8xxx.c
>> +
>> +static void pm8821_irq_handler(struct irq_desc *desc)
>> +{
>> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
>> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
>> + unsigned int master;
>> + int ret;
>> +
>> + chained_irq_enter(irq_chip, desc);
>> + ret = regmap_read(chip->regmap,
>> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
>> + if (ret) {
>> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
>
> Hm? vi?
yes.. That was good catch!! will fix it in next version...
>
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aee5072c-4e09-547e-2f58-7b2106bced3c@redhat.com>
On 11/14/2016 10:45 AM, Laura Abbott wrote:
> On 11/11/2016 04:44 PM, Florian Fainelli wrote:
>> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
>> debug_virt_to_phys() which helps catch vmalloc space addresses being
>> passed. This is helpful in debugging bogus drivers that just assume
>> linear mappings all over the place.
>>
>> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
>> __virt_to_phys() as being the functional implementation of the address
>> translation, so we special case the debug stub to call into
>> __virt_to_phys directly.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/include/asm/memory.h | 4 ++++
>> arch/arm64/include/asm/memory.h | 4 ++++
>> include/asm-generic/memory_model.h | 4 ++++
>> mm/debug.c | 15 +++++++++++++++
>> 4 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index 76cbd9c674df..448dec9b8b00 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index b71086d25195..c9e436b28523 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
>> index 5148150cc80b..426085757258 100644
>> --- a/include/asm-generic/memory_model.h
>> +++ b/include/asm-generic/memory_model.h
>> @@ -80,6 +80,10 @@
>> #define page_to_pfn __page_to_pfn
>> #define pfn_to_page __pfn_to_page
>>
>> +#ifdef CONFIG_DEBUG_VM
>> +unsigned long debug_virt_to_phys(volatile void *address);
>> +#endif /* CONFIG_DEBUG_VM */
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/mm/debug.c b/mm/debug.c
>> index 9feb699c5d25..72b2ca9b11f4 100644
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
>> );
>> }
>>
>> +#include <asm/memory.h>
>> +#include <linux/mm.h>
>> +
>> +unsigned long debug_virt_to_phys(volatile void *address)
>> +{
>> + BUG_ON(is_vmalloc_addr((const void *)address));
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
>> + defined(CONFIG_MICROBLAZE)
>> + return __virt_to_phys(address);
>> +#else
>> + return virt_to_phys(address);
>> +#endif
>> +}
>> +EXPORT_SYMBOL(debug_virt_to_phys);
>> +
>> #endif /* CONFIG_DEBUG_VM */
>>
>
> is_vmalloc_addr is necessary but not sufficient. This misses
> cases like module addresses.
Indeed, thanks.
> The x86 version (CONFIG_DEBUG_VIRTUAL)
> bounds checks against the known linear map to catch all cases.
> I'm for a generic approach to this if it can catch all cases
> that an architecture specific version would catch.
For one, my patch causes an early BUG to occur on ARM64 during
arch/arm64/kernel/setup.c::setup_arch when we call
cpu_uninstall_idmap(). I suspect there could be a bunch of little checks
like these where we'd have to have an architecture specific "is this
physical/virtual address valid" that may make a generic implementation
hard to come up with.
--
Florian
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-11-14 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFofZdFfGA8gbS9FJxAX5Ub-s8yZWDcNVOgwiEBpho4oyw@mail.gmail.com>
Hi,
On 11/11/2016 06:34 AM, Ulf Hansson wrote:
> On 10 November 2016 at 20:56, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Rob, Ulf, Jon,
>>
>> On 10/27/2016 08:15 AM, Dave Gerlach wrote:
>>>
>>> +Jon
>>> On 10/26/2016 04:59 PM, Rob Herring wrote:
>>>>
>>>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com>
>>>> wrote:
>>>>>
>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>
>>>>>> Hi,
>>>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>>>>>
>>>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>>>
>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>>>> control device power states.
>>>>>>>>
>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>
>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>> ---
>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54
>>>>>>>> +++++++++++++
>>>>>>>> MAINTAINERS | 2 +
>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>> ++++++++++++++++++++++
>>>>>>>> 3 files changed, 146 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..32f38a349656
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> @@ -0,0 +1,54 @@
>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>> +---------------------------------------------
>>>>>>>> +
>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>> that is
>>>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>> system
>>>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>>>> domain
>>>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>>>> use of
>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>> +
>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>> +
>>>>>>>> +PM Domain Node
>>>>>>>> +==============
>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>> PMMC,
>>>>>>>> +which in this case is the single implementation as documented by the
>>>>>>>> generic
>>>>>>>> +PM domain bindings in
>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the
>>>>>>>> devices.
>>>>>>>>
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +k2g_pds: k2g_pds {
>>>>>>>
>>>>>>>
>>>>>>> should use generic name like "power-contoller", e.g. k2g_pds:
>>>>>>> power-controller
>>>>>>
>>>>>>
>>>>>> Ok, that makes more sense.
>>>>>>
>>>>>>>
>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>> + ti,sci = <&pmmc>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +PM Domain Consumers
>>>>>>>> +===================
>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>> provide
>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>> device
>>>>>>>> +specific ID that identifies the device.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>> node.
>>>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI
>>>>>>>> to
>>>>>>>> + be used for device control.
>>>>>>>
>>>>>>>
>>>>>>> This ID doesn't look right.
>>>>>>>
>>>>>>> Why not use #power-domain-cells = <1> and pass the index in the DT?
>>>>>>> ...
>>>>
>>>>
>>>> Exactly. ti,sci-id is a NAK for me.
>>>
>>>
>>> I was told not to use the onecell during v1 discussion. I agree this would
>>> be
>>> ideal but I cannot due to what the bindings represent, the phandle
>>> parameter is
>>> an index into a list of genpds, whereas we need an actual ID number we can
>>> use
>>> and I do not have the ability to get that from the phandle.
>>>
>>> @Ulf/Jon, is there any hope of bringing back custom xlate functions for
>>> genpd
>>> providers? I don't have a good background on why it was even removed. I
>>> can
>>> maintain a single genpd for all devices but I need a way to parse this ID,
>>> whether it's from a separate property or a phandle. It is locked now to
>>> indexing
>>> into a list of genpds but I need additional per device information for
>>> devices
>>> bound to a genpd and I need either a custom parameter or the ability to
>>> parse
>>> the phandle myself.
>>>
>>
>> Any comments here? The meaning of the phandle onecell is fixed in the genpd
>> framework so I'm not sure how we want to move forward with this, I need to
>> pass a power domain ID to the genpd driver, and if this shouldn't be a new
>> property I'm not sure what direction we should take.
>>
>> Regards,
>> Dave
>>
>>
>>>>
>>>>>>>
>>>>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for
>>>>>>>> k2g.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +uart0: serial at 02530c00 {
>>>>>>>> + compatible = "ns16550a";
>>>>>>>> + ...
>>>>>>>> + power-domains = <&k2g_pds>;
>>>>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>>>>
>>>>>>>
>>>>>>> ... like this:
>>>>>>>
>>>>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>>>>
>>>>>>
>>>>>> That's how I did it in version one actually. I was able to define my
>>>>>> own xlate function to parse the phandle and get that index, but Ulf
>>>>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>>>>> providers and dropped the concept of adding your own xlate. This locks
>>>>>> the onecell approach to using a fixed static array of genpds that get
>>>>>> indexed into (without passing the index to the provider, just the
>>>>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>>>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>>>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>>>>> the sci-id and then use it in the genpd device start/stop hooks.
>>>>
>>>>
>>>> I have no idea what any of this means. All sounds like driver
>>>> architecture, not anything to do with bindings.
>>>
>>>
>>> This was a response to Kevin, not part of binding description.
>>>
>>>>
>>>>>
>>>>> Ah, right. I remember now. This approach allows you to use a single
>>>>> genpd as discussed earlier.
>>>>>
>>>>> Makes sense now, suggestion retracted.
>>>>
>>>>
>>>> IIRC, the bindings in Jon's case had a node for each domain and didn't
>>>> need any additional property.
>>>
>>>
>>> Yes but we only have one domain and index into it, not into a list of
>>> domains,
>
> Exactly. And this my main point as well. We are not talking about a
> domain property but a device property.
>
>>> so the additional property is solving a different problem.
>
> Yes.
>
> Perhaps you could try to elaborate about what the TI SCI ID really
> represents for the device, as to help Rob understand the bigger
> picture?
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Thanks for the response. Yes, you've pretty much hit it on the head. It
is not an index into a list of genpds but rather identifies the device
*within* a single genpd. It is a property specific to each device that
resides in a ti-sci-genpd, not a mapping describing which genpd the
device belongs to. The generic power domain binding is concerned with
mapping the device to a specific genpd, which is does fine for us, but
we have a sub mapping for devices that exist inside a genpd which, we
must describe as well, hence the ti,sci-id.
Regards,
Dave
>
> Hope that helps.
>
> Kind regards
> Uffe
>
^ permalink raw reply
* [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ 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