* [PATCH 4/7] iommu/amd: make sure TLB to be flushed before IOVA freed
From: Zhen Lei @ 2018-05-31 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-1-git-send-email-thunder.leizhen@huawei.com>
Although the mapping has already been removed in the page table, it maybe
still exist in TLB. Suppose the freed IOVAs is reused by others before the
flush operation completed, the new user can not correctly access to its
meomory.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 8fb8c73..93aa389 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2402,9 +2402,9 @@ static void __unmap_single(struct dma_ops_domain *dma_dom,
}
if (amd_iommu_unmap_flush) {
- dma_ops_free_iova(dma_dom, dma_addr, pages);
domain_flush_tlb(&dma_dom->domain);
domain_flush_complete(&dma_dom->domain);
+ dma_ops_free_iova(dma_dom, dma_addr, pages);
} else {
pages = __roundup_pow_of_two(pages);
queue_iova(&dma_dom->iovad, dma_addr >> PAGE_SHIFT, pages, 0);
--
1.8.3
^ permalink raw reply related
* [PATCH 3/7] iommu: prepare for the non-strict mode support
From: Zhen Lei @ 2018-05-31 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-1-git-send-email-thunder.leizhen@huawei.com>
In common, a IOMMU unmap operation follow the below steps:
1. remove the mapping in page table of the specified iova range
2. execute tlbi command to invalid the mapping which is cached in TLB
3. wait for the above tlbi operation to be finished
4. free the IOVA resource
5. free the physical memory resource
This maybe a problem when unmap is very frequently, the combination of tlbi
and wait operation will consume a lot of time. A feasible method is put off
tlbi and iova-free operation, when accumulating to a certain number or
reaching a specified time, execute only one tlbi_all command to clean up
TLB, then free the backup IOVAs. Mark as non-strict mode.
But it must be noted that, although the mapping has already been removed in
the page table, it maybe still exist in TLB. And the freed physical memory
may also be reused for others. So a attacker can persistent access to memory
based on the just freed IOVA, to obtain sensible data or corrupt memory. So
the VFIO should always choose the strict mode.
This patch just add a new parameter for the unmap operation, to help the
upper functions capable choose which mode to be applied.
No functional changes.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/arm-smmu-v3.c | 2 +-
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/io-pgtable-arm-v7s.c | 6 +++---
drivers/iommu/io-pgtable-arm.c | 6 +++---
drivers/iommu/io-pgtable.h | 2 +-
drivers/iommu/ipmmu-vmsa.c | 2 +-
drivers/iommu/msm_iommu.c | 2 +-
drivers/iommu/mtk_iommu.c | 2 +-
drivers/iommu/qcom_iommu.c | 2 +-
include/linux/iommu.h | 2 ++
10 files changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 4402187..59b3387 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1767,7 +1767,7 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova,
if (!ops)
return 0;
- return ops->unmap(ops, iova, size);
+ return ops->unmap(ops, iova, size, IOMMU_STRICT);
}
static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..253e807 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1249,7 +1249,7 @@ static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,
if (!ops)
return 0;
- return ops->unmap(ops, iova, size);
+ return ops->unmap(ops, iova, size, IOMMU_STRICT);
}
static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 10e4a3d..799eced 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -658,7 +658,7 @@ static size_t __arm_v7s_unmap(struct arm_v7s_io_pgtable *data,
}
static size_t arm_v7s_unmap(struct io_pgtable_ops *ops, unsigned long iova,
- size_t size)
+ size_t size, int strict)
{
struct arm_v7s_io_pgtable *data = io_pgtable_ops_to_data(ops);
@@ -883,7 +883,7 @@ static int __init arm_v7s_do_selftests(void)
size = 1UL << __ffs(cfg.pgsize_bitmap);
while (i < loopnr) {
iova_start = i * SZ_16M;
- if (ops->unmap(ops, iova_start + size, size) != size)
+ if (ops->unmap(ops, iova_start + size, size, IOMMU_STRICT) != size)
return __FAIL(ops);
/* Remap of partial unmap */
@@ -902,7 +902,7 @@ static int __init arm_v7s_do_selftests(void)
while (i != BITS_PER_LONG) {
size = 1UL << i;
- if (ops->unmap(ops, iova, size) != size)
+ if (ops->unmap(ops, iova, size, IOMMU_STRICT) != size)
return __FAIL(ops);
if (ops->iova_to_phys(ops, iova + 42))
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 39c2a05..e0f52db 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -624,7 +624,7 @@ static size_t __arm_lpae_unmap(struct arm_lpae_io_pgtable *data,
}
static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
- size_t size)
+ size_t size, int strict)
{
struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
arm_lpae_iopte *ptep = data->pgd;
@@ -1108,7 +1108,7 @@ static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
/* Partial unmap */
size = 1UL << __ffs(cfg->pgsize_bitmap);
- if (ops->unmap(ops, SZ_1G + size, size) != size)
+ if (ops->unmap(ops, SZ_1G + size, size, IOMMU_STRICT) != size)
return __FAIL(ops, i);
/* Remap of partial unmap */
@@ -1124,7 +1124,7 @@ static int __init arm_lpae_run_tests(struct io_pgtable_cfg *cfg)
while (j != BITS_PER_LONG) {
size = 1UL << j;
- if (ops->unmap(ops, iova, size) != size)
+ if (ops->unmap(ops, iova, size, IOMMU_STRICT) != size)
return __FAIL(ops, i);
if (ops->iova_to_phys(ops, iova + 42))
diff --git a/drivers/iommu/io-pgtable.h b/drivers/iommu/io-pgtable.h
index 2df7909..2908806 100644
--- a/drivers/iommu/io-pgtable.h
+++ b/drivers/iommu/io-pgtable.h
@@ -120,7 +120,7 @@ struct io_pgtable_ops {
int (*map)(struct io_pgtable_ops *ops, unsigned long iova,
phys_addr_t paddr, size_t size, int prot);
size_t (*unmap)(struct io_pgtable_ops *ops, unsigned long iova,
- size_t size);
+ size_t size, int strict);
phys_addr_t (*iova_to_phys)(struct io_pgtable_ops *ops,
unsigned long iova);
};
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index 40ae6e8..e6d9e11 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -716,7 +716,7 @@ static size_t ipmmu_unmap(struct iommu_domain *io_domain, unsigned long iova,
{
struct ipmmu_vmsa_domain *domain = to_vmsa_domain(io_domain);
- return domain->iop->unmap(domain->iop, iova, size);
+ return domain->iop->unmap(domain->iop, iova, size, IOMMU_STRICT);
}
static void ipmmu_iotlb_sync(struct iommu_domain *io_domain)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 0d33504..180fa3d 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -532,7 +532,7 @@ static size_t msm_iommu_unmap(struct iommu_domain *domain, unsigned long iova,
unsigned long flags;
spin_lock_irqsave(&priv->pgtlock, flags);
- len = priv->iop->unmap(priv->iop, iova, len);
+ len = priv->iop->unmap(priv->iop, iova, len, IOMMU_STRICT);
spin_unlock_irqrestore(&priv->pgtlock, flags);
return len;
diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index f2832a1..54661ed 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -386,7 +386,7 @@ static size_t mtk_iommu_unmap(struct iommu_domain *domain,
size_t unmapsz;
spin_lock_irqsave(&dom->pgtlock, flags);
- unmapsz = dom->iop->unmap(dom->iop, iova, size);
+ unmapsz = dom->iop->unmap(dom->iop, iova, size, IOMMU_STRICT);
spin_unlock_irqrestore(&dom->pgtlock, flags);
return unmapsz;
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index 65b9c99..90abde1 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -444,7 +444,7 @@ static size_t qcom_iommu_unmap(struct iommu_domain *domain, unsigned long iova,
*/
pm_runtime_get_sync(qcom_domain->iommu->dev);
spin_lock_irqsave(&qcom_domain->pgtbl_lock, flags);
- ret = ops->unmap(ops, iova, size);
+ ret = ops->unmap(ops, iova, size, IOMMU_STRICT);
spin_unlock_irqrestore(&qcom_domain->pgtbl_lock, flags);
pm_runtime_put_sync(qcom_domain->iommu->dev);
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 19938ee..39b3150 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -86,6 +86,8 @@ struct iommu_domain_geometry {
#define IOMMU_DOMAIN_DMA (__IOMMU_DOMAIN_PAGING | \
__IOMMU_DOMAIN_DMA_API)
+#define IOMMU_STRICT 1
+
struct iommu_domain {
unsigned type;
const struct iommu_ops *ops;
--
1.8.3
^ permalink raw reply related
* [PATCH 2/7] iommu/arm-smmu-v3: fix the implementation of flush_iotlb_all hook
From: Zhen Lei @ 2018-05-31 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-1-git-send-email-thunder.leizhen@huawei.com>
.flush_iotlb_all can not just wait for previous tlbi operations to be
completed, but should also invalid all TLBs of the related domain.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/arm-smmu-v3.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 1d64710..4402187 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1770,6 +1770,14 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova,
return ops->unmap(ops, iova, size);
}
+static void arm_smmu_flush_iotlb_all(struct iommu_domain *domain)
+{
+ struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+
+ if (smmu_domain->smmu)
+ arm_smmu_tlb_inv_context(smmu_domain);
+}
+
static void arm_smmu_iotlb_sync(struct iommu_domain *domain)
{
struct arm_smmu_device *smmu = to_smmu_domain(domain)->smmu;
@@ -1998,7 +2006,7 @@ static void arm_smmu_put_resv_regions(struct device *dev,
.map = arm_smmu_map,
.unmap = arm_smmu_unmap,
.map_sg = default_iommu_map_sg,
- .flush_iotlb_all = arm_smmu_iotlb_sync,
+ .flush_iotlb_all = arm_smmu_flush_iotlb_all,
.iotlb_sync = arm_smmu_iotlb_sync,
.iova_to_phys = arm_smmu_iova_to_phys,
.add_device = arm_smmu_add_device,
--
1.8.3
^ permalink raw reply related
* [PATCH 1/7] iommu/dma: fix trival coding style mistake
From: Zhen Lei @ 2018-05-31 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527752569-18020-1-git-send-email-thunder.leizhen@huawei.com>
The static function iova_reserve_iommu_regions is only called by function
iommu_dma_init_domain, and the 'if (!dev)' check in iommu_dma_init_domain
affect it only, so we can safely move the check into it. I think it looks
more natural.
In addition, the local variable 'ret' is only assigned in the branch of
'if (region->type == IOMMU_RESV_MSI)', so the 'if (ret)' should also only
take effect in the branch, add a brace to enclose it.
No functional changes.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
drivers/iommu/dma-iommu.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ddcbbdb..4e885f7 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -231,6 +231,9 @@ static int iova_reserve_iommu_regions(struct device *dev,
LIST_HEAD(resv_regions);
int ret = 0;
+ if (!dev)
+ return 0;
+
if (dev_is_pci(dev))
iova_reserve_pci_windows(to_pci_dev(dev), iovad);
@@ -246,11 +249,12 @@ static int iova_reserve_iommu_regions(struct device *dev,
hi = iova_pfn(iovad, region->start + region->length - 1);
reserve_iova(iovad, lo, hi);
- if (region->type == IOMMU_RESV_MSI)
+ if (region->type == IOMMU_RESV_MSI) {
ret = cookie_init_hw_msi_region(cookie, region->start,
region->start + region->length);
- if (ret)
- break;
+ if (ret)
+ break;
+ }
}
iommu_put_resv_regions(dev, &resv_regions);
@@ -308,8 +312,6 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
}
init_iova_domain(iovad, 1UL << order, base_pfn);
- if (!dev)
- return 0;
return iova_reserve_iommu_regions(dev, domain);
}
--
1.8.3
^ permalink raw reply related
* [PATCH 0/7] add non-strict mode support for arm-smmu-v3
From: Zhen Lei @ 2018-05-31 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In common, a IOMMU unmap operation follow the below steps:
1. remove the mapping in page table of the specified iova range
2. execute tlbi command to invalid the mapping which is cached in TLB
3. wait for the above tlbi operation to be finished
4. free the IOVA resource
5. free the physical memory resource
This maybe a problem when unmap is very frequently, the combination of tlbi
and wait operation will consume a lot of time. A feasible method is put off
tlbi and iova-free operation, when accumulating to a certain number or
reaching a specified time, execute only one tlbi_all command to clean up
TLB, then free the backup IOVAs. Mark as non-strict mode.
But it must be noted that, although the mapping has already been removed in
the page table, it maybe still exist in TLB. And the freed physical memory
may also be reused for others. So a attacker can persistent access to memory
based on the just freed IOVA, to obtain sensible data or corrupt memory. So
the VFIO should always choose the strict mode.
Some may consider put off physical memory free also, that will still follow
strict mode. But for the map_sg cases, the memory allocation is not controlled
by IOMMU APIs, so it is not enforceable.
Fortunately, Intel and AMD have already applied the non-strict mode, and put
queue_iova() operation into the common file dma-iommu.c., and my work is based
on it. The difference is that arm-smmu-v3 driver will call IOMMU common APIs to
unmap, but Intel and AMD IOMMU drivers are not.
Below is the performance data of strict vs non-strict for NVMe device:
Randomly Read IOPS: 146K(strict) vs 573K(non-strict)
Randomly Write IOPS: 143K(strict) vs 513K(non-strict)
Zhen Lei (7):
iommu/dma: fix trival coding style mistake
iommu/arm-smmu-v3: fix the implementation of flush_iotlb_all hook
iommu: prepare for the non-strict mode support
iommu/amd: make sure TLB to be flushed before IOVA freed
iommu/dma: add support for non-strict mode
iommu/io-pgtable-arm: add support for non-strict mode
iommu/arm-smmu-v3: add support for non-strict mode
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/arm-smmu-v3.c | 16 ++++++++++++---
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/dma-iommu.c | 41 ++++++++++++++++++++++++++++++--------
drivers/iommu/io-pgtable-arm-v7s.c | 6 +++---
drivers/iommu/io-pgtable-arm.c | 28 ++++++++++++++------------
drivers/iommu/io-pgtable.h | 2 +-
drivers/iommu/ipmmu-vmsa.c | 2 +-
drivers/iommu/msm_iommu.c | 2 +-
drivers/iommu/mtk_iommu.c | 2 +-
drivers/iommu/qcom_iommu.c | 2 +-
include/linux/iommu.h | 5 +++++
12 files changed, 76 insertions(+), 34 deletions(-)
--
1.8.3
^ permalink raw reply
* [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Stephen Boyd @ 2018-05-31 7:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9f2e1aa8-21c1-10b0-6193-e6bc16993a0d@codeaurora.org>
Quoting Sricharan R (2018-05-30 21:57:20)
> Hi Stephen,
>
> On 5/30/2018 9:25 PM, Stephen Boyd wrote:
> > Quoting Sricharan R (2018-05-24 22:40:11)
> >> Hi Bjorn,
> >>
> >> On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
> >>> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
> >>>
> >>>> From: Stephen Boyd <sboyd@codeaurora.org>
> >>>>
> >>>> Krait CPUs have a handful of L2 cache controller registers that
> >>>> live behind a cp15 based indirection register. First you program
> >>>> the indirection register (l2cpselr) to point the L2 'window'
> >>>> register (l2cpdr) at what you want to read/write. Then you
> >>>> read/write the 'window' register to do what you want. The
> >>>> l2cpselr register is not banked per-cpu so we must lock around
> >>>> accesses to it to prevent other CPUs from re-pointing l2cpdr
> >>>> underneath us.
> >>>>
> >>>> Cc: Mark Rutland <mark.rutland@arm.com>
> >>>> Cc: Russell King <linux@arm.linux.org.uk>
> >>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >>>
> >>> This should have your signed-off-by here as well.
> >>>
> >>
> >> ok.
> >>
> >>> Apart from that:
> >>>
> >>> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >>>
> >>
> >
> > Will these patches come around again? I'll do a quick sweep on them
> > today but I expect them to be resent.
>
> Sure, i will have to resend them again, fixing couple of Bjorn's
> minor comments. Will address your comments that you would give
> as well along with that.
>
Ok. One general comment is that it would be nice if the bindings for all
the nodes that are introduced included 'clocks' properties and also
maybe 'clock-names' properties for the clocks that are consumed by each
node. Right now, we hide those details from DT and rely on the string
names to hook the clk tree up for us. That sort of prevents us from
moving away from string easily, so I would just throw the clocks into
the binding right now and always have them there just in case we want to
use the binding to figure out the hierarchy in the future.
I've been thinking we need to do something similar for the gcc and other
nodes for any clks they use, but I haven't gotten around to it.
Otherwise the patches look mostly ok to me. Not sure I'll have any other
comments.
^ permalink raw reply
* [PATCH] PCI: mediatek: Add system pm support for MT2712
From: Honghui Zhang @ 2018-05-31 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531042020.GQ39853@bhelgaas-glaptop.roam.corp.google.com>
On Wed, 2018-05-30 at 23:20 -0500, Bjorn Helgaas wrote:
> On Wed, May 30, 2018 at 10:35:36AM +0800, honghui.zhang at mediatek.com wrote:
> > From: Honghui Zhang <honghui.zhang@mediatek.com>
> >
> > The MTCMOS of PCIe Host for MT2712 will be off when system suspend, and all
> > the internel control register will be reset after system resume. The PCIe
> > link should be re-established and the related control register values should
> > be re-set after system resume.
> >
> > Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
> > CC: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > drivers/pci/host/pcie-mediatek.c | 82 ++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 82 insertions(+)
> >
> > diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
> > index dabf1086..60f98d92 100644
> > --- a/drivers/pci/host/pcie-mediatek.c
> > +++ b/drivers/pci/host/pcie-mediatek.c
> > @@ -132,12 +132,14 @@ struct mtk_pcie_port;
> > /**
> > * struct mtk_pcie_soc - differentiate between host generations
> > * @need_fix_class_id: whether this host's class ID needed to be fixed or not
> > + * @pm_support: whether the host's MTCMOS will be off when suspend
> > * @ops: pointer to configuration access functions
> > * @startup: pointer to controller setting functions
> > * @setup_irq: pointer to initialize IRQ functions
> > */
> > struct mtk_pcie_soc {
> > bool need_fix_class_id;
> > + bool pm_support;
> > struct pci_ops *ops;
> > int (*startup)(struct mtk_pcie_port *port);
> > int (*setup_irq)(struct mtk_pcie_port *port, struct device_node *node);
> > @@ -1179,12 +1181,91 @@ static int mtk_pcie_probe(struct platform_device *pdev)
> > return err;
> > }
> >
> > +static int __maybe_unused mtk_pcie_suspend_noirq(struct device *dev)
> > +{
> > + struct platform_device *pdev;
> > + struct mtk_pcie *pcie;
> > + struct mtk_pcie_port *port;
> > + const struct mtk_pcie_soc *soc;
> > +
> > + pdev = to_platform_device(dev);
> > + pcie = platform_get_drvdata(pdev);
> > + soc = pcie->soc;
> > + if (!soc->pm_support)
> > + return 0;
> > +
> > + list_for_each_entry(port, &pcie->ports, list) {
> > + clk_disable_unprepare(port->ahb_ck);
> > + clk_disable_unprepare(port->sys_ck);
> > + phy_power_off(port->phy);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int __maybe_unused mtk_pcie_resume_noirq(struct device *dev)
>
> I don't really like the __maybe_unused annotations. Looking at the
> other users of SET_NOIRQ_SYSTEM_SLEEP_PM_OPS, I think a small majority
> of them wrap the function definitions in #ifdef CONFIG_PM_SLEEP
> instead of using __maybe_unused. That's also a bit ugly, but has the
> advantage of truly omitting the definitions when they're not needed.
Ok, I will follow your advise in the next version.
thanks.
^ permalink raw reply
* [PATCH v2 7/9] PM / Domains: Split genpd_dev_pm_attach()
From: Viresh Kumar @ 2018-05-31 7:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-8-ulf.hansson@linaro.org>
On 29-05-18, 12:04, Ulf Hansson wrote:
> To extend genpd to deal with allowing multiple PM domains per device, some
> of the code in genpd_dev_pm_attach() can be re-used. Let's prepare for this
> by moving some of the code into a sub-function.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 60 ++++++++++++++++++++-----------------
> 1 file changed, 33 insertions(+), 27 deletions(-)
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 08/10] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: Archit Taneja @ 2018-05-31 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527682561-1386-9-git-send-email-m.purski@samsung.com>
Hi,
On Wednesday 30 May 2018 05:45 PM, Maciej Purski wrote:
> From: Andrzej Hajda <a.hajda@samsung.com>
>
> Add a drm_bridge driver for the Toshiba TC358764 DSI to LVDS bridge.
>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Signed-off-by: Maciej Purski <m.purski@samsung.com>
> ---
> drivers/gpu/drm/bridge/Kconfig | 9 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/tc358764.c | 547 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 557 insertions(+)
> create mode 100644 drivers/gpu/drm/bridge/tc358764.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index fa2c799..9bd3eb8 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -110,6 +110,15 @@ config DRM_THINE_THC63LVD1024
> ---help---
> Thine THC63LVD1024 LVDS/parallel converter driver.
>
> +config DRM_TOSHIBA_TC358764
> + tristate "TC358764 DSI/LVDS bridge"
> + depends on DRM && DRM_PANEL
> + depends on OF
> + select DRM_MIPI_DSI
> + select VIDEOMODE_HELPERS
I don't see videomode usage in the driver, can we drop this if it isn't
used?
> + help
> + Toshiba TC358764 DSI/LVDS bridge driver
> +
> config DRM_TOSHIBA_TC358767
> tristate "Toshiba TC358767 eDP bridge"
> depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 35f88d4..bf7c0ce 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> obj-$(CONFIG_DRM_SII902X) += sii902x.o
> obj-$(CONFIG_DRM_SII9234) += sii9234.o
> obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> +obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
> obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/tc358764.c b/drivers/gpu/drm/bridge/tc358764.c
> new file mode 100644
> index 0000000..3109eba
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/tc358764.c
> @@ -0,0 +1,547 @@
We'd need a SPDX license here?
> +/*
> + * Copyright (C) 2018 Samsung Electronics Co., Ltd
> + *
> + * Authors:
> + * Andrzej Hajda <a.hajda@samsung.com>
> + * Maciej Purski <m.purski@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.
> + *
> + */
> +
> +#include <drm/drm_atomic_helper.h>
> +
> +#include <drm/drmP.h>
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_panel.h>
> +
> +#include <drm/drm_crtc.h>
> +#include <drm/drm_crtc_helper.h>
> +
> +#include <linux/gpio/consumer.h>
> +#include <linux/of_graph.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <video/mipi_display.h>
> +#include <video/of_videomode.h>
> +#include <video/videomode.h>
> +
> +#define FLD_MASK(start, end) (((1 << ((start) - (end) + 1)) - 1) << (end))
> +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end))
> +
> +/* PPI layer registers */
> +#define PPI_STARTPPI 0x0104 /* START control bit */
> +#define PPI_LPTXTIMECNT 0x0114 /* LPTX timing signal */
> +#define PPI_LANEENABLE 0x0134 /* Enables each lane */
> +#define PPI_TX_RX_TA 0x013C /* BTA timing parameters */
> +#define PPI_D0S_CLRSIPOCOUNT 0x0164 /* Assertion timer for Lane 0 */
> +#define PPI_D1S_CLRSIPOCOUNT 0x0168 /* Assertion timer for Lane 1 */
> +#define PPI_D2S_CLRSIPOCOUNT 0x016C /* Assertion timer for Lane 2 */
> +#define PPI_D3S_CLRSIPOCOUNT 0x0170 /* Assertion timer for Lane 3 */
> +#define PPI_START_FUNCTION 1
> +
> +/* DSI layer registers */
> +#define DSI_STARTDSI 0x0204 /* START control bit of DSI-TX */
> +#define DSI_LANEENABLE 0x0210 /* Enables each lane */
> +#define DSI_RX_START 1
> +
> +/* Video path registers */
> +#define VP_CTRL 0x0450 /* Video Path Control */
> +#define VP_CTRL_MSF(v) FLD_VAL(v, 0, 0) /* Magic square in RGB666 */
> +#define VP_CTRL_VTGEN(v) FLD_VAL(v, 4, 4) /* Use chip clock for timing */
> +#define VP_CTRL_EVTMODE(v) FLD_VAL(v, 5, 5) /* Event mode */
> +#define VP_CTRL_RGB888(v) FLD_VAL(v, 8, 8) /* RGB888 mode */
> +#define VP_CTRL_VSDELAY(v) FLD_VAL(v, 31, 20) /* VSYNC delay */
> +#define VP_CTRL_HSPOL BIT(17) /* Polarity of HSYNC signal */
> +#define VP_CTRL_DEPOL BIT(18) /* Polarity of DE signal */
> +#define VP_CTRL_VSPOL BIT(19) /* Polarity of VSYNC signal */
> +#define VP_HTIM1 0x0454 /* Horizontal Timing Control 1 */
> +#define VP_HTIM1_HBP(v) FLD_VAL(v, 24, 16)
> +#define VP_HTIM1_HSYNC(v) FLD_VAL(v, 8, 0)
> +#define VP_HTIM2 0x0458 /* Horizontal Timing Control 2 */
> +#define VP_HTIM2_HFP(v) FLD_VAL(v, 24, 16)
> +#define VP_HTIM2_HACT(v) FLD_VAL(v, 10, 0)
> +#define VP_VTIM1 0x045C /* Vertical Timing Control 1 */
> +#define VP_VTIM1_VBP(v) FLD_VAL(v, 23, 16)
> +#define VP_VTIM1_VSYNC(v) FLD_VAL(v, 7, 0)
> +#define VP_VTIM2 0x0460 /* Vertical Timing Control 2 */
> +#define VP_VTIM2_VFP(v) FLD_VAL(v, 23, 16)
> +#define VP_VTIM2_VACT(v) FLD_VAL(v, 10, 0)
> +#define VP_VFUEN 0x0464 /* Video Frame Timing Update Enable */
> +
> +/* LVDS registers */
> +#define LV_MX0003 0x0480 /* Mux input bit 0 to 3 */
> +#define LV_MX0407 0x0484 /* Mux input bit 4 to 7 */
> +#define LV_MX0811 0x0488 /* Mux input bit 8 to 11 */
> +#define LV_MX1215 0x048C /* Mux input bit 12 to 15 */
> +#define LV_MX1619 0x0490 /* Mux input bit 16 to 19 */
> +#define LV_MX2023 0x0494 /* Mux input bit 20 to 23 */
> +#define LV_MX2427 0x0498 /* Mux input bit 24 to 27 */
> +#define LV_MX(b0, b1, b2, b3) (FLD_VAL(b0, 4, 0) | FLD_VAL(b1, 12, 8) | \
> + FLD_VAL(b2, 20, 16) | FLD_VAL(b3, 28, 24))
> +
> +/* Input bit numbers used in mux registers */
> +enum {
> + LVI_R0,
> + LVI_R1,
> + LVI_R2,
> + LVI_R3,
> + LVI_R4,
> + LVI_R5,
> + LVI_R6,
> + LVI_R7,
> + LVI_G0,
> + LVI_G1,
> + LVI_G2,
> + LVI_G3,
> + LVI_G4,
> + LVI_G5,
> + LVI_G6,
> + LVI_G7,
> + LVI_B0,
> + LVI_B1,
> + LVI_B2,
> + LVI_B3,
> + LVI_B4,
> + LVI_B5,
> + LVI_B6,
> + LVI_B7,
> + LVI_HS,
> + LVI_VS,
> + LVI_DE,
> + LVI_L0
> +};
> +
> +#define LV_CFG 0x049C /* LVDS Configuration */
> +#define LV_PHY0 0x04A0 /* LVDS PHY 0 */
> +#define LV_PHY0_RST(v) FLD_VAL(v, 22, 22) /* PHY reset */
> +#define LV_PHY0_IS(v) FLD_VAL(v, 15, 14)
> +#define LV_PHY0_ND(v) FLD_VAL(v, 4, 0) /* Frequency range select */
> +#define LV_PHY0_PRBS_ON(v) FLD_VAL(v, 20, 16) /* Clock/Data Flag pins */
> +
> +/* System registers */
> +#define SYS_RST 0x0504 /* System Reset */
> +#define SYS_ID 0x0580 /* System ID */
> +
> +#define SYS_RST_I2CS BIT(0) /* Reset I2C-Slave controller */
> +#define SYS_RST_I2CM BIT(1) /* Reset I2C-Master controller */
> +#define SYS_RST_LCD BIT(2) /* Reset LCD controller */
> +#define SYS_RST_BM BIT(3) /* Reset Bus Management controller */
> +#define SYS_RST_DSIRX BIT(4) /* Reset DSI-RX and App controller */
> +#define SYS_RST_REG BIT(5) /* Reset Register module */
> +
> +#define LPX_PERIOD 2
> +#define TTA_SURE 3
> +#define TTA_GET 0x20000
> +
> +/* Lane enable PPI and DSI register bits */
> +#define LANEENABLE_CLEN BIT(0)
> +#define LANEENABLE_L0EN BIT(1)
> +#define LANEENABLE_L1EN BIT(2)
> +#define LANEENABLE_L2EN BIT(3)
> +#define LANEENABLE_L3EN BIT(4)
> +
> +/* LVCFG fields */
> +#define LV_CFG_LVEN BIT(0)
> +#define LV_CFG_LVDLINK BIT(1)
> +#define LV_CFG_CLKPOL1 BIT(2)
> +#define LV_CFG_CLKPOL2 BIT(3)
> +
> +static const char * const tc358764_supplies[] = {
> + "vddc", "vddio", "vddmipi", "vddlvds133", "vddlvds112"
> +};
> +
> +struct tc358764 {
> + struct device *dev;
> + struct drm_bridge bridge;
> + struct drm_connector connector;
> + struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
> + struct gpio_desc *gpio_reset;
> +
> + struct drm_panel *panel;
> +};
> +
> +static int tc358764_read(struct tc358764 *ctx, u16 addr, u32 *val)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> + const struct mipi_dsi_host_ops *ops = dsi->host->ops;
> + struct mipi_dsi_msg msg = {
> + .type = MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM,
> + .channel = dsi->channel,
> + .flags = MIPI_DSI_MSG_USE_LPM,
> + .tx_buf = &addr,
> + .tx_len = 2,
> + .rx_buf = val,
> + .rx_len = 4
> + };
> + ssize_t ret;
> +
> + if (!ops || !ops->transfer)
> + return -EINVAL;
> +
> + cpu_to_le16s(&addr);
> +
> + ret = ops->transfer(dsi->host, &msg);
> + if (ret >= 0)
> + le32_to_cpus(val); > +
> + dev_dbg(ctx->dev, "read: %d, addr: %d\n", addr, *val);
> +
> + return ret;
> +}
> +
> +static int tc358764_write(struct tc358764 *ctx, u16 addr, u32 val)
> +{
> + struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> + const struct mipi_dsi_host_ops *ops = dsi->host->ops;
> + u8 data[6];
> + int ret;
> + struct mipi_dsi_msg msg = {
> + .type = MIPI_DSI_GENERIC_LONG_WRITE,
> + .channel = dsi->channel,
> + .flags = MIPI_DSI_MSG_USE_LPM | MIPI_DSI_MSG_REQ_ACK,
> + .tx_buf = data,
> + .tx_len = 6
> + };
> +
> + if (!ops || !ops->transfer)
> + return -EINVAL;
> +
> + data[0] = addr;
> + data[1] = addr >> 8;
> + data[2] = val;
> + data[3] = val >> 8;
> + data[4] = val >> 16;
> + data[5] = val >> 24;
> +
> + ret = ops->transfer(dsi->host, &msg);
> +
> + return ret;
> +}
> +
> +static inline struct tc358764 *bridge_to_tc358764(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct tc358764, bridge);
> +}
> +
> +static inline
> +struct tc358764 *connector_to_tc358764(struct drm_connector *connector)
> +{
> + return container_of(connector, struct tc358764, connector);
> +}
> +
> +static int tc358764_init(struct tc358764 *ctx)
> +{
> + u32 v = 0;
> +
> + tc358764_read(ctx, SYS_ID, &v);
> + dev_info(ctx->dev, "ID: %#x\n", v);
> +
> + /* configure PPI counters */
> + tc358764_write(ctx, PPI_TX_RX_TA, TTA_GET | TTA_SURE);
> + tc358764_write(ctx, PPI_LPTXTIMECNT, LPX_PERIOD);
> + tc358764_write(ctx, PPI_D0S_CLRSIPOCOUNT, 5);
> + tc358764_write(ctx, PPI_D1S_CLRSIPOCOUNT, 5);
> + tc358764_write(ctx, PPI_D2S_CLRSIPOCOUNT, 5);
> + tc358764_write(ctx, PPI_D3S_CLRSIPOCOUNT, 5);
> +
> + /* enable four data lanes and clock lane */
> + tc358764_write(ctx, PPI_LANEENABLE, LANEENABLE_L3EN | LANEENABLE_L2EN |
> + LANEENABLE_L1EN | LANEENABLE_L0EN | LANEENABLE_CLEN);
> + tc358764_write(ctx, DSI_LANEENABLE, LANEENABLE_L3EN | LANEENABLE_L2EN |
> + LANEENABLE_L1EN | LANEENABLE_L0EN | LANEENABLE_CLEN);
> +
> + /* start */
> + tc358764_write(ctx, PPI_STARTPPI, PPI_START_FUNCTION);
> + tc358764_write(ctx, DSI_STARTDSI, DSI_RX_START);
> +
> + /* configure video path */
> + tc358764_write(ctx, VP_CTRL, VP_CTRL_VSDELAY(15) | VP_CTRL_RGB888(1) |
> + VP_CTRL_EVTMODE(1) | VP_CTRL_HSPOL | VP_CTRL_VSPOL);
Could we specify somewhere that
> +
> + /* reset PHY */
> + tc358764_write(ctx, LV_PHY0, LV_PHY0_RST(1) |
> + LV_PHY0_PRBS_ON(4) | LV_PHY0_IS(2) | LV_PHY0_ND(6));
> + tc358764_write(ctx, LV_PHY0, LV_PHY0_PRBS_ON(4) | LV_PHY0_IS(2) |
> + LV_PHY0_ND(6));
> +
> + /* reset bridge */
> + tc358764_write(ctx, SYS_RST, SYS_RST_LCD);
> +
> + /* set bit order */
> + tc358764_write(ctx, LV_MX0003, LV_MX(LVI_R0, LVI_R1, LVI_R2, LVI_R3));
> + tc358764_write(ctx, LV_MX0407, LV_MX(LVI_R4, LVI_R7, LVI_R5, LVI_G0));
> + tc358764_write(ctx, LV_MX0811, LV_MX(LVI_G1, LVI_G2, LVI_G6, LVI_G7));
> + tc358764_write(ctx, LV_MX1215, LV_MX(LVI_G3, LVI_G4, LVI_G5, LVI_B0));
> + tc358764_write(ctx, LV_MX1619, LV_MX(LVI_B6, LVI_B7, LVI_B1, LVI_B2));
> + tc358764_write(ctx, LV_MX2023, LV_MX(LVI_B3, LVI_B4, LVI_B5, LVI_L0));
> + tc358764_write(ctx, LV_MX2427, LV_MX(LVI_HS, LVI_VS, LVI_DE, LVI_R6));
> + tc358764_write(ctx, LV_CFG, LV_CFG_CLKPOL2 | LV_CFG_CLKPOL1 |
> + LV_CFG_LVEN);
> +
> + return 0;
> +}
> +
> +static void tc358764_reset(struct tc358764 *ctx)
> +{
> + msleep(20);
> + gpiod_set_value(ctx->gpio_reset, 0);
> + msleep(20);
> + gpiod_set_value(ctx->gpio_reset, 1);
> + msleep(40);
> +}
> +
> +static void tc358764_poweroff(struct tc358764 *ctx)
> +{
> + int ret;
> +
> + tc358764_reset(ctx);
> +
> + drm_panel_disable(ctx->panel);
> + msleep(40);
> +
> + ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
> + if (ret < 0)
> + dev_err(ctx->dev, "error disabling regulators (%d)\n", ret);
> +}
> +
> +static int tc358764_get_modes(struct drm_connector *connector)
> +{
> + struct tc358764 *ctx = connector_to_tc358764(connector);
> +
> + if (ctx->panel && ctx->panel->funcs && ctx->panel->funcs->get_modes)
> + return ctx->panel->funcs->get_modes(ctx->panel);
> +
> + return 0;
> +}
> +
> +static const
> +struct drm_connector_helper_funcs tc358764_connector_helper_funcs = {
> + .get_modes = tc358764_get_modes,
> +};
> +
> +static const struct drm_connector_funcs tc358764_connector_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .destroy = drm_connector_cleanup,
> + .reset = drm_atomic_helper_connector_reset,
> + .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> +};
> +
> +static void tc358764_disable(struct drm_bridge *bridge)
> +{
> + struct tc358764 *ctx = bridge_to_tc358764(bridge);
> +
> + tc358764_poweroff(ctx);
> +}
> +
> +static void tc358764_pre_enable(struct drm_bridge *bridge)
> +{
> + struct tc358764 *ctx = bridge_to_tc358764(bridge);
> + int ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies),
> + ctx->supplies);
> + if (ret < 0)
> + dev_err(ctx->dev, "error enabling regulators (%d)\n", ret);
> +
> + tc358764_reset(ctx);
> + tc358764_init(ctx);
> +}
> +
> +static void tc358764_enable(struct drm_bridge *bridge)
> +{
> + struct tc358764 *ctx = bridge_to_tc358764(bridge);
> + int ret;
> +
> + drm_panel_prepare(ctx->panel);
> +
> + ret = drm_panel_enable(ctx->panel);
> + if (ret < 0)
> + pr_err("panel enable failed\n");
> +
> + msleep(40);
> +}
> +
> +static int tc358764_attach(struct drm_bridge *bridge)
> +{
> + struct tc358764 *ctx = bridge_to_tc358764(bridge);
> + struct drm_device *drm = bridge->dev;
> + int ret;
> +
> + if (!bridge->encoder) {
> + DRM_ERROR("Encoder not found\n");
> + return -ENODEV;
> + }
> +
> + ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
> + ret = drm_connector_init(drm, &ctx->connector,
> + &tc358764_connector_funcs,
> + DRM_MODE_CONNECTOR_LVDS);
> + if (ret) {
> + DRM_ERROR("Failed to initialize connector\n");
> + return ret;
> + }
> +
> + drm_connector_helper_add(&ctx->connector,
> + &tc358764_connector_helper_funcs);
> +
> + drm_mode_connector_attach_encoder(&ctx->connector, bridge->encoder);
> +
> + if (ctx->panel)
> + drm_panel_attach(ctx->panel, &ctx->connector);
> +
> + drm_atomic_helper_connector_reset(&ctx->connector);
> + drm_connector_register(&ctx->connector);
> +
> + return 0;
> +}
> +
> +static const struct drm_bridge_funcs tc358764_bridge_funcs = {
> + .disable = tc358764_disable,
> + .enable = tc358764_enable,
> + .pre_enable = tc358764_pre_enable,
> + .attach = tc358764_attach,
> +};
> +
> +static struct device_node *tc358764_of_find_panel_node(struct device *dev)
> +{
> + struct device_node *np, *ep;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, 0);
> + if (!ep) {
> + pr_err("faile to get endpoint\n");
> + return NULL;
> + }
> +
> + np = of_graph_get_remote_port_parent(ep);
> +
> + return np;
> +}
> +
> +static int tc358764_parse_dt(struct tc358764 *ctx)
> +{
> + struct device *dev = ctx->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *lvds;
> +
> + ctx->gpio_reset = devm_gpiod_get_from_of_node(dev, np, "reset", 0,
> + GPIOD_OUT_LOW,
> + "tc358764-reset");
> + if (IS_ERR(ctx->gpio_reset)) {
> + dev_err(dev, "no reset GPIO pin provided\n");
> + return PTR_ERR(ctx->gpio_reset);
> + }
> +
> + lvds = tc358764_of_find_panel_node(ctx->dev);
> + if (!lvds) {
> + dev_err(dev, "cannot find panel node\n");
> + return -EINVAL;
> + }
> +
> + ctx->panel = of_drm_find_panel(lvds);
> + if (!ctx->panel) {
> + dev_err(dev, "panel not registered\n");
> + return -EPROBE_DEFER;
> + }
> +
> + return 0;
> +}
> +
> +static int tc358764_configure_regulators(struct tc358764 *ctx)
> +{
> + int i, ret;
> +
> + for (i = 0; i < ARRAY_SIZE(ctx->supplies); ++i)
> + ctx->supplies[i].supply = tc358764_supplies[i];
> +
> + ret = devm_regulator_bulk_get(ctx->dev, ARRAY_SIZE(ctx->supplies),
> + ctx->supplies);
> + if (ret < 0)
> + dev_err(ctx->dev, "failed to get regulators: %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int tc358764_probe(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + struct tc358764 *ctx;
> + int ret;
> +
> + ctx = devm_kzalloc(dev, sizeof(struct tc358764), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> +
> + mipi_dsi_set_drvdata(dsi, ctx);
> +
> + ctx->dev = dev;
> +
> + dsi->lanes = 4;
> + dsi->format = MIPI_DSI_FMT_RGB888;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST
> + | MIPI_DSI_MODE_VIDEO_AUTO_VERT;
if you use the mipi_dsi_device_transfer() helper, I guess you'd need to
add the LPM flag here.
Looks good to me otherwise. Once the DT port issue is concluded:
Reviewed-by: Archit Taneja <architt@codeaurora.org>
> +
> + ret = tc358764_parse_dt(ctx);
> + if (ret < 0)
> + return ret;
> +
> + ret = tc358764_configure_regulators(ctx);
> + if (ret < 0)
> + return ret;
> +
> + ctx->bridge.funcs = &tc358764_bridge_funcs;
> + ctx->bridge.of_node = dev->of_node;
> +
> + drm_bridge_add(&ctx->bridge);
> +
> + ret = mipi_dsi_attach(dsi);
> + if (ret < 0) {
> + drm_bridge_remove(&ctx->bridge);
> + dev_err(dev, "failed to attach dsi\n");
> + }
> +
> + return ret;
> +}
> +
> +static int tc358764_remove(struct mipi_dsi_device *dsi)
> +{
> + struct tc358764 *ctx = mipi_dsi_get_drvdata(dsi);
> +
> + tc358764_poweroff(ctx);
> +
> + mipi_dsi_detach(dsi);
> + drm_bridge_remove(&ctx->bridge);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id tc358764_of_match[] = {
> + { .compatible = "toshiba,tc358764" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, tc358764_of_match);
> +
> +static struct mipi_dsi_driver tc358764_driver = {
> + .probe = tc358764_probe,
> + .remove = tc358764_remove,
> + .driver = {
> + .name = "tc358764",
> + .owner = THIS_MODULE,
> + .of_match_table = tc358764_of_match,
> + },
> +};
> +module_mipi_dsi_driver(tc358764_driver);
> +
> +MODULE_AUTHOR("Andrzej Hajda <a.hajda@samsung.com>");
> +MODULE_AUTHOR("Maciej Purski <m.purski@samsung.com>");
> +MODULE_DESCRIPTION("MIPI-DSI based Driver for TC358764 DSI/LVDS Bridge");
> +MODULE_LICENSE("GPL v2");
>
^ permalink raw reply
* [PATCH 00/12] introduce support for early platform drivers
From: Geert Uytterhoeven @ 2018-05-31 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+7=NGj57k=E5GAuDmW7Uu_YkHJXf8jSyc_ad3r1op4yA@mail.gmail.com>
Hi Rob,
On Thu, May 31, 2018 at 12:36 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, May 30, 2018 at 2:40 PM, Michael Turquette
> <mturquette@baylibre.com> wrote:
>> Quoting Rob Herring (2018-05-14 06:20:57)
>>> On Mon, May 14, 2018 at 6:38 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>> > 2018-05-11 22:13 GMT+02:00 Rob Herring <robh+dt@kernel.org>:
>>> >> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>> >>> This series is a follow-up to the RFC[1] posted a couple days ago.
>>> >>>
>>> >>> NOTE: this series applies on top of my recent patches[2] that move the previous
>>> >>> implementation of early platform devices to arch/sh.
>>> >>>
>>> >>> Problem:
>>> >>>
>>> >>> Certain class of devices, such as timers, certain clock drivers and irq chip
>>> >>> drivers need to be probed early in the boot sequence. The currently preferred
>>> >>> approach is using one of the OF_DECLARE() macros. This however does not create
>>> >>> a platform device which has many drawbacks - such as not being able to use
>>> >>> devres routines, dev_ log functions or no way of deferring the init OF function
>>> >>> if some other resources are missing.
>>> >>
>>> >> I skimmed though this and it doesn't look horrible (how's that for
>>> >> positive feedback? ;) ). But before going into the details, I think
>>> >> first there needs to be agreement this is the right direction.
>>> >>
>>> >> The question does remain though as to whether this class of devices
>>> >> should be platform drivers. They can't be modules. They can't be
>>> >> hotplugged. Can they be runtime-pm enabled? So the advantage is ...
>>> >>
>>> >
>>> > The main (but not the only) advantage for drivers that can both be
>>> > platform drivers and OF_DECLARE drivers is that we get a single entry
>>> > point and can reuse code without resorting to checking if (!dev). It
>>> > results in more consistent code base. Another big advantage is
>>> > consolidation of device tree and machine code for SoC drivers used in
>>> > different boards of which some are still using board files and others
>>> > are defined in DT (see: DaVinci).
>>> >
>>> >> I assume that the clock maintainers had some reason to move clocks to
>>> >> be platform drivers. It's just not clear to me what that was.
>>> >>
>>> >>> For drivers that use both platform drivers and OF_DECLARE the situation is even
>>> >>> more complicated as the code needs to take into account that there can possibly
>>> >>> be no struct device present. For a specific use case that we're having problems
>>> >>> with, please refer to the recent DaVinci common-clock conversion patches and
>>> >>> the nasty workaround that this problem implies[3].
>>> >>
>>> >> So devm_kzalloc will work with this solution? Why did we need
>>> >> devm_kzalloc in the first place? The clocks can never be removed and
>>> >> cleaning up on error paths is kind of pointless. The system would be
>>> >> hosed, right?
>>> >>
>>> >
>>> > It depends - not all clocks are necessary for system to boot.
>>>
>>> That doesn't matter. You have a single driver for all/most of the
>>> clocks, so the driver can't be removed.
>>
>> -ECANOFWORMS
>>
>> A couple of quick rebuttals, but I imagine we're going to disagree on
>> the platform_driver thing as a matter of taste no matter what...
>
> It's really more should the clocksource, clockevents and primary
> interrupt controller be drivers. Let's get agreement on that first. If
> yes, then it probably does make sense that their dependencies are
> drivers too. If not, then making only the dependencies drivers doesn't
> seem right to me.
Yes, they should all be drivers.
Assuming clocksources, clockevents, or primary interrupt controllers are
special, and thus forcing everyone to use OF_DECLARE for the whole
subsystem, doesn't fly everywhere.
Clockevents and interrupt controllers can have a module clock.
All three can be part of a PM Domain, which requires a struct device to
be handled properly.
>> 1) There should be multiple clk drivers in a properly modeled system.
>> Some folks still incorrectly put all clocks in a system into a single
>> driver because That's How We Used To Do It, and some systems (simpler
>> ones) really only have a single clock generator IP block.
>>
>> Excepting those two reasons above, we really should have separate
>> drivers for clocks controlled by the PMIC, for the (one or more) clock
>> generator blocks inside of the AP/SoC, and then even more for the
>> drivers that map to IP blocks that have their own clock gens.
>
> I agree those should be separate entities at least. But for a given
> h/w block, if you already have to use OF_DECLARE, why would you try to
> split that into OF_DECLARE and a driver? what advantage does putting
> non-boot essential clocks in a driver or transitioning to a driver get
> you?
You may want to split it because of dependencies. OF_DECLARE
doesn't handle EPROBE_DEFER, while some critical parts may be
needed early.
> And I've seen PMIC clocks could be inputs to the SoC's clock
> controller(s), so the dependencies get more complicated. Then does the
> PMIC driver and its dependencies need to be early drivers too?
Especially if there are clock loops, but that's something different.
Cfr. cs2000 in arch/arm64/boot/dts/renesas/salvator-common.dtsi, which
provides a clock from the main SoC, but also consumes a clock from the main
SoC. The latter is modeled in DT as a fixed-clock as a workaround.
>> Good examples of the latter are display controllers that generate their
>> own PLL and pixel clock. Or MMC controllers that have a
>> runtime-programmable clock divider. Examples of these are merged into
>> mainline.
>
> But those are drivers of types other than a clock controller that
> happen to register some clocks as well. I wasn't saying these cases
> can't or shouldn't be part of the driver model. Look at irqchips. We
> have some that use the driver model (e.g. every GPIO driver) and some
> that don't because there's no need (e.g. GIC).
There is a need for using the driver model for the GIC. On some platforms,
the GIC can be part of a clock and/or power domain.
For secondary GICs, that got fixed in commit 9c8edddfc9924cb4
("irqchip/gic: Add platform driver for non-root GICs that require RPM").
For primary GICs, it's still not fixed, so we have to live with
CLK_IS_CRITICAL, and rely on other critical devices in the same power
domain to avoid the power domain being powered off.
>> 2) Stephen and I wanted clock drivers to actually be represented in the
>> driver model. There were these gigantic clock drivers that exclusively
>> used CLK_OF_DECLARE and they just sort of floated out there in the
>> ether... no representation in sysfs, no struct device to map onto a
>> clock controller struct, etc.
>>
>> I'd be happy to hear why you think that platform_driver is a bad fit for
>> a device driver that generally manages memory-mapped system resources
>> that are part of the system glue and not really tied to a specific bus.
>> Sounds like a good fit to me.
>>
>> If platform_driver doesn't handle the early boot thing well, that tells
>> me that we have a problem to solve in platform_driver, not in the clk
>> subsystem or drivers.
>
> Doing things earlier is not the only way to solve the problems.
> Perhaps we need to figure out how to start things later. Maybe it's
> not feasible here, I don't know.
The fixed probe order imposed by OF_DECLARE() limits this: if your
OF_DECLARE() driver depends on something else, the latter must become an
early device.
If all subsystems would use real devices, EPROBE_DEFER would handle most of
it automatically.
Then, next step would be to avoid triggering EPROBE_DEFER, e.g. by
analyzing dependencies in DT...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 5/9] PM / Domains: dt: Allow power-domain property to be a list of specifiers
From: Viresh Kumar @ 2018-05-31 6:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-6-ulf.hansson@linaro.org>
On 29-05-18, 12:04, Ulf Hansson wrote:
> To be able to describe topologies where devices are partitioned across
> multiple power domains, let's extend the power-domain property to allow
> being a list of PM domain specifiers.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: devicetree at vger.kernel.org
> Suggested-by: Jon Hunter <jonathanh@nvidia.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 8/9] PM / Domains: Add support for multi PM domains per device to genpd
From: Ulf Hansson @ 2018-05-31 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a53f0970-22c4-444f-10e6-c115a21d05ea@nvidia.com>
[...]
>> +/**
>> + * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain.
>> + * @dev: Device to attach.
>
> Can you update the description of the above as well?
Yes, like below?
genpd_dev_pm_attach_by_id() - Associate a device with one of its PM domains.
@dev: The device used to lookup the PM domain.
Kind regards
Uffe
^ permalink raw reply
* [PATCH v2 4/9] PM / Domains: Drop unused parameter in genpd_allocate_dev_data()
From: Viresh Kumar @ 2018-05-31 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-5-ulf.hansson@linaro.org>
On 29-05-18, 12:04, Ulf Hansson wrote:
> The in-parameter struct generic_pm_domain *genpd to
> genpd_allocate_dev_data() is unused, so let's drop it.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 3/9] PM / Domains: Drop genpd as in-param for pm_genpd_remove_device()
From: Viresh Kumar @ 2018-05-31 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-4-ulf.hansson@linaro.org>
On 29-05-18, 12:04, Ulf Hansson wrote:
> There is no need to pass a genpd struct to pm_genpd_remove_device(), as we
> already have the information about the PM domain (genpd) through the device
> structure.
>
> Additionally, we don't allow to remove a PM domain from a device, other
> than the one it may have assigned to it, so really it does not make sense
> to have a separate in-param for it.
>
> For these reason, drop it and update the current only call to
> pm_genpd_remove_device() from amdgpu_acp.
>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Christian K?nig <christian.koenig@amd.com>
> Cc: David (ChunMing) Zhou <David1.Zhou@amd.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 8 ++++----
> drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c | 2 +-
> include/linux/pm_domain.h | 5 ++---
> 3 files changed, 7 insertions(+), 8 deletions(-)
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 1/6] ARM: dra762: hwmod: Add MCAN support
From: Tero Kristo @ 2018-05-31 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530155448.GH5705@atomide.com>
On 30/05/18 18:54, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [180530 15:44]:
>> On 30/05/18 18:28, Tony Lindgren wrote:
>>> * Tero Kristo <t-kristo@ti.com> [180530 15:18]:
>>>> For the OCP if part, I think that is still needed until we switch over to
>>>> full sysc driver. clkctrl_offs you probably also need because that is used
>>>> for mapping the omap_hwmod against a specific clkctrl clock. Those can be
>>>> only removed once we are done with hwmod (or figure out some other way to
>>>> assign the clkctrl clock to a hwmod.)
>>>
>>> Hmm might be worth testing. I thought your commit 70f05be32133
>>> ("ARM: OMAP2+: hwmod: populate clkctrl clocks for hwmods if available")
>>> already parses the clkctrl from dts?
>>
>> It maps the clkctrl clock to be used by hwmod, if those are available. We
>> didn't add any specific clock entries to DT for mapping the actual clkctrl
>> clock without the hwmod_data hints yet though, as that was deemed temporary
>> solution only due to transition to interconnect driver. I.e., you would need
>> something like this in DT for every device node:
>>
>> &uart3 {
>> clocks = <l4per_clkctrl UART3_CLK 0>;
>> clock-names = "clkctrl";
>> };
>>
>> ... which is currently not present.
>
> Hmm is that not the "fck" clkctrl clock we have already in
> the dts files for the interconnect target modules?
Oh okay, yeah, we could parse that one, but currently it is not done,
and is not present for everything either I believe.
> We can also use pdata callbacks to pass the clock node if
> needed. But I guess I don't quite still understand what we
> are missing :)
So, what is missing is the glue logic only from the hwmod codebase.
Right now this is not supported but should be relatively trivial thing
to add if we really want to do this.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH v2 2/9] PM / Domains: Drop __pm_genpd_add_device()
From: Viresh Kumar @ 2018-05-31 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-3-ulf.hansson@linaro.org>
On 29-05-18, 12:04, Ulf Hansson wrote:
> There are still a few non-DT existing users of genpd, however neither of
> them uses __pm_genpd_add_device(), hence let's drop it.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/base/power/domain.c | 10 ++++------
> include/linux/pm_domain.h | 14 +++-----------
> 2 files changed, 7 insertions(+), 17 deletions(-)
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v2 1/9] PM / Domains: Drop extern declarations of functions in pm_domain.h
From: Viresh Kumar @ 2018-05-31 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529100421.31022-2-ulf.hansson@linaro.org>
On 29-05-18, 12:04, Ulf Hansson wrote:
> Using "extern" to declare a function in a public header file is somewhat
> pointless, but also doesn't hurt. However, to make all the function
> declarations in pm_domain.h to be consistent, let's drop the use of
> "extern".
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> include/linux/pm_domain.h | 51 ++++++++++++++++++---------------------
> 1 file changed, 23 insertions(+), 28 deletions(-)
Finally.
I wanted to do that earlier as checkpatch complained non stop about
such declarations :)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCHv8 3/3] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Hean-Loong, Ong @ 2018-05-31 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527746514-3861-1-git-send-email-hean.loong.ong@intel.com>
From: Ong Hean Loong <hean.loong.ong@intel.com>
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong Hean Loong <hean.loong.ong@intel.com>
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile | 9 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 95 ++++++++++++++++
drivers/gpu/drm/ivip/intel_vip_core.c | 163 ++++++++++++++++++++++++++++
drivers/gpu/drm/ivip/intel_vip_drv.h | 52 +++++++++
drivers/gpu/drm/ivip/intel_vip_of.c | 193 +++++++++++++++++++++++++++++++++
8 files changed, 529 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7..cdc8e1a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff..c0fba1d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 0000000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+ tristate "Intel FGPA Video and Image Processing"
+ depends on DRM && OF
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select DRM_KMS_CMA_HELPER
+ help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only single
+ frame buffer is supported. Note that ACPI and X_86 architecture
+ is not supported for Arria10. If M is selected the module will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 0000000..cc55b04
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 0000000..46bb04c
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,95 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_encoder_slave.h>
+#include <drm/drm_plane_helper.h>
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .detect = intelvipfb_drm_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = intelvipfb_drm_connector_destroy,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int intelvipfb_drm_connector_get_modes(struct drm_connector *connector)
+{
+ struct drm_device *drm = connector->dev;
+ int count;
+
+ count = drm_add_modes_noedid(connector, drm->mode_config.max_width,
+ drm->mode_config.max_height);
+ drm_set_preferred_mode(connector, drm->mode_config.max_width,
+ drm->mode_config.max_height);
+ return count;
+}
+
+static const struct drm_connector_helper_funcs
+intelvipfb_drm_connector_helper_funcs = {
+ .get_modes = intelvipfb_drm_connector_get_modes,
+};
+
+struct drm_connector *
+intelvipfb_conn_setup(struct drm_device *drm)
+{
+ struct drm_connector *conn;
+ int ret;
+
+ conn = devm_kzalloc(drm->dev, sizeof(*conn), GFP_KERNEL);
+ if (IS_ERR(conn))
+ return NULL;
+
+ ret = drm_connector_init(drm, conn, &intelvipfb_drm_connector_funcs,
+ DRM_MODE_CONNECTOR_DisplayPort);
+ if (ret < 0) {
+ dev_err(drm->dev, "failed to initialize drm connector\n");
+ ret = -ENOMEM;
+ goto error_connector_cleanup;
+ }
+
+ conn->polled = 0;
+ drm_connector_helper_add(conn, &intelvipfb_drm_connector_helper_funcs);
+
+ return conn;
+
+error_connector_cleanup:
+ drm_connector_cleanup(conn);
+
+ return NULL;
+}
diff --git a/drivers/gpu/drm/ivip/intel_vip_core.c b/drivers/gpu/drm/ivip/intel_vip_core.c
new file mode 100644
index 0000000..a09e1ca
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_core.c
@@ -0,0 +1,163 @@
+/*
+ * intel_vip_core.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_fb_helper.h>
+#include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_plane_helper.h>
+#include <drm/drm_simple_kms_helper.h>
+#include <drm/drm_gem_framebuffer_helper.h>
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#include "intel_vip_drv.h"
+
+static void intelvipfb_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state)
+{
+ /*
+ * The frameinfo variable has to correspond to the size of the VIP Suite
+ * Frame Reader register 7 which will determine the maximum size used
+ * in this frameinfo
+ */
+
+ u32 frameinfo;
+ struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
+ void __iomem *base = priv->base;
+ struct drm_plane_state *state = pipe->plane.state;
+ dma_addr_t addr;
+
+ addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
+
+ dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
+
+ frameinfo =
+ readl(base + INTELVIPFB_FRAME_READER) & 0x00ffffff;
+ writel(frameinfo, base + INTELVIPFB_FRAME_INFO);
+ writel(addr, base + INTELVIPFB_FRAME_START);
+ /* Finally set the control register to 1 to start streaming */
+ writel(1, base + INTELVIPFB_CONTROL);
+}
+
+static void intelvipfb_disable(struct drm_simple_display_pipe *pipe)
+{
+ struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
+ void __iomem *base = priv->base;
+ /* set the control register to 0 to stop streaming */
+ writel(0, base + INTELVIPFB_CONTROL);
+}
+
+static const struct drm_mode_config_funcs intelvipfb_mode_config_funcs = {
+ .fb_create = drm_gem_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void intelvipfb_setup_mode_config(struct drm_device *drm)
+{
+ drm_mode_config_init(drm);
+ drm->mode_config.funcs = &intelvipfb_mode_config_funcs;
+}
+
+static int intelvipfb_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
+ struct drm_plane_state *plane_state)
+{
+ return drm_gem_fb_prepare_fb(&pipe->plane, plane_state);
+}
+
+
+static struct drm_simple_display_pipe_funcs fbpriv_funcs = {
+ .prepare_fb = intelvipfb_pipe_prepare_fb,
+ .enable = intelvipfb_enable,
+ .disable = intelvipfb_disable
+};
+
+int intelvipfb_probe(struct device *dev)
+{
+ int retval;
+ struct drm_device *drm;
+ struct intelvipfb_priv *fbpriv = dev_get_drvdata(dev);
+ struct drm_connector *connector;
+ u32 formats[] = {DRM_FORMAT_XRGB8888};
+
+ drm = fbpriv->drm;
+
+ drm->dev_private = fbpriv;
+
+ intelvipfb_setup_mode_config(drm);
+
+ connector = intelvipfb_conn_setup(drm);
+ if (!connector) {
+ dev_err(drm->dev, "Connector setup failed\n");
+ goto err_mode_config;
+ }
+
+ retval = drm_simple_display_pipe_init(drm, &fbpriv->pipe,
+ &fbpriv_funcs, formats,
+ ARRAY_SIZE(formats), NULL, connector);
+ if (retval < 0) {
+ dev_err(drm->dev, "Cannot setup simple display pipe\n");
+ goto err_mode_config;
+ }
+
+ fbpriv->fbcma = drm_fbdev_cma_init(drm,
+ drm->mode_config.preferred_depth,
+ drm->mode_config.num_connector);
+
+ drm_mode_config_reset(drm);
+
+ drm_dev_register(drm, 0);
+
+ return retval;
+
+err_mode_config:
+
+ drm_mode_config_cleanup(drm);
+ return -ENODEV;
+}
+
+int intelvipfb_remove(struct device *dev)
+{
+ struct intelvipfb_priv *fbpriv = dev_get_drvdata(dev);
+ struct drm_device *drm = fbpriv->drm;
+
+ drm_dev_unregister(drm);
+
+ if (fbpriv->fbcma)
+ drm_fbdev_cma_fini(fbpriv->fbcma);
+
+ drm_mode_config_cleanup(drm);
+ drm_dev_unref(drm);
+
+ return 0;
+}
+
+MODULE_AUTHOR("Ong, Hean-Loong <hean.loong.ong@intel.com>");
+MODULE_DESCRIPTION("Intel VIP Frame Buffer II driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/ivip/intel_vip_drv.h b/drivers/gpu/drm/ivip/intel_vip_drv.h
new file mode 100644
index 0000000..0a3555d
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_drv.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2017 Intel Corporation.
+ *
+ * Intel Video and Image Processing(VIP) Frame Buffer II driver.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+#ifndef _INTEL_VIP_DRV_H
+#define _INTEL_VIP_DRV_H
+
+#define DRIVER_NAME "intelvipfb"
+#define BYTES_PER_PIXEL 4
+#define CRTC_NUM 1
+#define CONN_NUM 1
+
+/* control registers */
+#define INTELVIPFB_CONTROL 0
+#define INTELVIPFB_STATUS 0x4
+#define INTELVIPFB_INTERRUPT 0x8
+#define INTELVIPFB_FRAME_COUNTER 0xC
+#define INTELVIPFB_FRAME_DROP 0x10
+#define INTELVIPFB_FRAME_INFO 0x14
+#define INTELVIPFB_FRAME_START 0x18
+#define INTELVIPFB_FRAME_READER 0x1C
+
+int intelvipfb_probe(struct device *dev);
+int intelvipfb_remove(struct device *dev);
+int intelvipfb_setup_crtc(struct drm_device *drm);
+struct drm_connector *intelvipfb_conn_setup(struct drm_device *drm);
+
+struct intelvipfb_priv {
+ struct drm_simple_display_pipe pipe;
+ struct drm_fbdev_cma *fbcma;
+ struct drm_device *drm;
+ void __iomem *base;
+};
+
+#endif
diff --git a/drivers/gpu/drm/ivip/intel_vip_of.c b/drivers/gpu/drm/ivip/intel_vip_of.c
new file mode 100644
index 0000000..47302f9
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_of.c
@@ -0,0 +1,193 @@
+/*
+ * intel_vip_of.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+#include <drm/drm_fb_helper.h>
+#include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_of.h>
+#include <drm/drm_simple_kms_helper.h>
+
+#include <linux/component.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include "intel_vip_drv.h"
+
+DEFINE_DRM_GEM_CMA_FOPS(drm_fops);
+
+static void intelvipfb_lastclose(struct drm_device *drm)
+{
+ struct intelvipfb_priv *priv = drm->dev_private;
+
+ drm_fbdev_cma_restore_mode(priv->fbcma);
+}
+
+static struct drm_driver intelvipfb_drm = {
+ .driver_features =
+ DRIVER_MODESET | DRIVER_GEM |
+ DRIVER_PRIME | DRIVER_ATOMIC,
+ .gem_free_object_unlocked = drm_gem_cma_free_object,
+ .gem_vm_ops = &drm_gem_cma_vm_ops,
+ .dumb_create = drm_gem_cma_dumb_create,
+ .dumb_destroy = drm_gem_dumb_destroy,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_export = drm_gem_prime_export,
+ .gem_prime_import = drm_gem_prime_import,
+ .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+ .gem_prime_vmap = drm_gem_cma_prime_vmap,
+ .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
+ .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ .lastclose = intelvipfb_lastclose,
+ .name = DRIVER_NAME,
+ .date = "20170729",
+ .desc = "Intel FPGA VIP SUITE",
+ .major = 1,
+ .minor = 0,
+ .ioctls = NULL,
+ .patchlevel = 0,
+ .fops = &drm_fops,
+};
+
+/*
+ * Setting up information derived from OF Device Tree Nodes
+ * max-width, max-height, bits per pixel, memory port width
+ */
+
+static int intelvipfb_drm_setup(struct device *dev,
+ struct intelvipfb_priv *fbpriv)
+{
+ struct drm_device *drm = fbpriv->drm;
+ struct device_node *np = dev->of_node;
+ int mem_word_width;
+ int max_h, max_w;
+ int ret;
+
+ ret = of_property_read_u32(np, "altr,max-width", &max_w);
+ if (ret) {
+ dev_err(dev,
+ "Missing required parameter 'altr,max-width'");
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "altr,max-height", &max_h);
+ if (ret) {
+ dev_err(dev,
+ "Missing required parameter 'altr,max-height'");
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "altr,mem-port-width", &mem_word_width);
+ if (ret) {
+ dev_err(dev, "Missing required parameter 'altr,mem-port-width '");
+ return ret;
+ }
+
+ if (!(mem_word_width >= 32 && mem_word_width % 32 == 0)) {
+ dev_err(dev,
+ "mem-word-width is set to %i. must be >= 32 and multiple of 32.",
+ mem_word_width);
+ return -ENODEV;
+ }
+
+ drm->mode_config.min_width = 640;
+ drm->mode_config.min_height = 480;
+ drm->mode_config.max_width = max_w;
+ drm->mode_config.max_height = max_h;
+ drm->mode_config.preferred_depth = 32;
+
+ return 0;
+}
+
+static int intelvipfb_of_probe(struct platform_device *pdev)
+{
+ int retval;
+ struct resource *reg_res;
+ struct intelvipfb_priv *fbpriv;
+ struct device *dev = &pdev->dev;
+ struct drm_device *drm;
+
+ fbpriv = devm_kzalloc(dev, sizeof(*fbpriv), GFP_KERNEL);
+ if (!fbpriv)
+ return -ENOMEM;
+
+ /*setup DRM */
+ drm = drm_dev_alloc(&intelvipfb_drm, dev);
+ if (IS_ERR(drm))
+ return PTR_ERR(drm);
+
+ retval = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
+ if (retval)
+ return -ENODEV;
+
+ fbpriv->drm = drm;
+
+ reg_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!reg_res)
+ return -ENOMEM;
+
+ fbpriv->base = devm_ioremap_resource(dev, reg_res);
+
+ if (IS_ERR(fbpriv->base)) {
+ dev_err(dev, "devm_ioremap_resource failed\n");
+ retval = PTR_ERR(fbpriv->base);
+ return -ENOMEM;
+ }
+
+ intelvipfb_drm_setup(dev, fbpriv);
+
+ dev_set_drvdata(dev, fbpriv);
+
+ return intelvipfb_probe(dev);
+}
+
+static int intelvipfb_of_remove(struct platform_device *pdev)
+{
+ return intelvipfb_remove(&pdev->dev);
+}
+
+/*
+ * The name vip-frame-buffer-2.0 is derived from
+ * http://www.altera.com/literature/ug/ug_vip.pdf
+ * frame buffer IP cores section 14
+ */
+
+static const struct of_device_id intelvipfb_of_match[] = {
+ { .compatible = "altr,vip-frame-buffer-2.0" },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, intelvipfb_of_match);
+
+static struct platform_driver intelvipfb_driver = {
+ .probe = intelvipfb_of_probe,
+ .remove = intelvipfb_of_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = intelvipfb_of_match,
+ },
+};
+
+module_platform_driver(intelvipfb_driver);
--
1.7.1
^ permalink raw reply related
* [PATCH] drm/bridge/synopsys: dw-hdmi: fix dw_hdmi_setup_rx_sense
From: Archit Taneja @ 2018-05-31 6:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527673438-20643-1-git-send-email-narmstrong@baylibre.com>
On Wednesday 30 May 2018 03:13 PM, Neil Armstrong wrote:
> The dw_hdmi_setup_rx_sense exported function should not use struct device
> to recover the dw-hdmi context using drvdata, but take struct dw_hdmi
> directly like other exported functions.
>
> This caused a regression using Meson DRM on S905X since v4.17-rc1 :
Reviewed-by: Archit Taneja <architt@codeaurora.org>
>
> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> [...]
> CPU: 0 PID: 124 Comm: irq/32-dw_hdmi_ Not tainted 4.17.0-rc7 #2
> Hardware name: Libre Technology CC (DT)
> [...]
> pc : osq_lock+0x54/0x188
> lr : __mutex_lock.isra.0+0x74/0x530
> [...]
> Process irq/32-dw_hdmi_ (pid: 124, stack limit = 0x00000000adf418cb)
> Call trace:
> osq_lock+0x54/0x188
> __mutex_lock_slowpath+0x10/0x18
> mutex_lock+0x30/0x38
> __dw_hdmi_setup_rx_sense+0x28/0x98
> dw_hdmi_setup_rx_sense+0x10/0x18
> dw_hdmi_top_thread_irq+0x2c/0x50
> irq_thread_fn+0x28/0x68
> irq_thread+0x10c/0x1a0
> kthread+0x128/0x130
> ret_from_fork+0x10/0x18
> Code: 34000964 d00050a2 51000484 9135c042 (f864d844)
> ---[ end trace 945641e1fbbc07da ]---
> note: irq/32-dw_hdmi_[124] exited with preempt_count 1
> genirq: exiting task "irq/32-dw_hdmi_" (124) is an active IRQ thread (irq 32)
>
> Fixes: eea034af90c6 ("drm/bridge/synopsys: dw-hdmi: don't clobber drvdata")
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Koen Kooi <koen@dominion.thruhere.net>
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 15 ++++-----------
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> include/drm/bridge/dw_hdmi.h | 2 +-
> 3 files changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index ec8d000..3c136f2b 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -2077,7 +2077,7 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
> return ret;
> }
>
> -void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> {
> mutex_lock(&hdmi->mutex);
>
> @@ -2103,13 +2103,6 @@ void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
> }
> mutex_unlock(&hdmi->mutex);
> }
> -
> -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense)
> -{
> - struct dw_hdmi *hdmi = dev_get_drvdata(dev);
> -
> - __dw_hdmi_setup_rx_sense(hdmi, hpd, rx_sense);
> -}
> EXPORT_SYMBOL_GPL(dw_hdmi_setup_rx_sense);
>
> static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> @@ -2145,9 +2138,9 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
> */
> if (intr_stat &
> (HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_IH_PHY_STAT0_HPD)) {
> - __dw_hdmi_setup_rx_sense(hdmi,
> - phy_stat & HDMI_PHY_HPD,
> - phy_stat & HDMI_PHY_RX_SENSE);
> + dw_hdmi_setup_rx_sense(hdmi,
> + phy_stat & HDMI_PHY_HPD,
> + phy_stat & HDMI_PHY_RX_SENSE);
>
> if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
> cec_notifier_set_phys_addr(hdmi->cec_notifier,
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index a393095..c9ad456 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -529,7 +529,7 @@ static irqreturn_t dw_hdmi_top_thread_irq(int irq, void *dev_id)
> if (stat & HDMITX_TOP_INTR_HPD_RISE)
> hpd_connected = true;
>
> - dw_hdmi_setup_rx_sense(dw_hdmi->dev, hpd_connected,
> + dw_hdmi_setup_rx_sense(dw_hdmi->hdmi, hpd_connected,
> hpd_connected);
>
> drm_helper_hpd_irq_event(dw_hdmi->encoder.dev);
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index dd2a8cf..ccb5aa8 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -151,7 +151,7 @@ struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
> struct drm_encoder *encoder,
> const struct dw_hdmi_plat_data *plat_data);
>
> -void dw_hdmi_setup_rx_sense(struct device *dev, bool hpd, bool rx_sense);
> +void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense);
>
> void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate);
> void dw_hdmi_audio_enable(struct dw_hdmi *hdmi);
>
^ permalink raw reply
* [PATCH] ARM:drm ivip Intel FPGA Video and Image Processing Suite
From: Hean-Loong, Ong @ 2018-05-31 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527745851-3339-1-git-send-email-hean.loong.ong@intel.com>
From: Ong Hean Loong <hean.loong.ong@intel.com>
Driver for Intel FPGA Video and Image Processing Suite Frame Buffer II.
The driver only supports the Intel Arria10 devkit and its variants.
This driver can be either loaded staticlly or in modules.
The OF device tree binding is located at:
Documentation/devicetree/bindings/display/altr,vip-fb2.txt
Signed-off-by: Ong Hean Loong <hean.loong.ong@intel.com>
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/ivip/Kconfig | 14 +++
drivers/gpu/drm/ivip/Makefile | 9 ++
drivers/gpu/drm/ivip/intel_vip_conn.c | 95 ++++++++++++++++
drivers/gpu/drm/ivip/intel_vip_core.c | 163 ++++++++++++++++++++++++++++
drivers/gpu/drm/ivip/intel_vip_drv.h | 52 +++++++++
drivers/gpu/drm/ivip/intel_vip_of.c | 193 +++++++++++++++++++++++++++++++++
8 files changed, 529 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index deeefa7..cdc8e1a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -204,6 +204,8 @@ source "drivers/gpu/drm/nouveau/Kconfig"
source "drivers/gpu/drm/i915/Kconfig"
+source "drivers/gpu/drm/ivip/Kconfig"
+
config DRM_VGEM
tristate "Virtual GEM provider"
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 50093ff..c0fba1d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/
obj-$(CONFIG_DRM_MGA) += mga/
obj-$(CONFIG_DRM_I810) += i810/
obj-$(CONFIG_DRM_I915) += i915/
+obj-$(CONFIG_DRM_IVIP) += ivip/
obj-$(CONFIG_DRM_MGAG200) += mgag200/
obj-$(CONFIG_DRM_VC4) += vc4/
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
diff --git a/drivers/gpu/drm/ivip/Kconfig b/drivers/gpu/drm/ivip/Kconfig
new file mode 100644
index 0000000..1d08b90
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Kconfig
@@ -0,0 +1,14 @@
+config DRM_IVIP
+ tristate "Intel FGPA Video and Image Processing"
+ depends on DRM && OF
+ select DRM_GEM_CMA_HELPER
+ select DRM_KMS_HELPER
+ select DRM_KMS_FB_HELPER
+ select DRM_KMS_CMA_HELPER
+ help
+ Choose this option if you have an Intel FPGA Arria 10 system
+ and above with an Intel Display Port IP. This does not support
+ legacy Intel FPGA Cyclone V display port. Currently only single
+ frame buffer is supported. Note that ACPI and X_86 architecture
+ is not supported for Arria10. If M is selected the module will be
+ called ivip.
diff --git a/drivers/gpu/drm/ivip/Makefile b/drivers/gpu/drm/ivip/Makefile
new file mode 100644
index 0000000..cc55b04
--- /dev/null
+++ b/drivers/gpu/drm/ivip/Makefile
@@ -0,0 +1,9 @@
+#
+# Makefile for the drm device driver. This driver provides support for the
+# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
+
+ccflags-y := -Iinclude/drm
+
+obj-$(CONFIG_DRM_IVIP) += ivip.o
+ivip-objs := intel_vip_of.o intel_vip_core.o \
+ intel_vip_conn.o
diff --git a/drivers/gpu/drm/ivip/intel_vip_conn.c b/drivers/gpu/drm/ivip/intel_vip_conn.c
new file mode 100644
index 0000000..46bb04c
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_conn.c
@@ -0,0 +1,95 @@
+/*
+ * intel_vip_conn.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_encoder_slave.h>
+#include <drm/drm_plane_helper.h>
+
+static enum drm_connector_status
+intelvipfb_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+ return connector_status_connected;
+}
+
+static void intelvipfb_drm_connector_destroy(struct drm_connector *connector)
+{
+ drm_connector_unregister(connector);
+ drm_connector_cleanup(connector);
+}
+
+static const struct drm_connector_funcs intelvipfb_drm_connector_funcs = {
+ .reset = drm_atomic_helper_connector_reset,
+ .detect = intelvipfb_drm_connector_detect,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .destroy = intelvipfb_drm_connector_destroy,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int intelvipfb_drm_connector_get_modes(struct drm_connector *connector)
+{
+ struct drm_device *drm = connector->dev;
+ int count;
+
+ count = drm_add_modes_noedid(connector, drm->mode_config.max_width,
+ drm->mode_config.max_height);
+ drm_set_preferred_mode(connector, drm->mode_config.max_width,
+ drm->mode_config.max_height);
+ return count;
+}
+
+static const struct drm_connector_helper_funcs
+intelvipfb_drm_connector_helper_funcs = {
+ .get_modes = intelvipfb_drm_connector_get_modes,
+};
+
+struct drm_connector *
+intelvipfb_conn_setup(struct drm_device *drm)
+{
+ struct drm_connector *conn;
+ int ret;
+
+ conn = devm_kzalloc(drm->dev, sizeof(*conn), GFP_KERNEL);
+ if (IS_ERR(conn))
+ return NULL;
+
+ ret = drm_connector_init(drm, conn, &intelvipfb_drm_connector_funcs,
+ DRM_MODE_CONNECTOR_DisplayPort);
+ if (ret < 0) {
+ dev_err(drm->dev, "failed to initialize drm connector\n");
+ ret = -ENOMEM;
+ goto error_connector_cleanup;
+ }
+
+ conn->polled = 0;
+ drm_connector_helper_add(conn, &intelvipfb_drm_connector_helper_funcs);
+
+ return conn;
+
+error_connector_cleanup:
+ drm_connector_cleanup(conn);
+
+ return NULL;
+}
diff --git a/drivers/gpu/drm/ivip/intel_vip_core.c b/drivers/gpu/drm/ivip/intel_vip_core.c
new file mode 100644
index 0000000..a09e1ca
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_core.c
@@ -0,0 +1,163 @@
+/*
+ * intel_vip_core.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+
+#include <drm/drmP.h>
+#include <drm/drm_atomic.h>
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_crtc_helper.h>
+#include <drm/drm_fb_helper.h>
+#include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_plane_helper.h>
+#include <drm/drm_simple_kms_helper.h>
+#include <drm/drm_gem_framebuffer_helper.h>
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#include "intel_vip_drv.h"
+
+static void intelvipfb_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state)
+{
+ /*
+ * The frameinfo variable has to correspond to the size of the VIP Suite
+ * Frame Reader register 7 which will determine the maximum size used
+ * in this frameinfo
+ */
+
+ u32 frameinfo;
+ struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
+ void __iomem *base = priv->base;
+ struct drm_plane_state *state = pipe->plane.state;
+ dma_addr_t addr;
+
+ addr = drm_fb_cma_get_gem_addr(state->fb, state, 0);
+
+ dev_info(pipe->plane.dev->dev, "Address 0x%x\n", addr);
+
+ frameinfo =
+ readl(base + INTELVIPFB_FRAME_READER) & 0x00ffffff;
+ writel(frameinfo, base + INTELVIPFB_FRAME_INFO);
+ writel(addr, base + INTELVIPFB_FRAME_START);
+ /* Finally set the control register to 1 to start streaming */
+ writel(1, base + INTELVIPFB_CONTROL);
+}
+
+static void intelvipfb_disable(struct drm_simple_display_pipe *pipe)
+{
+ struct intelvipfb_priv *priv = pipe->plane.dev->dev_private;
+ void __iomem *base = priv->base;
+ /* set the control register to 0 to stop streaming */
+ writel(0, base + INTELVIPFB_CONTROL);
+}
+
+static const struct drm_mode_config_funcs intelvipfb_mode_config_funcs = {
+ .fb_create = drm_gem_fb_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void intelvipfb_setup_mode_config(struct drm_device *drm)
+{
+ drm_mode_config_init(drm);
+ drm->mode_config.funcs = &intelvipfb_mode_config_funcs;
+}
+
+static int intelvipfb_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
+ struct drm_plane_state *plane_state)
+{
+ return drm_gem_fb_prepare_fb(&pipe->plane, plane_state);
+}
+
+
+static struct drm_simple_display_pipe_funcs fbpriv_funcs = {
+ .prepare_fb = intelvipfb_pipe_prepare_fb,
+ .enable = intelvipfb_enable,
+ .disable = intelvipfb_disable
+};
+
+int intelvipfb_probe(struct device *dev)
+{
+ int retval;
+ struct drm_device *drm;
+ struct intelvipfb_priv *fbpriv = dev_get_drvdata(dev);
+ struct drm_connector *connector;
+ u32 formats[] = {DRM_FORMAT_XRGB8888};
+
+ drm = fbpriv->drm;
+
+ drm->dev_private = fbpriv;
+
+ intelvipfb_setup_mode_config(drm);
+
+ connector = intelvipfb_conn_setup(drm);
+ if (!connector) {
+ dev_err(drm->dev, "Connector setup failed\n");
+ goto err_mode_config;
+ }
+
+ retval = drm_simple_display_pipe_init(drm, &fbpriv->pipe,
+ &fbpriv_funcs, formats,
+ ARRAY_SIZE(formats), NULL, connector);
+ if (retval < 0) {
+ dev_err(drm->dev, "Cannot setup simple display pipe\n");
+ goto err_mode_config;
+ }
+
+ fbpriv->fbcma = drm_fbdev_cma_init(drm,
+ drm->mode_config.preferred_depth,
+ drm->mode_config.num_connector);
+
+ drm_mode_config_reset(drm);
+
+ drm_dev_register(drm, 0);
+
+ return retval;
+
+err_mode_config:
+
+ drm_mode_config_cleanup(drm);
+ return -ENODEV;
+}
+
+int intelvipfb_remove(struct device *dev)
+{
+ struct intelvipfb_priv *fbpriv = dev_get_drvdata(dev);
+ struct drm_device *drm = fbpriv->drm;
+
+ drm_dev_unregister(drm);
+
+ if (fbpriv->fbcma)
+ drm_fbdev_cma_fini(fbpriv->fbcma);
+
+ drm_mode_config_cleanup(drm);
+ drm_dev_unref(drm);
+
+ return 0;
+}
+
+MODULE_AUTHOR("Ong, Hean-Loong <hean.loong.ong@intel.com>");
+MODULE_DESCRIPTION("Intel VIP Frame Buffer II driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/ivip/intel_vip_drv.h b/drivers/gpu/drm/ivip/intel_vip_drv.h
new file mode 100644
index 0000000..0a3555d
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_drv.h
@@ -0,0 +1,52 @@
+/*
+ * Copyright (C) 2017 Intel Corporation.
+ *
+ * Intel Video and Image Processing(VIP) Frame Buffer II driver.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+#ifndef _INTEL_VIP_DRV_H
+#define _INTEL_VIP_DRV_H
+
+#define DRIVER_NAME "intelvipfb"
+#define BYTES_PER_PIXEL 4
+#define CRTC_NUM 1
+#define CONN_NUM 1
+
+/* control registers */
+#define INTELVIPFB_CONTROL 0
+#define INTELVIPFB_STATUS 0x4
+#define INTELVIPFB_INTERRUPT 0x8
+#define INTELVIPFB_FRAME_COUNTER 0xC
+#define INTELVIPFB_FRAME_DROP 0x10
+#define INTELVIPFB_FRAME_INFO 0x14
+#define INTELVIPFB_FRAME_START 0x18
+#define INTELVIPFB_FRAME_READER 0x1C
+
+int intelvipfb_probe(struct device *dev);
+int intelvipfb_remove(struct device *dev);
+int intelvipfb_setup_crtc(struct drm_device *drm);
+struct drm_connector *intelvipfb_conn_setup(struct drm_device *drm);
+
+struct intelvipfb_priv {
+ struct drm_simple_display_pipe pipe;
+ struct drm_fbdev_cma *fbcma;
+ struct drm_device *drm;
+ void __iomem *base;
+};
+
+#endif
diff --git a/drivers/gpu/drm/ivip/intel_vip_of.c b/drivers/gpu/drm/ivip/intel_vip_of.c
new file mode 100644
index 0000000..47302f9
--- /dev/null
+++ b/drivers/gpu/drm/ivip/intel_vip_of.c
@@ -0,0 +1,193 @@
+/*
+ * intel_vip_of.c -- Intel Video and Image Processing(VIP)
+ * Frame Buffer II driver
+ *
+ * This driver supports the Intel VIP Frame Reader component.
+ * More info on the hardware can be found in the Intel Video
+ * and Image Processing Suite User Guide at this address
+ * http://www.altera.com/literature/ug/ug_vip.pdf.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * Authors:
+ * Ong, Hean-Loong <hean.loong.ong@intel.com>
+ *
+ */
+#include <drm/drm_fb_helper.h>
+#include <drm/drm_fb_cma_helper.h>
+#include <drm/drm_gem_cma_helper.h>
+#include <drm/drm_of.h>
+#include <drm/drm_simple_kms_helper.h>
+
+#include <linux/component.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include "intel_vip_drv.h"
+
+DEFINE_DRM_GEM_CMA_FOPS(drm_fops);
+
+static void intelvipfb_lastclose(struct drm_device *drm)
+{
+ struct intelvipfb_priv *priv = drm->dev_private;
+
+ drm_fbdev_cma_restore_mode(priv->fbcma);
+}
+
+static struct drm_driver intelvipfb_drm = {
+ .driver_features =
+ DRIVER_MODESET | DRIVER_GEM |
+ DRIVER_PRIME | DRIVER_ATOMIC,
+ .gem_free_object_unlocked = drm_gem_cma_free_object,
+ .gem_vm_ops = &drm_gem_cma_vm_ops,
+ .dumb_create = drm_gem_cma_dumb_create,
+ .dumb_destroy = drm_gem_dumb_destroy,
+ .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+ .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .gem_prime_export = drm_gem_prime_export,
+ .gem_prime_import = drm_gem_prime_import,
+ .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+ .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
+ .gem_prime_vmap = drm_gem_cma_prime_vmap,
+ .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
+ .gem_prime_mmap = drm_gem_cma_prime_mmap,
+ .lastclose = intelvipfb_lastclose,
+ .name = DRIVER_NAME,
+ .date = "20170729",
+ .desc = "Intel FPGA VIP SUITE",
+ .major = 1,
+ .minor = 0,
+ .ioctls = NULL,
+ .patchlevel = 0,
+ .fops = &drm_fops,
+};
+
+/*
+ * Setting up information derived from OF Device Tree Nodes
+ * max-width, max-height, bits per pixel, memory port width
+ */
+
+static int intelvipfb_drm_setup(struct device *dev,
+ struct intelvipfb_priv *fbpriv)
+{
+ struct drm_device *drm = fbpriv->drm;
+ struct device_node *np = dev->of_node;
+ int mem_word_width;
+ int max_h, max_w;
+ int ret;
+
+ ret = of_property_read_u32(np, "altr,max-width", &max_w);
+ if (ret) {
+ dev_err(dev,
+ "Missing required parameter 'altr,max-width'");
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "altr,max-height", &max_h);
+ if (ret) {
+ dev_err(dev,
+ "Missing required parameter 'altr,max-height'");
+ return ret;
+ }
+
+ ret = of_property_read_u32(np, "altr,mem-port-width", &mem_word_width);
+ if (ret) {
+ dev_err(dev, "Missing required parameter 'altr,mem-port-width '");
+ return ret;
+ }
+
+ if (!(mem_word_width >= 32 && mem_word_width % 32 == 0)) {
+ dev_err(dev,
+ "mem-word-width is set to %i. must be >= 32 and multiple of 32.",
+ mem_word_width);
+ return -ENODEV;
+ }
+
+ drm->mode_config.min_width = 640;
+ drm->mode_config.min_height = 480;
+ drm->mode_config.max_width = max_w;
+ drm->mode_config.max_height = max_h;
+ drm->mode_config.preferred_depth = 32;
+
+ return 0;
+}
+
+static int intelvipfb_of_probe(struct platform_device *pdev)
+{
+ int retval;
+ struct resource *reg_res;
+ struct intelvipfb_priv *fbpriv;
+ struct device *dev = &pdev->dev;
+ struct drm_device *drm;
+
+ fbpriv = devm_kzalloc(dev, sizeof(*fbpriv), GFP_KERNEL);
+ if (!fbpriv)
+ return -ENOMEM;
+
+ /*setup DRM */
+ drm = drm_dev_alloc(&intelvipfb_drm, dev);
+ if (IS_ERR(drm))
+ return PTR_ERR(drm);
+
+ retval = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
+ if (retval)
+ return -ENODEV;
+
+ fbpriv->drm = drm;
+
+ reg_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!reg_res)
+ return -ENOMEM;
+
+ fbpriv->base = devm_ioremap_resource(dev, reg_res);
+
+ if (IS_ERR(fbpriv->base)) {
+ dev_err(dev, "devm_ioremap_resource failed\n");
+ retval = PTR_ERR(fbpriv->base);
+ return -ENOMEM;
+ }
+
+ intelvipfb_drm_setup(dev, fbpriv);
+
+ dev_set_drvdata(dev, fbpriv);
+
+ return intelvipfb_probe(dev);
+}
+
+static int intelvipfb_of_remove(struct platform_device *pdev)
+{
+ return intelvipfb_remove(&pdev->dev);
+}
+
+/*
+ * The name vip-frame-buffer-2.0 is derived from
+ * http://www.altera.com/literature/ug/ug_vip.pdf
+ * frame buffer IP cores section 14
+ */
+
+static const struct of_device_id intelvipfb_of_match[] = {
+ { .compatible = "altr,vip-frame-buffer-2.0" },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, intelvipfb_of_match);
+
+static struct platform_driver intelvipfb_driver = {
+ .probe = intelvipfb_of_probe,
+ .remove = intelvipfb_of_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = intelvipfb_of_match,
+ },
+};
+
+module_platform_driver(intelvipfb_driver);
--
1.7.1
^ permalink raw reply related
* Regression in Linux next again
From: Naresh Kamboju @ 2018-05-31 5:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+G9fYvff4_9XH8Y4CTadexb2WGV+rAd29Jdo4ztBxqFXKbt5Q@mail.gmail.com>
On 30 May 2018 at 20:23, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> On 30 May 2018 at 20:03, Mark Brown <broonie@kernel.org> wrote:
>> On Wed, May 30, 2018 at 04:03:15PM +0200, Maciej Purski wrote:
>>
>>> I'm afraid, I have no idea, how to fix it quickly. You can revert it and
>>> in the next version I'll fix the build error and split the last patch even
>>> more, so we could perform a more precise bisection. I'd be grateful if you
>>> could push it on your test coupled branch and Tony could test it again before
>>> merging it with next again.
>>
>> Yeah, if we could get testing from Tony first that'd be ideal.
>
> Linux next 4.17.0-rc7-next-20180529 boot failed on x15 device.
> Manually reproduced boot failed problem on x15 device.
> The qemu_arm32 boots successfully.
>
> Ref bug:
> LKFT: linux-next: Boot failed on beagle board x15
> https://bugs.linaro.org/show_bug.cgi?id=3863
This bug still happening on 4.17.0-rc7-next-20180530 on beagle board x15.
Linux version 4.17.0-rc7-next-20180530 (buildslave at x86-64-07) (gcc version
6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP Wed May 30 12:38:23 UTC 2018
- Naresh
^ permalink raw reply
* [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-31 5:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPftrzwLMSDeTBBxG-nvpsriBuPEwQAViTcE3DYRYsnzmg@mail.gmail.com>
On 30-05-18, 14:32, Krzysztof Kozlowski wrote:
> OK, I see the possibility although it is still far away from use
> cases. You cannot hotplug booting CPU (CPU0) on Exynos kernels. It
> never worked. Strictly speaking - offlining will work. But bringing it
> online will likely hang the system.
True and I used the following out of tree patch for a long time for my
dual A15 exynos to make hotplug work.
https://git.linaro.org/people/vireshk/backup/linux.git/commit/?h=bkp/exynos/hotplug&id=aab8a906a70b8f1fb15a4b7bd2ee27e6dcabf79d
--
viresh
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add missing CPU clocks to secondary CPUs on Exynos542x
From: Viresh Kumar @ 2018-05-31 5:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530164922.31851-1-krzk@kernel.org>
On 30-05-18, 18:49, Krzysztof Kozlowski wrote:
> Secondary CPUs should have the same information in DeviceTree as booting
> CPU from both correctness point of view and for possible hotplug
> scenarios.
>
> Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> ---
> arch/arm/boot/dts/exynos5420-cpus.dtsi | 6 ++++++
> arch/arm/boot/dts/exynos5422-cpus.dtsi | 8 +++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
Nice.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v3 5/5] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
From: djw at t-chip.com.cn @ 2018-05-31 5:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527737273-8387-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.
This special pin can now be reference as <&gpio_mute 0>, thanks
to the gpio-syscon driver, which makes writing regulator-gpio possible.
If the signal voltage changes, the io domain needs to change
correspondingly.
To use this feature, the following options are required in kernel config:
- CONFIG_GPIO_SYSCON=y
- CONFIG_POWER_AVS=y
- CONFIG_ROCKCHIP_IODOMAIN=y
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v3:
- Use <&gpio_mute 0> instead of <&gpio_mute 1> to refer to the GPIO_MUTE pin.
Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts
Changes in v1:
- Split into small patches
- Sort dts properties in sdmmc node
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b983abd..25c1111 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -41,6 +41,19 @@
vin-supply = <&vcc_io>;
};
+ vcc_sdio: sdmmcio-regulator {
+ compatible = "regulator-gpio";
+ gpios = <&gpio_mute 0 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1
+ 3300000 0x0>;
+ regulator-name = "vcc_sdio";
+ regulator-type = "voltage";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -213,7 +226,7 @@
vccio1-supply = <&vcc_io>;
vccio2-supply = <&vcc18_emmc>;
- vccio3-supply = <&vcc_io>;
+ vccio3-supply = <&vcc_sdio>;
vccio4-supply = <&vcc_18>;
vccio5-supply = <&vcc_io>;
vccio6-supply = <&vcc_io>;
@@ -242,7 +255,12 @@
max-frequency = <150000000>;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc0_clk &sdmmc0_cmd &sdmmc0_dectn &sdmmc0_bus4>;
+ sd-uhs-sdr12;
+ sd-uhs-sdr25;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vcc_sdio>;
status = "okay";
};
@@ -277,3 +295,7 @@
&usb_host0_ohci {
status = "okay";
};
+
+&gpio_mute {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v9 01/15] ARM: Add Krait L2 register accessor functions
From: Sricharan R @ 2018-05-31 4:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <152769571081.144038.4314499217001219157@swboyd.mtv.corp.google.com>
Hi Stephen,
On 5/30/2018 9:25 PM, Stephen Boyd wrote:
> Quoting Sricharan R (2018-05-24 22:40:11)
>> Hi Bjorn,
>>
>> On 5/24/2018 11:09 PM, Bjorn Andersson wrote:
>>> On Tue 06 Mar 06:38 PST 2018, Sricharan R wrote:
>>>
>>>> From: Stephen Boyd <sboyd@codeaurora.org>
>>>>
>>>> Krait CPUs have a handful of L2 cache controller registers that
>>>> live behind a cp15 based indirection register. First you program
>>>> the indirection register (l2cpselr) to point the L2 'window'
>>>> register (l2cpdr) at what you want to read/write. Then you
>>>> read/write the 'window' register to do what you want. The
>>>> l2cpselr register is not banked per-cpu so we must lock around
>>>> accesses to it to prevent other CPUs from re-pointing l2cpdr
>>>> underneath us.
>>>>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Russell King <linux@arm.linux.org.uk>
>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>>>
>>> This should have your signed-off-by here as well.
>>>
>>
>> ok.
>>
>>> Apart from that:
>>>
>>> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>
>>
>
> Will these patches come around again? I'll do a quick sweep on them
> today but I expect them to be resent.
Sure, i will have to resend them again, fixing couple of Bjorn's
minor comments. Will address your comments that you would give
as well along with that.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ 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