* RE: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a compatibility string to bindings
From: Ashish Kumar @ 2019-08-05 9:08 UTC (permalink / raw)
To: broonie@kernel.org
Cc: devicetree@vger.kernel.org, Han Xu, bbrezillon@kernel.org,
Kuldeep Singh, linux-mtd@lists.infradead.org, Rob Herring,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CA+EcR23hhD2=abMtNGDoW1LtXSE4qfjTy1uzU7sgrbi7W=KSbw@mail.gmail.com>
> -----Original Message-----
> From: Han Xu <xhnjupt@gmail.com>
> Sent: Thursday, August 1, 2019 8:53 PM
> To: Rob Herring <robh@kernel.org>
> Cc: Ashish Kumar <ashish.kumar@nxp.com>; devicetree@vger.kernel.org;
> bbrezillon@kernel.org; Kuldeep Singh <kuldeep.singh@nxp.com>;
> broonie@kernel.org; linux-mtd@lists.infradead.org; linux-arm-
> kernel@lists.infradead.org
> Subject: [EXT] Re: [Patch v3 1/2] dt-bindings: spi: spi-fsl-qspi: Add ls2080a
> compatibility string to bindings
>
> Caution: EXT Email
>
> On Tue, Jul 9, 2019 at 3:09 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, 19 Jun 2019 16:41:53 +0530, Ashish Kumar wrote:
> > > There are 2 version of QSPI-IP, according to which controller
> > > registers sets can be big endian or little endian.There are some
> > > other minor changes like RX fifo depth etc.
> > >
> > > The big endian version uses driver compatible "fsl,ls1021a-qspi" and
> > > little endian version uses driver compatible "fsl,ls2080a-qspi"
> > >
> > > Signed-off-by: Kuldeep Singh <kuldeep.singh@nxp.com>
> > > Signed-off-by: Ashish Kumar <ashish.kumar@nxp.com>
> > > ---
> > > v3:
> > > Rebase to top
> > > v2:
> > > Convert to patch series and rebasing done on top of tree
> > >
> > > Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> >
> > Reviewed-by: Rob Herring <robh@kernel.org>
>
> Acked-by: Han Xu <han.xu@nxp.com>
Hello Mark,
Could you please send this patch[1] from your spi tree, It applies seamlessly on
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/
[1]: http://patchwork.ozlabs.org/patch/1118636/
Regards
Ashish
>
> >
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> > .infradead.org%2Fmailman%2Flistinfo%2Flinux-
> mtd%2F&data=02%7C01%7C
> >
> Ashish.Kumar%40nxp.com%7Ca172f045af714e408d0a08d716942751%7C686
> ea1d3bc
> >
> 2b4c6fa92cd99c5c301635%7C0%7C1%7C637002697881500159&sdata=f
> 8i1y4aa
> > k3gPnuXM3fD1xFPp4RB7GEWZ45%2BeWPOoNSA%3D&reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dma-mapping: fix page attributes for dma_mmap_*
From: Catalin Marinas @ 2019-08-05 9:10 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Shawn Anastasio, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, iommu, Paul Burton,
James Hogan, Will Deacon, linux-arm-kernel, Robin Murphy
In-Reply-To: <20190805080145.5694-2-hch@lst.de>
On Mon, Aug 05, 2019 at 11:01:44AM +0300, Christoph Hellwig wrote:
> All the way back to introducing dma_common_mmap we've defaulyed to mark
s/defaultyed/defaulted/
> the pages as uncached. But this is wrong for DMA coherent devices.
> Later on DMA_ATTR_WRITE_COMBINE also got incorrect treatment as that
> flag is only treated special on the alloc side for non-coherent devices.
>
> Introduce a new dma_pgprot helper that deals with the check for coherent
> devices so that only the remapping cases even reach arch_dma_mmap_pgprot
s/even/ever/
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 1d3f0b5a9940..bd2b039f43a6 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -14,9 +14,7 @@
> pgprot_t arch_dma_mmap_pgprot(struct device *dev, pgprot_t prot,
> unsigned long attrs)
> {
> - if (!dev_is_dma_coherent(dev) || (attrs & DMA_ATTR_WRITE_COMBINE))
> - return pgprot_writecombine(prot);
> - return prot;
> + return pgprot_writecombine(prot);
> }
For arm64:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
From: Krzysztof Kozlowski @ 2019-08-05 9:11 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Rutland, devicetree, Sascha Hauer,
linux-kernel@vger.kernel.org, Schrempf Frieder, Rob Herring,
NXP Linux Team, Pengutronix Kernel Team, Fabio Estevam,
linux-arm-kernel
In-Reply-To: <20190803154724.GS8870@X250.getinternet.no>
On Sat, 3 Aug 2019 at 17:47, Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Mon, Jul 29, 2019 at 07:20:07PM +0200, Krzysztof Kozlowski wrote:
> > Add support for i.MX6UL modules from Kontron Electronics GmbH (before
> > acquisition: Exceet Electronics) and evalkit boards based on it:
> >
> > 1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
> > (LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
> > 256 MB NAND and other interfaces,
> > 2. N6310 S: evalkit, w/wo eMMC, without display,
> > 3. N6310 S 43: evalkit with 4.3" display,
> > 4. N6310 S 50: evalkit with 5.0" display.
> >
> > This includes device nodes for unsupported displays (Admatec
> > T043C004800272T2A and T070P133T0S301).
>
> Do not include unsupported devices.
>
> >
> > The work is based on Exceet/Kontron source code (GPLv2) with numerous
> > changes:
> > 1. Reorganize files,
> > 2. Rename Exceet -> Kontron,
> > 3. Rename models/compatibles to match newest Kontron product naming,
> > 4. Fix coding style errors and adjust to device tree coding guidelines,
> > 5. Fix DTC warnings,
> > 6. Extend compatibles so eval boards inherit the SoM compatible,
> > 7. Use defines instead of GPIO and interrupt flag values,
> > 8. Use proper vendor compatible for Macronix SPI NOR,
> > 9. Sort nodes alphabetically.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> >
> > ---
> >
> > Changes since v2, after Fabio's review:
> > 1. Add "imx6ul" compatible to board name (that's what I understood from
> > review),
> > 2. Add vendor/device prefix to eeprom and document the compatible,
> > 3. Use "admatecde" as vendor compatible to avoid confusion with Admatec
> > AG in Switzerland (also making LCD panels),
> > 4. Use generic names for nodes,
> > 5. Use IRQ_TYPE_LEVEL_LOW,
> > 6. Move iomux to the end of files,
> > 7. Remove regulators node (include regulators in top level),
> > 8. Remove cpu clock-frequency,
> > 9. Other minor fixes pointed by Fabio.
> >
> > Changes since v1, after Frieder's review:
> > 1. Remove unneeded license notes,
> > 2. Add Kontron copyright (2018),
> > 3. Rename the files/models/compatibles to new naming - N6310,
> > 4. Remove unneeded CPU operating points override,
> > 5. Switch regulator nodes into simple children nodes without addresses
> > (so not simple bus),
> > 6. Use proper vendor compatible for Macronix SPI NOR.
> > ---
> > .../devicetree/bindings/arm/fsl.yaml | 4 +
> > .../devicetree/bindings/eeprom/at25.txt | 1 +
>
> Please make them two separate patches.
You mean split at25 change to separate patch? or split both - at25 and
fsl bindings - to separate patches?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* remove default fallbacks in dma_map_ops v2
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
Hi all,
we have a few places where the DMA mapping layer has non-trivial default
actions that are questionable and/or dangerous.
This series instead wires up the mmap, get_sgtable and get_required_mask
methods explicitly and cleans up some surrounding areas. This also means
we could get rid of the ARCH_NO_COHERENT_DMA_MMAP kconfig option, as we
now require a mmap method wired up, or in case of non-coherent dma-direct
the presence of the arch_dma_coherent_to_pfn hook. The only interesting
case is that the sound code also checked the ARCH_NO_COHERENT_DMA_MMAP
symbol in somewhat odd ways, so I'd like to see a review of the sound
situation before going forward with that patch.
Changes since v1:
- add a dma_can_mmap helper for alsa
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/7] dma-mapping: move the dma_get_sgtable API comments from arm to common code
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805091159.7826-1-hch@lst.de>
The comments are spot on and should be near the central API, not just
near a single implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 11 -----------
kernel/dma/mapping.c | 11 +++++++++++
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6774b03aa405..4410af33c5c4 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -877,17 +877,6 @@ static void arm_coherent_dma_free(struct device *dev, size_t size, void *cpu_add
__arm_dma_free(dev, size, cpu_addr, handle, attrs, true);
}
-/*
- * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
- * that the intention is to allow exporting memory allocated via the
- * coherent DMA APIs through the dma_buf API, which only accepts a
- * scattertable. This presents a couple of problems:
- * 1. Not all memory allocated via the coherent DMA APIs is backed by
- * a struct page
- * 2. Passing coherent DMA memory into the streaming APIs is not allowed
- * as we will try to flush the memory through a different alias to that
- * actually being used (and the flushes are redundant.)
- */
int arm_dma_get_sgtable(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t handle, size_t size,
unsigned long attrs)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index b945239621d8..4ceb5b9016d8 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -136,6 +136,17 @@ int dma_common_get_sgtable(struct device *dev, struct sg_table *sgt,
return ret;
}
+/*
+ * The whole dma_get_sgtable() idea is fundamentally unsafe - it seems
+ * that the intention is to allow exporting memory allocated via the
+ * coherent DMA APIs through the dma_buf API, which only accepts a
+ * scattertable. This presents a couple of problems:
+ * 1. Not all memory allocated via the coherent DMA APIs is backed by
+ * a struct page
+ * 2. Passing coherent DMA memory into the streaming APIs is not allowed
+ * as we will try to flush the memory through a different alias to that
+ * actually being used (and the flushes are redundant.)
+ */
int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/7] dma-mapping: explicitly wire up ->mmap and ->get_sgtable
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805091159.7826-1-hch@lst.de>
While the default ->mmap and ->get_sgtable implementations work for the
majority of our dma_map_ops impementations they are inherently safe
for others that don't use the page allocator or CMA and/or use their
own way of remapping not covered by the common code. So remove the
defaults if these methods are not wired up, but instead wire up the
default implementations for all safe instances.
Fixes: e1c7e324539a ("dma-mapping: always provide the dma_map_ops based implementation")
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/alpha/kernel/pci_iommu.c | 2 ++
arch/ia64/hp/common/sba_iommu.c | 2 ++
arch/ia64/sn/pci/pci_dma.c | 2 ++
arch/mips/jazz/jazzdma.c | 2 ++
arch/powerpc/kernel/dma-iommu.c | 2 ++
arch/powerpc/platforms/ps3/system-bus.c | 4 ++++
arch/powerpc/platforms/pseries/vio.c | 2 ++
arch/s390/pci/pci_dma.c | 2 ++
arch/x86/kernel/amd_gart_64.c | 2 ++
arch/x86/kernel/pci-calgary_64.c | 2 ++
drivers/iommu/amd_iommu.c | 2 ++
drivers/iommu/intel-iommu.c | 2 ++
kernel/dma/mapping.c | 20 ++++++++++++--------
13 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 242108439f42..7f1925a32c99 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -955,5 +955,7 @@ const struct dma_map_ops alpha_pci_ops = {
.map_sg = alpha_pci_map_sg,
.unmap_sg = alpha_pci_unmap_sg,
.dma_supported = alpha_pci_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
EXPORT_SYMBOL(alpha_pci_ops);
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index 3d24cc43385b..4c0ea6c2833d 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -2183,6 +2183,8 @@ const struct dma_map_ops sba_dma_ops = {
.map_sg = sba_map_sg_attrs,
.unmap_sg = sba_unmap_sg_attrs,
.dma_supported = sba_dma_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
void sba_dma_init(void)
diff --git a/arch/ia64/sn/pci/pci_dma.c b/arch/ia64/sn/pci/pci_dma.c
index b7d42e4edc1f..12ffb9c0d738 100644
--- a/arch/ia64/sn/pci/pci_dma.c
+++ b/arch/ia64/sn/pci/pci_dma.c
@@ -438,6 +438,8 @@ static struct dma_map_ops sn_dma_ops = {
.unmap_sg = sn_dma_unmap_sg,
.dma_supported = sn_dma_supported,
.get_required_mask = sn_dma_get_required_mask,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
void sn_dma_init(void)
diff --git a/arch/mips/jazz/jazzdma.c b/arch/mips/jazz/jazzdma.c
index 1804dc9d8136..a01e14955187 100644
--- a/arch/mips/jazz/jazzdma.c
+++ b/arch/mips/jazz/jazzdma.c
@@ -682,5 +682,7 @@ const struct dma_map_ops jazz_dma_ops = {
.sync_sg_for_device = jazz_dma_sync_sg_for_device,
.dma_supported = dma_direct_supported,
.cache_sync = arch_dma_cache_sync,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
EXPORT_SYMBOL(jazz_dma_ops);
diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
index a0879674a9c8..2f5a53874f6d 100644
--- a/arch/powerpc/kernel/dma-iommu.c
+++ b/arch/powerpc/kernel/dma-iommu.c
@@ -208,4 +208,6 @@ const struct dma_map_ops dma_iommu_ops = {
.sync_single_for_device = dma_iommu_sync_for_device,
.sync_sg_for_cpu = dma_iommu_sync_sg_for_cpu,
.sync_sg_for_device = dma_iommu_sync_sg_for_device,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
index 98410119c47b..70fcc9736a8c 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -700,6 +700,8 @@ static const struct dma_map_ops ps3_sb_dma_ops = {
.get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_sb_map_page,
.unmap_page = ps3_unmap_page,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
static const struct dma_map_ops ps3_ioc0_dma_ops = {
@@ -711,6 +713,8 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
.get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_ioc0_map_page,
.unmap_page = ps3_unmap_page,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
/**
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index 6601b9d404dc..3473eef7628c 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -605,6 +605,8 @@ static const struct dma_map_ops vio_dma_mapping_ops = {
.unmap_page = vio_dma_iommu_unmap_page,
.dma_supported = dma_iommu_dma_supported,
.get_required_mask = dma_iommu_get_required_mask,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
/**
diff --git a/arch/s390/pci/pci_dma.c b/arch/s390/pci/pci_dma.c
index 9e52d1527f71..03d8c1c9f82f 100644
--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -668,6 +668,8 @@ const struct dma_map_ops s390_pci_dma_ops = {
.unmap_sg = s390_dma_unmap_sg,
.map_page = s390_dma_map_pages,
.unmap_page = s390_dma_unmap_pages,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
/* dma_supported is unconditionally true without a callback */
};
EXPORT_SYMBOL_GPL(s390_pci_dma_ops);
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index a585ea6f686a..a65b4a9c7f87 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -678,6 +678,8 @@ static const struct dma_map_ops gart_dma_ops = {
.alloc = gart_alloc_coherent,
.free = gart_free_coherent,
.dma_supported = dma_direct_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
static void gart_iommu_shutdown(void)
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 9d4343aa481b..23fdec030c37 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -468,6 +468,8 @@ static const struct dma_map_ops calgary_dma_ops = {
.map_page = calgary_map_page,
.unmap_page = calgary_unmap_page,
.dma_supported = dma_direct_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
static inline void __iomem * busno_to_bbar(unsigned char num)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index b607a92791d3..2e74ad659985 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2722,6 +2722,8 @@ static const struct dma_map_ops amd_iommu_dma_ops = {
.map_sg = map_sg,
.unmap_sg = unmap_sg,
.dma_supported = amd_iommu_dma_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
static int init_reserved_iova_ranges(void)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index bdaed2da8a55..7505c5d9cf78 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3737,6 +3737,8 @@ static const struct dma_map_ops intel_dma_ops = {
.map_resource = intel_map_resource,
.unmap_resource = intel_unmap_resource,
.dma_supported = dma_direct_supported,
+ .mmap = dma_common_mmap,
+ .get_sgtable = dma_common_get_sgtable,
};
static inline int iommu_domain_cache_init(void)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 4ceb5b9016d8..cdb157cd70e7 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -153,11 +153,12 @@ int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
{
const struct dma_map_ops *ops = get_dma_ops(dev);
- if (!dma_is_direct(ops) && ops->get_sgtable)
- return ops->get_sgtable(dev, sgt, cpu_addr, dma_addr, size,
- attrs);
- return dma_common_get_sgtable(dev, sgt, cpu_addr, dma_addr, size,
- attrs);
+ if (dma_is_direct(ops))
+ return dma_common_get_sgtable(dev, sgt, cpu_addr, dma_addr,
+ size, attrs);
+ if (!ops->get_sgtable)
+ return -ENXIO;
+ return ops->get_sgtable(dev, sgt, cpu_addr, dma_addr, size, attrs);
}
EXPORT_SYMBOL(dma_get_sgtable_attrs);
@@ -221,9 +222,12 @@ int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
{
const struct dma_map_ops *ops = get_dma_ops(dev);
- if (!dma_is_direct(ops) && ops->mmap)
- return ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
- return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
+ if (dma_is_direct(ops))
+ return dma_common_mmap(dev, vma, cpu_addr, dma_addr, size,
+ attrs);
+ if (!ops->mmap)
+ return -ENXIO;
+ return ops->mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
}
EXPORT_SYMBOL(dma_mmap_attrs);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/7] dma-mapping: add a dma_can_mmap helper
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805091159.7826-1-hch@lst.de>
Add a helper to check if DMA allocations for a specific device can be
mapped to userspace using dma_mmap_*.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/linux/dma-mapping.h | 5 +++++
kernel/dma/mapping.c | 23 +++++++++++++++++++++++
2 files changed, 28 insertions(+)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index f7d1eea32c78..17271857be5d 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -462,6 +462,7 @@ int dma_get_sgtable_attrs(struct device *dev, struct sg_table *sgt,
int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs);
+bool dma_can_mmap(struct device *dev);
int dma_supported(struct device *dev, u64 mask);
int dma_set_mask(struct device *dev, u64 mask);
int dma_set_coherent_mask(struct device *dev, u64 mask);
@@ -552,6 +553,10 @@ static inline int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
{
return -ENXIO;
}
+static inline bool dma_can_mmap(struct device *dev)
+{
+ return false;
+}
static inline int dma_supported(struct device *dev, u64 mask)
{
return 0;
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index cdb157cd70e7..ab6aa355e1a0 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -203,6 +203,29 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
#endif /* !CONFIG_ARCH_NO_COHERENT_DMA_MMAP */
}
+/**
+ * dma_can_mmap - check if a given device supports dma_mmap_*
+ * @dev: device to check
+ *
+ * Returns %true if @dev supports dma_mmap_coherent() and dma_mmap_attrs() to
+ * map DMA allocations to userspace.
+ */
+bool dma_can_mmap(struct device *dev)
+{
+ const struct dma_map_ops *ops = get_dma_ops(dev);
+
+ if (IS_ENABLED(CONFIG_ARCH_NO_COHERENT_DMA_MMAP))
+ return false;
+
+ if (dma_is_direct(ops)) {
+ return dev_is_dma_coherent(dev) ||
+ IS_ENABLED(CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN);
+ }
+
+ return ops->mmap != NULL;
+}
+EXPORT_SYMBOL_GPL(dma_can_mmap);
+
/**
* dma_mmap_attrs - map a coherent DMA allocation into user space
* @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/7] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805091159.7826-1-hch@lst.de>
Replace the local hack with the dma_can_mmap helper to check if
a given device supports mapping DMA allocations to userspace.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
sound/core/pcm_native.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 703857aab00f..81c82c3ee8a2 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -220,12 +220,11 @@ static bool hw_support_mmap(struct snd_pcm_substream *substream)
{
if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
return false;
- /* architecture supports dma_mmap_coherent()? */
-#if defined(CONFIG_ARCH_NO_COHERENT_DMA_MMAP) || !defined(CONFIG_HAS_DMA)
+ if (!dma_can_mmap(substream->dma_buffer.dev.dev))
+ return false;
if (!substream->ops->mmap &&
substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
return false;
-#endif
return true;
}
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/7] m68knommu: add a pgprot_noncached stub
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805091159.7826-1-hch@lst.de>
Provide a pgprot_noncached like all the other nommu ports so that
common code can rely on it being able to be present. Note that this is
generally code that is not actually run on nommu, but at least we can
avoid nasty ifdefs by having a stub.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/m68k/include/asm/pgtable_no.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/m68k/include/asm/pgtable_no.h b/arch/m68k/include/asm/pgtable_no.h
index fc3a96c77bd8..06194c7ba151 100644
--- a/arch/m68k/include/asm/pgtable_no.h
+++ b/arch/m68k/include/asm/pgtable_no.h
@@ -29,6 +29,8 @@
#define PAGE_READONLY __pgprot(0)
#define PAGE_KERNEL __pgprot(0)
+#define pgprot_noncached(prot) (prot)
+
extern void paging_init(void);
#define swapper_pg_dir ((pgd_t *) 0)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 6/7] dma-mapping: remove ARCH_NO_COHERENT_DMA_MMAP
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805091159.7826-1-hch@lst.de>
Now that we never use a default ->mmap implementation, and non-coherent
architectures can control the presence of ->mmap support by enabling
ARCH_HAS_DMA_COHERENT_TO_PFN for the dma direct implementation there
is no need for a global config option to control the availability
of dma_common_mmap.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/Kconfig | 3 ---
arch/c6x/Kconfig | 1 -
arch/m68k/Kconfig | 1 -
arch/microblaze/Kconfig | 1 -
arch/parisc/Kconfig | 1 -
arch/sh/Kconfig | 1 -
arch/xtensa/Kconfig | 1 -
kernel/dma/mapping.c | 7 -------
8 files changed, 16 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index a7b57dd42c26..ec2834206d08 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -790,9 +790,6 @@ config COMPAT_32BIT_TIME
This is relevant on all 32-bit architectures, and 64-bit architectures
as part of compat syscall handling.
-config ARCH_NO_COHERENT_DMA_MMAP
- bool
-
config ARCH_NO_PREEMPT
bool
diff --git a/arch/c6x/Kconfig b/arch/c6x/Kconfig
index b4fb61c83494..e65e8d82442a 100644
--- a/arch/c6x/Kconfig
+++ b/arch/c6x/Kconfig
@@ -20,7 +20,6 @@ config C6X
select OF_EARLY_FLATTREE
select GENERIC_CLOCKEVENTS
select MODULES_USE_ELF_RELA
- select ARCH_NO_COHERENT_DMA_MMAP
select MMU_GATHER_NO_RANGE if MMU
config MMU
diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index c518d695c376..614b355ae338 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -8,7 +8,6 @@ config M68K
select ARCH_HAS_DMA_PREP_COHERENT if HAS_DMA && MMU && !COLDFIRE
select ARCH_HAS_SYNC_DMA_FOR_DEVICE if HAS_DMA
select ARCH_MIGHT_HAVE_PC_PARPORT if ISA
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_NO_PREEMPT if !COLDFIRE
select BINFMT_FLAT_ARGVP_ENVP_ON_STACK
select DMA_DIRECT_REMAP if HAS_DMA && MMU && !COLDFIRE
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index d411de05b628..632c9477a0f6 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -9,7 +9,6 @@ config MICROBLAZE
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARCH_MIGHT_HAVE_PC_PARPORT
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_WANT_IPC_PARSE_VERSION
select BUILDTIME_EXTABLE_SORT
select TIMER_OF
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 6d732e451071..e9dd88b7f81e 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -52,7 +52,6 @@ config PARISC
select GENERIC_SCHED_CLOCK
select HAVE_UNSTABLE_SCHED_CLOCK if SMP
select GENERIC_CLOCKEVENTS
- select ARCH_NO_COHERENT_DMA_MMAP
select CPU_NO_EFFICIENT_FFS
select NEED_DMA_MAP_STATE
select NEED_SG_DMA_LENGTH
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 6b1b5941b618..f356ee674d89 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -5,7 +5,6 @@ config SUPERH
select ARCH_HAS_PTE_SPECIAL
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_MIGHT_HAVE_PC_PARPORT
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select HAVE_PATA_PLATFORM
select CLKDEV_LOOKUP
select DMA_DECLARE_COHERENT
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index ebc135bda921..70653aed3005 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -5,7 +5,6 @@ config XTENSA
select ARCH_HAS_BINFMT_FLAT if !MMU
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
- select ARCH_NO_COHERENT_DMA_MMAP if !MMU
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_WANT_FRAME_POINTERS
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index ab6aa355e1a0..47765c96fe09 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -169,7 +169,6 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
{
-#ifndef CONFIG_ARCH_NO_COHERENT_DMA_MMAP
unsigned long user_count = vma_pages(vma);
unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long off = vma->vm_pgoff;
@@ -198,9 +197,6 @@ int dma_common_mmap(struct device *dev, struct vm_area_struct *vma,
return remap_pfn_range(vma, vma->vm_start, pfn + vma->vm_pgoff,
user_count << PAGE_SHIFT, vma->vm_page_prot);
-#else
- return -ENXIO;
-#endif /* !CONFIG_ARCH_NO_COHERENT_DMA_MMAP */
}
/**
@@ -214,9 +210,6 @@ bool dma_can_mmap(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
- if (IS_ENABLED(CONFIG_ARCH_NO_COHERENT_DMA_MMAP))
- return false;
-
if (dma_is_direct(ops)) {
return dev_is_dma_coherent(dev) ||
IS_ENABLED(CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 7/7] dma-mapping: provide a better default ->get_required_mask
From: Christoph Hellwig @ 2019-08-05 9:11 UTC (permalink / raw)
To: iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-kernel, linux-m68k, Robin Murphy,
linux-arm-kernel
In-Reply-To: <20190805091159.7826-1-hch@lst.de>
Most dma_map_ops instances are IOMMUs that work perfectly fine in 32-bits
of IOVA space, and the generic direct mapping code already provides its
own routines that is intelligent based on the amount of memory actually
present. Wire up the dma-direct routine for the ARM direct mapping code
as well, and otherwise default to the constant 32-bit mask. This way
we only need to override it for the occasional odd IOMMU that requires
64-bit IOVA support, or IOMMU drivers that are more efficient if they
can fall back to the direct mapping.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/mm/dma-mapping.c | 3 +++
arch/powerpc/platforms/ps3/system-bus.c | 7 ------
arch/x86/kernel/amd_gart_64.c | 1 +
kernel/dma/mapping.c | 30 +++++++++----------------
4 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 4410af33c5c4..9c9a23e5600d 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -14,6 +14,7 @@
#include <linux/list.h>
#include <linux/init.h>
#include <linux/device.h>
+#include <linux/dma-direct.h>
#include <linux/dma-mapping.h>
#include <linux/dma-noncoherent.h>
#include <linux/dma-contiguous.h>
@@ -192,6 +193,7 @@ const struct dma_map_ops arm_dma_ops = {
.sync_sg_for_cpu = arm_dma_sync_sg_for_cpu,
.sync_sg_for_device = arm_dma_sync_sg_for_device,
.dma_supported = arm_dma_supported,
+ .get_required_mask = dma_direct_get_required_mask,
};
EXPORT_SYMBOL(arm_dma_ops);
@@ -212,6 +214,7 @@ const struct dma_map_ops arm_coherent_dma_ops = {
.map_sg = arm_dma_map_sg,
.map_resource = dma_direct_map_resource,
.dma_supported = arm_dma_supported,
+ .get_required_mask = dma_direct_get_required_mask,
};
EXPORT_SYMBOL(arm_coherent_dma_ops);
diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
index 70fcc9736a8c..3542b7bd6a46 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -686,18 +686,12 @@ static int ps3_dma_supported(struct device *_dev, u64 mask)
return mask >= DMA_BIT_MASK(32);
}
-static u64 ps3_dma_get_required_mask(struct device *_dev)
-{
- return DMA_BIT_MASK(32);
-}
-
static const struct dma_map_ops ps3_sb_dma_ops = {
.alloc = ps3_alloc_coherent,
.free = ps3_free_coherent,
.map_sg = ps3_sb_map_sg,
.unmap_sg = ps3_sb_unmap_sg,
.dma_supported = ps3_dma_supported,
- .get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_sb_map_page,
.unmap_page = ps3_unmap_page,
.mmap = dma_common_mmap,
@@ -710,7 +704,6 @@ static const struct dma_map_ops ps3_ioc0_dma_ops = {
.map_sg = ps3_ioc0_map_sg,
.unmap_sg = ps3_ioc0_unmap_sg,
.dma_supported = ps3_dma_supported,
- .get_required_mask = ps3_dma_get_required_mask,
.map_page = ps3_ioc0_map_page,
.unmap_page = ps3_unmap_page,
.mmap = dma_common_mmap,
diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
index a65b4a9c7f87..d02662238b57 100644
--- a/arch/x86/kernel/amd_gart_64.c
+++ b/arch/x86/kernel/amd_gart_64.c
@@ -680,6 +680,7 @@ static const struct dma_map_ops gart_dma_ops = {
.dma_supported = dma_direct_supported,
.mmap = dma_common_mmap,
.get_sgtable = dma_common_get_sgtable,
+ .get_required_mask = dma_direct_get_required_mask,
};
static void gart_iommu_shutdown(void)
diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index 47765c96fe09..96599f39f67a 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -247,25 +247,6 @@ int dma_mmap_attrs(struct device *dev, struct vm_area_struct *vma,
}
EXPORT_SYMBOL(dma_mmap_attrs);
-static u64 dma_default_get_required_mask(struct device *dev)
-{
- u32 low_totalram = ((max_pfn - 1) << PAGE_SHIFT);
- u32 high_totalram = ((max_pfn - 1) >> (32 - PAGE_SHIFT));
- u64 mask;
-
- if (!high_totalram) {
- /* convert to mask just covering totalram */
- low_totalram = (1 << (fls(low_totalram) - 1));
- low_totalram += low_totalram - 1;
- mask = low_totalram;
- } else {
- high_totalram = (1 << (fls(high_totalram) - 1));
- high_totalram += high_totalram - 1;
- mask = (((u64)high_totalram) << 32) + 0xffffffff;
- }
- return mask;
-}
-
u64 dma_get_required_mask(struct device *dev)
{
const struct dma_map_ops *ops = get_dma_ops(dev);
@@ -274,7 +255,16 @@ u64 dma_get_required_mask(struct device *dev)
return dma_direct_get_required_mask(dev);
if (ops->get_required_mask)
return ops->get_required_mask(dev);
- return dma_default_get_required_mask(dev);
+
+ /*
+ * We require every DMA ops implementation to at least support a 32-bit
+ * DMA mask (and use bounce buffering if that isn't supported in
+ * hardware). As the direct mapping code has its own routine to
+ * actually report an optimal mask we default to 32-bit here as that
+ * is the right thing for most IOMMUs, and at least not actively
+ * harmful in general.
+ */
+ return DMA_BIT_MASK(32);
}
EXPORT_SYMBOL_GPL(dma_get_required_mask);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v1 05/16] drm/fsl-dcu: fix opencoded use of drm_panel_*
From: Stefan Agner @ 2019-08-05 9:16 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Neil Armstrong, David Airlie, Linus Walleij, dri-devel,
Andrzej Hajda, Thierry Reding, Laurent Pinchart,
Benjamin Gaignard, Fabio Estevam, Marek Vasut, Laurent Pinchart,
Joonyoung Shim, Vincent Abriou, Krzysztof Kozlowski,
Jonathan Hunter, Maxime Ripard, Kukjin Kim, linux-arm-kernel,
Philipp Zabel, NXP Linux Team, Pengutronix Kernel Team,
Jonas Karlman, Sascha Hauer, Alison Wang, Maarten Lankhorst,
Gwan-gyeong Mun, Inki Dae, Alexios Zavras, linux-samsung-soc,
linux-tegra, Thomas Gleixner, Sean Paul, Allison Randal,
Jernej Skrabec, Shawn Guo, Seung-Woo Kim, Kyungmin Park,
Daniel Vetter, Sam Ravnborg, Enrico Weigelt
In-Reply-To: <20190804201637.1240-6-sam@ravnborg.org>
On 2019-08-04 22:16, Sam Ravnborg wrote:
> Use drm_panel_get_modes() to access modes.
> This has a nice side effect to simplify the code.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Stefan Agner <stefan@agner.ch>
> Cc: Alison Wang <alison.wang@nxp.com>
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 10 +---------
> 1 file changed, 1 insertion(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index 279d83eaffc0..a92fd6c70b09 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -65,17 +65,9 @@ static const struct drm_connector_funcs
> fsl_dcu_drm_connector_funcs = {
> static int fsl_dcu_drm_connector_get_modes(struct drm_connector *connector)
> {
> struct fsl_dcu_drm_connector *fsl_connector;
> - int (*get_modes)(struct drm_panel *panel);
> - int num_modes = 0;
>
> fsl_connector = to_fsl_dcu_connector(connector);
> - if (fsl_connector->panel && fsl_connector->panel->funcs &&
> - fsl_connector->panel->funcs->get_modes) {
> - get_modes = fsl_connector->panel->funcs->get_modes;
> - num_modes = get_modes(fsl_connector->panel);
> - }
> -
> - return num_modes;
> + return drm_panel_get_modes(fsl_connector->panel);
Oh, that old code looks rather messy. Thanks for the simplification!
This behaves slightly different since it now returns -EINVAL or -ENOSYS,
but that is what we want.
Acked-by: Stefan Agner <stefan@agner.ch>
--
Stefan
> }
>
> static int fsl_dcu_drm_connector_mode_valid(struct drm_connector *connector,
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 03/12] crypto: exynos - use devm_platform_ioremap_resource() to simplify code
From: Krzysztof Kozlowski @ 2019-08-05 9:18 UTC (permalink / raw)
To: YueHaibing
Cc: heiko, gary.hook, clabbe.montjoie, jamie, linux-stm32,
jesper.nilsson, linux-samsung-soc@vger.kernel.org, herbert,
linux-arm-kernel, linux-rockchip, wens, agross, thomas.lendacky,
alexandre.torgue, antoine.tenart, linux-arm-msm, mripard,
linux-mediatek, lars.persson, matthias.bgg, linux-arm-kernel,
linux-kernel@vger.kernel.org, linux-crypto, mcoquelin.stm32,
kgene, davem
In-Reply-To: <20190802132809.8116-4-yuehaibing@huawei.com>
On Fri, 2 Aug 2019 at 15:31, YueHaibing <yuehaibing@huawei.com> wrote:
>
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/crypto/exynos-rng.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 07/16] drm/mxsfb: fix opencoded use of drm_panel_*
From: Stefan Agner @ 2019-08-05 9:20 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Neil Armstrong, David Airlie, Linus Walleij, dri-devel,
Andrzej Hajda, Thierry Reding, Laurent Pinchart,
Benjamin Gaignard, Fabio Estevam, Marek Vasut, Laurent Pinchart,
Joonyoung Shim, Vincent Abriou, Krzysztof Kozlowski,
Jonathan Hunter, Maxime Ripard, Kukjin Kim, linux-arm-kernel,
Philipp Zabel, NXP Linux Team, Pengutronix Kernel Team,
Jonas Karlman, Sascha Hauer, Alison Wang, Maarten Lankhorst,
Gwan-gyeong Mun, Inki Dae, Alexios Zavras, linux-samsung-soc,
linux-tegra, Thomas Gleixner, Sean Paul, Allison Randal,
Jernej Skrabec, Shawn Guo, Seung-Woo Kim, Kyungmin Park,
Daniel Vetter, Sam Ravnborg, Enrico Weigelt
In-Reply-To: <20190804201637.1240-8-sam@ravnborg.org>
On 2019-08-04 22:16, Sam Ravnborg wrote:
> Use the drm_panel_get_modes() function.
Looks good to me,
Acked-by: Stefan Agner <stefan@agner.ch>
--
Stefan
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Marek Vasut <marex@denx.de>
> Cc: Stefan Agner <stefan@agner.ch>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> drivers/gpu/drm/mxsfb/mxsfb_out.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> index 231d016c6f47..be36f4d6cc96 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
> @@ -30,7 +30,7 @@ static int mxsfb_panel_get_modes(struct
> drm_connector *connector)
> drm_connector_to_mxsfb_drm_private(connector);
>
> if (mxsfb->panel)
> - return mxsfb->panel->funcs->get_modes(mxsfb->panel);
> + return drm_panel_get_modes(mxsfb->panel);
>
> return 0;
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 265 boots: 17 failed, 184 passed with 64 offline (next-20190730)
From: Lee Jones @ 2019-08-05 9:20 UTC (permalink / raw)
To: Timur Tabi
Cc: Kernel Build Reports Mailman List, Jeffrey Hugo, Linus Walleij,
Lina Iyer, Stephen Boyd, Mark Brown, Bjorn Andersson, Linux ARM
In-Reply-To: <e974aa7e-98d4-1594-755b-6f57ab852cd7@kernel.org>
On Thu, 01 Aug 2019, Timur Tabi wrote:
> On 7/31/19 12:58 PM, Jeffrey Hugo wrote:
> >
> > static int gpiochip_alloc_valid_mask(struct gpio_chip *gc)
> > {
> > if (IS_ENABLED(CONFIG_OF_GPIO))
> > gc->need_valid_mask = of_gpio_need_valid_mask(gc);
> > if (!gc->need_valid_mask)
> > return 0;
>
> So this seems wrong on a system with OF and ACPI. It assumes that OF takes
> priority over ACPI if both are enabled, and that's not true in general. If
> anything, it's the other way around.
Device Tree has priority in the Linux Kernel. If the bootloader
provides both (which breaks SBBR and EBBR compliance by the way!),
then the kernel will choose DT.
I guess this is because DT is more fluid (much to the originator's
dismay I should imagine) and can be used to fix broken ACPI tables
which tend to be more of a permanent fixture.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/7] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*
From: Takashi Iwai @ 2019-08-05 9:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-m68k, linux-kernel, iommu, Robin Murphy,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190805091159.7826-5-hch@lst.de>
On Mon, 05 Aug 2019 11:11:56 +0200,
Christoph Hellwig wrote:
>
> Replace the local hack with the dma_can_mmap helper to check if
> a given device supports mapping DMA allocations to userspace.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> sound/core/pcm_native.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
> index 703857aab00f..81c82c3ee8a2 100644
> --- a/sound/core/pcm_native.c
> +++ b/sound/core/pcm_native.c
> @@ -220,12 +220,11 @@ static bool hw_support_mmap(struct snd_pcm_substream *substream)
> {
> if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
> return false;
> - /* architecture supports dma_mmap_coherent()? */
> -#if defined(CONFIG_ARCH_NO_COHERENT_DMA_MMAP) || !defined(CONFIG_HAS_DMA)
> + if (!dma_can_mmap(substream->dma_buffer.dev.dev))
> + return false;
> if (!substream->ops->mmap &&
> substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
> return false;
> -#endif
This won't work as expected, unfortunately. It's a bit tricky check,
since the driver may have its own mmap implementation via
substream->ops->mmap, and the dma_buffer.dev.dev might point to
another object depending on the dma_buffer.dev.type.
So please replace with something like below:
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -221,11 +221,10 @@ static bool hw_support_mmap(struct snd_pcm_substream *substream)
if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
return false;
/* architecture supports dma_mmap_coherent()? */
-#if defined(CONFIG_ARCH_NO_COHERENT_DMA_MMAP) || !defined(CONFIG_HAS_DMA)
if (!substream->ops->mmap &&
- substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV)
+ substream->dma_buffer.dev.type == SNDRV_DMA_TYPE_DEV &&
+ !dma_can_mmap(substream->dma_buffer.dev.dev))
return false;
-#endif
return true;
}
Thanks!
Takashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: next/master boot: 265 boots: 17 failed, 184 passed with 64 offline (next-20190730)
From: Lee Jones @ 2019-08-05 9:23 UTC (permalink / raw)
To: Mark Brown
Cc: Kernel Build Reports Mailman List, Linus Walleij, Lina Iyer,
Bjorn Andersson, Stephen Boyd, Timur Tabi, Linux ARM
In-Reply-To: <20190731103934.GA4369@sirena.org.uk>
> > So if OF and ACPI is activated at the same time (can that happen?)
>
> Not really. There is a stub DT used to pass ACPI to the kernel.
Right. I think it's a choice the kernel makes on boot. Both can be
provided, but the kernel will pick to run with one or the other.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64: dts: ls1028a: fix gpio nodes
From: Hui Song @ 2019-08-05 9:14 UTC (permalink / raw)
To: linux-devel
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
From: Song Hui <hui.song_1@nxp.com>
Update the nodes to include little-endian
property to be consistent with the hardware.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06..7ccbbfc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -277,33 +277,36 @@
};
gpio1: gpio@2300000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
reg = <0x0 0x2300000 0x0 0x10000>;
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio2: gpio@2310000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
reg = <0x0 0x2310000 0x0 0x10000>;
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
gpio3: gpio@2320000 {
- compatible = "fsl,qoriq-gpio";
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
reg = <0x0 0x2320000 0x0 0x10000>;
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
+ little-endian;
};
usb0: usb@3100000 {
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1] gpio: mpc8xxx: Add new platforms GPIO DT node description
From: Hui Song @ 2019-08-05 9:14 UTC (permalink / raw)
To: linux-devel
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
In-Reply-To: <20190805091432.9656-1-hui.song_1@nxp.com>
From: Song Hui <hui.song_1@nxp.com>
Update the NXP GPIO node dt-binding file for QorIQ and
Layerscape platforms, and add one more example with
ls1028a GPIO node.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index 69d4616..fbe6d75 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -28,7 +28,7 @@ gpio0: gpio@1100 {
Example of gpio-controller node for a ls2080a SoC:
gpio0: gpio@2300000 {
- compatible = "fsl,ls2080a-gpio", "fsl,qoriq-gpio";
+ compatible = "fsl,ls1028a-gpio","fsl,ls2080a-gpio", "fsl,qoriq-gpio";
reg = <0x0 0x2300000 0x0 0x10000>;
interrupts = <0 36 0x4>; /* Level high type */
gpio-controller;
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 11/18] dt-bindings: pinctrl: bcm2835: Add brcm, bcm2711 compatible
From: Linus Walleij @ 2019-08-05 9:30 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Ulf Hansson, Matthias Brugger, Scott Branden,
open list:GPIO SUBSYSTEM, Stephen Boyd, Ray Jui,
Michael Turquette, linux-mmc, Adrian Hunter, Rob Herring,
Eric Anholt, Florian Fainelli, bcm-kernel-feedback-list,
Linux ARM, Nicolas Saenz Julienne, linux-rpi-kernel
In-Reply-To: <1563776607-8368-2-git-send-email-wahrenst@gmx.net>
On Mon, Jul 22, 2019 at 8:23 AM Stefan Wahren <wahrenst@gmx.net> wrote:
> Add a new compatible for the BCM2711.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
(...)
> + "brcm,bcm2711-gpio" - BCM2711 compatible pinctrl
Completely uncontroversial so patch applied.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/18] ARM: Add minimal Raspberry Pi 4 support
From: Linus Walleij @ 2019-08-05 9:33 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, Ulf Hansson, Florian Fainelli, Scott Branden,
open list:GPIO SUBSYSTEM, Stephen Boyd, Ray Jui,
Michael Turquette, linux-mmc, Adrian Hunter, Rob Herring,
Eric Anholt, Matthias Brugger, bcm-kernel-feedback-list,
Linux ARM, Nicolas Saenz Julienne, linux-rpi-kernel
In-Reply-To: <319549e0-23b5-4a49-49ae-723da754f984@gmx.net>
On Sun, Jul 28, 2019 at 1:22 PM Stefan Wahren <wahrenst@gmx.net> wrote:
> any comments on the clk / pinctrl parts or do you just wait for Rob's Ack?
I'm just gonna apply it.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 04/16] drm/imx: fix opencoded use of drm_panel_*
From: Philipp Zabel @ 2019-08-05 9:34 UTC (permalink / raw)
To: Sam Ravnborg, dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Andrzej Hajda,
Laurent Pinchart, Benjamin Gaignard, Fabio Estevam, Marek Vasut,
Laurent Pinchart, Joonyoung Shim, Krzysztof Kozlowski,
Jonathan Hunter, Maxime Ripard, Kukjin Kim, Allison Randal,
NXP Linux Team, Pengutronix Kernel Team, Jonas Karlman,
Sascha Hauer, Alison Wang, Maarten Lankhorst, Gwan-gyeong Mun,
Inki Dae, Alexios Zavras, linux-samsung-soc, linux-tegra,
Sean Paul, linux-arm-kernel, Jernej Skrabec, Shawn Guo,
Seung-Woo Kim, Kyungmin Park, Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-5-sam@ravnborg.org>
On Sun, 2019-08-04 at 22:16 +0200, Sam Ravnborg wrote:
> Use the drm_panel_get_modes() function to get the modes.
>
> This patch leave one test for the function pointer:
> panel->funcs->get_modes
>
> This is used to check if the panel may have any modes.
> There is no direct replacement.
> We may be able to just check that drm_panel_get_modes() return > 0,
> but as this is not the same functionality it is left for later.
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 01/16] drm/bridge: tc358767: fix opencoded use of drm_panel_*
From: Philipp Zabel @ 2019-08-05 9:35 UTC (permalink / raw)
To: Sam Ravnborg, dri-devel, Thierry Reding
Cc: Neil Armstrong, David Airlie, Linus Walleij, Stefan Agner,
Andrzej Hajda, Laurent Pinchart, Benjamin Gaignard, Fabio Estevam,
Marek Vasut, Laurent Pinchart, Joonyoung Shim, Vincent Abriou,
Krzysztof Kozlowski, Jonathan Hunter, Maxime Ripard, Kukjin Kim,
Allison Randal, NXP Linux Team, Pengutronix Kernel Team,
Jonas Karlman, Sascha Hauer, Alison Wang, Maarten Lankhorst,
Gwan-gyeong Mun, Inki Dae, Alexios Zavras, linux-samsung-soc,
linux-tegra, Thomas Gleixner, Sean Paul, linux-arm-kernel,
Jernej Skrabec, Shawn Guo, Seung-Woo Kim, Kyungmin Park,
Daniel Vetter, Enrico Weigelt
In-Reply-To: <20190804201637.1240-2-sam@ravnborg.org>
On Sun, 2019-08-04 at 22:16 +0200, Sam Ravnborg wrote:
> Replace open coded version with call to drm_panel_get_modes().
>
> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
> Cc: Andrzej Hajda <a.hajda@samsung.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> Cc: Jonas Karlman <jonas@kwiboo.se>
> Cc: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/gpu/drm/bridge/tc358767.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c
> index 42f03a985ac0..cebc8e620820 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1312,7 +1312,7 @@ static int tc_connector_get_modes(struct drm_connector *connector)
> {
> struct tc_data *tc = connector_to_tc(connector);
> struct edid *edid;
> - unsigned int count;
> + int count;
This looks like it also fixes a potential bug ...
> int ret;
>
> ret = tc_get_display_props(tc);
> @@ -1321,11 +1321,9 @@ static int tc_connector_get_modes(struct drm_connector *connector)
> return 0;
> }
>
> - if (tc->panel && tc->panel->funcs && tc->panel->funcs->get_modes) {
> - count = tc->panel->funcs->get_modes(tc->panel);
> - if (count > 0)
... when .get_modes returns a negative value.
> - return count;
> - }
> + count = drm_panel_get_modes(tc->panel);
> + if (count > 0)
> + return count;
>
> edid = drm_get_edid(connector, &tc->aux.ddc);
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 12/18] pinctrl: bcm2835: Add support for BCM2711 pull-up functionality
From: Linus Walleij @ 2019-08-05 9:38 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, Ulf Hansson, Matthias Brugger, Scott Branden,
open list:GPIO SUBSYSTEM, Stephen Boyd, Ray Jui,
Michael Turquette, linux-mmc, Adrian Hunter, Rob Herring,
Eric Anholt, Florian Fainelli, bcm-kernel-feedback-list,
Linux ARM, Nicolas Saenz Julienne, linux-rpi-kernel
In-Reply-To: <1563776607-8368-3-git-send-email-wahrenst@gmx.net>
On Mon, Jul 22, 2019 at 8:24 AM Stefan Wahren <wahrenst@gmx.net> wrote:
> The BCM2711 has a new way of selecting the pull-up/pull-down setting
> for a GPIO pin. The registers used for the BCM2835, GP_PUD and
> GP_PUDCLKn0, are no longer connected. A new set of registers,
> GP_GPIO_PUP_PDN_CNTRL_REGx must be used. This commit will add
> a new compatible string "brcm,bcm2711-gpio" and the kernel
> driver will use it to select which method is used to select
> pull-up/pull-down.
>
> This patch based on a patch by Al Cooper which was intended for the
> BCM7211. This is a bugfixed and improved version.
>
> Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Patch applied.
I think I complained about some other version of this patch, this one
looks entirely acceptable.
Can we get rid of custom pull settings etc from the upstream device
trees so we don't set bad examples? I have a strong urge to
throw in a pr_warn() about any use of it.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: dts: amlogic: g12: add temperature sensor
From: guillaume La Roque @ 2019-08-05 9:41 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: devicetree, linux-pm, khilman, daniel.lezcano, linux-kernel,
linux-amlogic, linux-arm-kernel
In-Reply-To: <CAFBinCBYPiLgmTNk+7Db3EPSPePwbnAshCbomYPXWdse8i0oJw@mail.gmail.com>
hi Martin,
thanks for comments i will fix in v3.
guillaume
On 8/3/19 7:52 PM, Martin Blumenstingl wrote:
> Hi Guillaume,
>
> On Wed, Jul 31, 2019 at 5:36 PM Guillaume La Roque
> <glaroque@baylibre.com> wrote:
>> Add cpu and ddr temperature sensors for G12 Socs
>>
>> Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
> with the nit-pick below addressed:
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
>> ---
>> .../boot/dts/amlogic/meson-g12-common.dtsi | 22 +++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
>> index 06e186ca41e3..7f862a3490fb 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
>> @@ -1353,6 +1353,28 @@
>> };
>> };
>>
>> + cpu_temp: temperature-sensor@34800 {
>> + compatible = "amlogic,g12-cpu-thermal",
>> + "amlogic,g12-thermal";
>> + reg = <0x0 0x34800 0x0 0x50>;
>> + interrupts = <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&clkc CLKID_TS>;
>> + status = "okay";
> I believe nodes are enabled automatically if they don't have a status property
>
>> + #thermal-sensor-cells = <0>;
>> + amlogic,ao-secure = <&sec_AO>;
>> + };
>> +
>> + ddr_temp: temperature-sensor@34c00 {
>> + compatible = "amlogic,g12-ddr-thermal",
>> + "amlogic,g12-thermal";
>> + reg = <0x0 0x34c00 0x0 0x50>;
>> + interrupts = <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>;
>> + clocks = <&clkc CLKID_TS>;
>> + status = "okay";
> same here
>
>
> Martin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox