* [PATCH 2/4] ARM: multi_v7_defconfig: enable stm32 i2s support
From: Olivier Moysan @ 2019-09-02 16:00 UTC (permalink / raw)
To: alexandre.torgue, olof, horms+renesas, arnd, krzk, yannick.fertre,
tony, m.szyprowski, fabrice.gasnier, enric.balletbo,
linux-arm-kernel, linux-kernel, linux-stm32
Cc: olivier.moysan
In-Reply-To: <1567440041-19220-1-git-send-email-olivier.moysan@st.com>
Enable support for I2S on STM32MP1.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 929d13842171..02265e195e50 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -700,6 +700,7 @@ CONFIG_SND_SOC_SH4_FSI=m
CONFIG_SND_SOC_RCAR=m
CONFIG_SND_SOC_STI=m
CONFIG_SND_SOC_STM32_SAI=m
+CONFIG_SND_SOC_STM32_I2S=m
CONFIG_SND_SUN4I_CODEC=m
CONFIG_SND_SOC_TEGRA=m
CONFIG_SND_SOC_TEGRA20_I2S=m
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] ARM: multi_v7_defconfig: enable stm32 sai support
From: Olivier Moysan @ 2019-09-02 16:00 UTC (permalink / raw)
To: alexandre.torgue, olof, horms+renesas, arnd, krzk, yannick.fertre,
tony, m.szyprowski, fabrice.gasnier, enric.balletbo,
linux-arm-kernel, linux-kernel, linux-stm32
Cc: olivier.moysan
In-Reply-To: <1567440041-19220-1-git-send-email-olivier.moysan@st.com>
Enable support for SAI on STM32MP1.
Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index c5d37dfafe98..929d13842171 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -699,6 +699,7 @@ CONFIG_SND_SOC_ODROID=m
CONFIG_SND_SOC_SH4_FSI=m
CONFIG_SND_SOC_RCAR=m
CONFIG_SND_SOC_STI=m
+CONFIG_SND_SOC_STM32_SAI=m
CONFIG_SND_SUN4I_CODEC=m
CONFIG_SND_SOC_TEGRA=m
CONFIG_SND_SOC_TEGRA20_I2S=m
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH V2] arm: xen: mm: use __GPF_DMA32 for arm64
From: Christoph Hellwig @ 2019-09-02 15:57 UTC (permalink / raw)
To: Stefano Stabellini
Cc: jgross, Peng Fan, Catalin Marinas, linux@armlinux.org.uk,
Christoph Hellwig, Julien Grall, dl-linux-imx,
xen-devel@lists.xenproject.org, boris.ostrovsky, nd,
will@kernel.org, linux-arm-kernel@lists.infradead.org,
Robin Murphy
In-Reply-To: <alpine.DEB.2.21.1908301926500.21347@sstabellini-ThinkPad-T480s>
On Fri, Aug 30, 2019 at 07:40:42PM -0700, Stefano Stabellini wrote:
> + Juergen, Boris
>
> On Fri, 30 Aug 2019, Christoph Hellwig wrote:
> > Can we take a step back and figure out what we want to do here?
> >
> > AFAICS this function allocates memory for the swiotlb-xen buffer,
> > and that means it must be <= 32-bit addressable to satisfy the DMA API
> > guarantees. That means we generally want to use GFP_DMA32 everywhere
> > that exists, but on systems with odd zones we might want to dip into
> > GFP_DMA. This also means swiotlb-xen doesn't actually do the right
> > thing on x86 at the moment. So shouldn't we just have one common
> > routine in swiotlb-xen.c that checks if we have CONFIG_ZONE_DMA32
> > set, then try GFP_DMA32, and if not check if CONFIG_ZONE_DMA is set
> > and then try that, else default to GFP_KERNEL?
>
> Yes, for ARM/ARM64 it makes a lot of sense given that dom0 is 1:1 mapped
> (pseudo-physical == physical). I'll let Juergen and Boris comment on
> the x86 side of things, but on x86 PV Dom0 is not 1:1 mapped so
> GFP_DMA32 is probably not meaningful.
But is it actually harmful? If the GFP_DMA32 doesn't hurt we could
just use it there. Or if that seems to ugly we can make the dma
flags dependents on a XEN_1TO1_MAPPED config option set by arm/arm64.
_______________________________________________
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 3/3] arm64: dts: Add power-domains properity to mfgcfg
From: kbuild test robot @ 2019-09-02 15:55 UTC (permalink / raw)
To: Weiyi Lu
Cc: Rob Herring, Nicolas Boichat, Weiyi Lu, srv_heupstream,
James Liao, Stephen Boyd, linux-kernel, Fan Chen, CK Hu,
linux-mediatek, kbuild-all, Matthias Brugger, linux-clk,
linux-arm-kernel
In-Reply-To: <1567413310-2589-4-git-send-email-weiyi.lu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1118 bytes --]
Hi Weiyi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc6 next-20190902]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Weiyi-Lu/clk-mediatek-Register-clock-gate-with-device/20190902-174605
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=arm64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/mediatek/mt8183.dtsi:391.29-30 syntax error
FATAL ERROR: Unable to parse input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 45326 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in
From: Krzysztof Kozlowski @ 2019-09-02 15:54 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-samsung-soc, linux-arm-kernel, Bartlomiej Zolnierkiewicz
In-Reply-To: <20190830130416.10420-1-m.szyprowski@samsung.com>
On Fri, Aug 30, 2019 at 03:04:16PM +0200, Marek Szyprowski wrote:
> Maxim 77802 PMIC is a main PMIC for the following Exynos5 based boards:
> Odroid XU, Chromebook Pit and Chromebook Pi. Driver for its voltage
> regulator is needed very early during boot to properly instantiate SD/MMC
> devices and mount rootfs, so change that driver to be compiled-in.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/configs/multi_v7_defconfig | 2 +-
Thanks, applied.
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 v4 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Wolfram Sang @ 2019-09-02 15:47 UTC (permalink / raw)
To: Eugen.Hristev
Cc: mark.rutland, devicetree, alexandre.belloni, linux-kernel,
pierre-yves.mordret, Ludovic.Desroches, robh+dt, linux-i2c, peda,
linux-arm-kernel
In-Reply-To: <b6528812-65d3-6561-38e7-c0545af900d8@microchip.com>
[-- Attachment #1.1: Type: text/plain, Size: 224 bytes --]
Hi Eugen,
> Wolfram, what do you think ?
Yes, the bindings should be generic. Peter's reasoning makes much sense
to me. I am quite sure if the two of you can work things out, I'll have
nothing to add.
Thanks,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/mcde: Some fixes to handling video mode
From: Stephan Gerhold @ 2019-09-02 15:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Maxime Ripard, Sean Paul, Maarten Lankhorst, linux-arm-kernel,
dri-devel
In-Reply-To: <20190902071714.13538-1-linus.walleij@linaro.org>
On Mon, Sep 02, 2019 at 09:17:14AM +0200, Linus Walleij wrote:
> The video DSI mode had not really been tested. These fixes makes
> it more likely to work on real hardware:
> - Set the HS clock to something the video mode reported by the
> panel can handle rather than the max HS rate.
> - Put the active width (x width) in the right bits and the VSA
> (vertical sync active) in the right bits (those were swapped).
> - Calculate the packet sizes in bytes as in the vendor driver,
> rather than in bits.
> - Handle negative result in front/back/sync packages and fall
> back to zero like in the vendor driver.
>
> Cc: Stephan Gerhold <stephan@gerhold.net>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/gpu/drm/mcde/mcde_dsi.c | 60 ++++++++++++++++++++++-----------
> 1 file changed, 41 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index 90659d190d78..f5079f0e24ca 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -365,11 +365,12 @@ void mcde_dsi_te_request(struct mipi_dsi_device *mdsi)
> static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> const struct drm_display_mode *mode)
> {
> - u8 bpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format);
> + /* cpp, characters per pixel, number of bytes per pixel */
> + u8 cpp = mipi_dsi_pixel_format_to_bpp(d->mdsi->format) / 8;
> u64 bpl;
> - u32 hfp;
> - u32 hbp;
> - u32 hsa;
> + int hfp;
> + int hbp;
> + int hsa;
> u32 blkline_pck, line_duration;
> u32 blkeol_pck, blkeol_duration;
> u32 val;
> @@ -420,13 +421,13 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> writel(val, d->regs + DSI_VID_MAIN_CTL);
>
> /* Vertical frame parameters are pretty straight-forward */
> - val = mode->vdisplay << DSI_VID_VSIZE_VSA_LENGTH_SHIFT;
> + val = mode->vdisplay << DSI_VID_VSIZE_VACT_LENGTH_SHIFT;
> /* vertical front porch */
> val |= (mode->vsync_start - mode->vdisplay)
> << DSI_VID_VSIZE_VFP_LENGTH_SHIFT;
> /* vertical sync active */
> val |= (mode->vsync_end - mode->vsync_start)
> - << DSI_VID_VSIZE_VACT_LENGTH_SHIFT;
> + << DSI_VID_VSIZE_VSA_LENGTH_SHIFT;
> /* vertical back porch */
> val |= (mode->vtotal - mode->vsync_end)
> << DSI_VID_VSIZE_VBP_LENGTH_SHIFT;
> @@ -437,21 +438,25 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> * horizontal resolution is given in pixels and must be re-calculated
> * into bytes since this is what the hardware expects.
> *
> + * hfp = horizontal front porch in bytes
> + * hbp = horizontal back porch in bytes
> + * hsa = horizontal sync active in bytes
> + *
> * 6 + 2 is HFP header + checksum
> */
> - hfp = (mode->hsync_start - mode->hdisplay) * bpp - 6 - 2;
> + hfp = (mode->hsync_start - mode->hdisplay) * cpp - 6 - 2;
> if (d->mdsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE) {
> /*
> * 6 is HBP header + checksum
> * 4 is RGB header + checksum
> */
> - hbp = (mode->htotal - mode->hsync_end) * bpp - 4 - 6;
> + hbp = (mode->htotal - mode->hsync_end) * cpp - 4 - 6;
> /*
> * 6 is HBP header + checksum
> * 4 is HSW packet bytes
> * 4 is RGB header + checksum
> */
> - hsa = (mode->hsync_end - mode->hsync_start) * bpp - 4 - 4 - 6;
> + hsa = (mode->hsync_end - mode->hsync_start) * cpp - 4 - 4 - 6;
> } else {
> /*
> * HBP includes both back porch and sync
> @@ -459,11 +464,23 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> * 4 is HSW packet bytes
> * 4 is RGB header + checksum
> */
> - hbp = (mode->htotal - mode->hsync_start) * bpp - 4 - 4 - 6;
> - /* HSA is not considered in this mode and set to 0 */
> + hbp = (mode->htotal - mode->hsync_start) * cpp - 4 - 4 - 6;
> + /* HSA is not present in this mode and set to 0 */
> + hsa = 0;
> + }
> + if (hfp < 0) {
> + dev_info(d->dev, "hfp negative, set to 0\n");
> + hfp = 0;
> + }
> + if (hbp < 0) {
> + dev_info(d->dev, "hbp negative, set to 0\n");
> + hbp = 0;
> + }
> + if (hsa < 0) {
> + dev_info(d->dev, "hsa negative, set to 0\n");
> hsa = 0;
> }
> - dev_dbg(d->dev, "hfp: %u, hbp: %u, hsa: %u\n",
> + dev_dbg(d->dev, "hfp: %u, hbp: %u, hsa: %u bytes\n",
> hfp, hbp, hsa);
>
> /* Frame parameters: horizontal sync active */
> @@ -475,7 +492,7 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> writel(val, d->regs + DSI_VID_HSIZE1);
>
> /* RGB data length (bytes on one scanline) */
> - val = mode->hdisplay * (bpp / 8);
> + val = mode->hdisplay * cpp;
> writel(val, d->regs + DSI_VID_HSIZE2);
>
> /* TODO: further adjustments for TVG mode here */
> @@ -507,7 +524,7 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> }
>
> line_duration = (blkline_pck + 6) / d->mdsi->lanes;
> - dev_dbg(d->dev, "line duration %u\n", line_duration);
> + dev_dbg(d->dev, "line duration %u bytes\n", line_duration);
> val = line_duration << DSI_VID_DPHY_TIME_REG_LINE_DURATION_SHIFT;
> /*
> * This is the time to perform LP->HS on D-PHY
> @@ -517,17 +534,18 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
> writel(val, d->regs + DSI_VID_DPHY_TIME);
>
> /* Calculate block end of line */
> - blkeol_pck = bpl - mode->hdisplay * bpp - 6;
> + blkeol_pck = bpl - mode->hdisplay * cpp - 6;
> blkeol_duration = (blkeol_pck + 6) / d->mdsi->lanes;
> - dev_dbg(d->dev, "blkeol pck: %u, duration: %u\n",
> - blkeol_pck, blkeol_duration);
> + dev_dbg(d->dev, "blkeol pck: %u bytes, duration: %u bytes\n",
> + blkeol_pck, blkeol_duration);
>
> if (d->mdsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> /* Set up EOL clock for burst mode */
> val = readl(d->regs + DSI_VID_BLKSIZE1);
> val |= blkeol_pck << DSI_VID_BLKSIZE1_BLKEOL_PCK_SHIFT;
> writel(val, d->regs + DSI_VID_BLKSIZE1);
> - writel(blkeol_pck, d->regs + DSI_VID_VCA_SETTING2);
> + writel(blkeol_pck & DSI_VID_VCA_SETTING2_EXACT_BURST_LIMIT_MASK,
> + d->regs + DSI_VID_VCA_SETTING2);
No functional difference, but it might be more clear to also shift this
by DSI_VID_VCA_SETTING2_EXACT_BURST_LIMIT_SHIFT.
>
> writel(blkeol_duration, d->regs + DSI_VID_PCK_TIME);
> writel(blkeol_duration - 6, d->regs + DSI_VID_VCA_SETTING1);
> @@ -535,9 +553,11 @@ static void mcde_dsi_setup_video_mode(struct mcde_dsi *d,
>
> /* Maximum line limit */
> val = readl(d->regs + DSI_VID_VCA_SETTING2);
> + val &= ~DSI_VID_VCA_SETTING2_MAX_LINE_LIMIT_MASK;
> val |= blkline_pck <<
> DSI_VID_VCA_SETTING2_EXACT_BURST_LIMIT_SHIFT;
This should be DSI_VID_VCA_SETTING2_MAX_LINE_LIMIT_SHIFT
to write the maximum line limit. Otherwise it will just
replace the "exact burst limit" written earlier.
_______________________________________________
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 1/5] dt-bindings: gpu: mali-midgard: Add samsung exynos5250 compatible
From: Krzysztof Kozlowski @ 2019-09-02 15:31 UTC (permalink / raw)
To: Guillaume Gardet
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190830104502.7128-2-guillaume.gardet@arm.com>
On Fri, Aug 30, 2019 at 12:44:58PM +0200, Guillaume Gardet wrote:
> Add "samsung,exynos5250-mali" binding.
>
> Signed-off-by: Guillaume Gardet <guillaume.gardet@arm.com>
>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> V3 changes:
> * add dt-bindings before node in device tree
> V2 changes:
> * new file
>
> Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 1 +
Thanks, entire set applied (with re-ordering and minor description
changes).
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: microblaze HAVE_MEMBLOCK_NODE_MAP dependency (was Re: [PATCH v2 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
From: Mike Rapoport @ 2019-09-02 15:18 UTC (permalink / raw)
To: Michal Simek
Cc: Catalin Marinas, Will Deacon, Michal Hocko,
open list:MEMORY MANAGEMENT, Paul Mackerras, H . Peter Anvin,
sparclinux@vger.kernel.org, Alexander Duyck, Will Deacon,
linux-s390@vger.kernel.org, Michael Ellerman, x86@kernel.org,
willy@infradead.org, Christian Borntraeger, Ingo Molnar,
Vlastimil Babka, Benjamin Herrenschmidt, Open Source Submission,
Pavel Tatashin, Vasily Gorbik, Heiko Carstens, Borislav Petkov,
Thomas Gleixner, Hoan Tran OS, Oscar Salvador,
linux-arm-kernel@lists.infradead.org, Randy Dunlap,
linux-kernel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org, David S . Miller
In-Reply-To: <f57f15b5-dee7-c2be-5a34-192a9ecf0763@monstr.eu>
On Mon, Sep 02, 2019 at 03:51:25PM +0200, Michal Simek wrote:
> On 31. 07. 19 19:15, Mike Rapoport wrote:
> > On Wed, Jul 31, 2019 at 04:41:14PM +0200, Michal Hocko wrote:
> >> On Wed 31-07-19 17:21:29, Mike Rapoport wrote:
> >>> On Wed, Jul 31, 2019 at 03:00:37PM +0200, Michal Hocko wrote:
> >>>>
> >>>> I am sorry, but I still do not follow. Who is consuming that node id
> >>>> information when NUMA=n. In other words why cannot we simply do
> >>>
> >>> We can, I think nobody cared to change it.
> >>
> >> It would be great if somebody with the actual HW could try it out.
> >> I can throw a patch but I do not even have a cross compiler in my
> >> toolbox.
> >
> > Well, it compiles :)
> >
> >>>> diff --git a/arch/microblaze/mm/init.c b/arch/microblaze/mm/init.c
> >>>> index a015a951c8b7..3a47e8db8d1c 100644
> >>>> --- a/arch/microblaze/mm/init.c
> >>>> +++ b/arch/microblaze/mm/init.c
> >>>> @@ -175,14 +175,9 @@ void __init setup_memory(void)
> >>>>
> >>>> start_pfn = memblock_region_memory_base_pfn(reg);
> >>>> end_pfn = memblock_region_memory_end_pfn(reg);
> >>>> - memblock_set_node(start_pfn << PAGE_SHIFT,
> >>>> - (end_pfn - start_pfn) << PAGE_SHIFT,
> >>>> - &memblock.memory, 0);
> >>>> + memory_present(0, start_pfn << PAGE_SHIFT, end_pfn << PAGE_SHIFT);
> >>>
> >>> memory_present() expects pfns, the shift is not needed.
> >>
> >> Right.
>
> Sorry for slow response on this. In general regarding this topic.
> Microblaze is soft core CPU (now there are hardcore versions too but not
> running Linux). I believe there could be Numa system with
> microblaze/microblazes (SMP is not supported in mainline).
>
> This code was added in 2011 which is pretty hard to remember why it was
> done in this way.
>
> It compiles but not working on HW. Please take a look at log below.
>
> Thanks,
> Michal
>
>
> [ 0.000000] Linux version 5.3.0-rc6-00007-g54b01939182f-dirty
> (monstr@monstr-desktop3) (gcc version 8.2.0 (crosstool-NG 1.20.0)) #101
> Mon Sep 2 15:44:05 CEST 2019
> [ 0.000000] setup_memory: max_mapnr: 0x40000
> [ 0.000000] setup_memory: min_low_pfn: 0x80000
> [ 0.000000] setup_memory: max_low_pfn: 0xb0000
> [ 0.000000] setup_memory: max_pfn: 0xc0000
> [ 0.000000] start pfn 0x80000
> [ 0.000000] end pfn 0xc0000
> [ 0.000000] Zone ranges:
> [ 0.000000] DMA [mem 0x0000000080000000-0x00000000afffffff]
> [ 0.000000] Normal empty
> [ 0.000000] HighMem [mem 0x00000000b0000000-0x00000000bfffffff]
> [ 0.000000] Movable zone start for each node
> [ 0.000000] Early memory node ranges
> [ 0.000000] node 1: [mem 0x0000000080000000-0x00000000bfffffff]
> [ 0.000000] Could not find start_pfn for node 0
> [ 0.000000] Initmem setup node 0 [mem
> 0x0000000000000000-0x0000000000000000]
This does not look good :)
I think the problem is that without an explicit call to memblock_set_node()
the ->nid in memblock is MAX_NUMNODES but free_area_init_nodes() presumes
actual node ids are properly set.
> [ 0.000000] earlycon: ns16550a0 at MMIO 0x44a01000 (options '115200n8')
> [ 0.000000] printk: bootconsole [ns16550a0] enabled
> [ 0.000000] setup_cpuinfo: initialising
> [ 0.000000] setup_cpuinfo: Using full CPU PVR support
> [ 0.000000] wt_msr_noirq
> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [ 0.000000] pcpu-alloc: [0] 0
> [ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 0
> [ 0.000000] Kernel command line: earlycon
> [ 0.000000] Dentry cache hash table entries: -2147483648 (order: -13,
> 0 bytes, linear)
> [ 0.000000] Inode-cache hash table entries: -2147483648 (order: -13,
> 0 bytes, linear)
> [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [ 0.000000] Oops: kernel access of bad area, sig: 11
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted
> 5.3.0-rc6-00007-g54b01939182f-dirty #101
> [ 0.000000] Registers dump: mode=805B9EA8
> [ 0.000000] r1=000065A0, r2=C05B7AE6, r3=00000000, r4=00000000
> [ 0.000000] r5=00080000, r6=00080B50, r7=00000000, r8=00000004
> [ 0.000000] r9=00000000, r10=0000001F, r11=00000000, r12=00006666
> [ 0.000000] r13=4119DCC0, r14=00000000, r15=C05EFF8C, r16=00000000
> [ 0.000000] r17=C0604408, r18=FFFC0000, r19=C05B9F6C, r20=BFFEC168
> [ 0.000000] r21=BFFEC168, r22=EFFF9AC0, r23=00000001, r24=C0606874
> [ 0.000000] r25=BFE6B74C, r26=80000000, r27=00000000, r28=90000040
> [ 0.000000] r29=01000000, r30=00000380, r31=C05C02F0, rPC=C0604408
> [ 0.000000] msr=000046A0, ear=00000004, esr=00000D12, fsr=FFFFFFFF
> [ 0.000000] Oops: kernel access of bad area, sig: 11
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
>
>
--
Sincerely yours,
Mike.
_______________________________________________
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 7/9] sparc64: numa: check the node id consistently for sparc64
From: David Miller @ 2019-09-02 15:17 UTC (permalink / raw)
To: linyunsheng
Cc: dalias, linux-sh, peterz, catalin.marinas, dave.hansen,
heiko.carstens, linuxarm, jiaxun.yang, linux-mips, mwb, paulus,
hpa, sparclinux, chenhc, will, cai, linux-s390, ysato, mpe, x86,
rppt, borntraeger, dledford, mingo, jeffrey.t.kirsher, benh,
jhogan, nfont, mattst88, len.brown, gor, anshuman.khandual, bp,
luto, tglx, naveen.n.rao, linux-arm-kernel, rth, axboe,
linuxppc-dev, linux-kernel, ralf, tbogendoerfer, paul.burton,
linux-alpha, ink, akpm, robin.murphy
In-Reply-To: <1e128e33-427f-19a2-0e13-95a9c0656ab1@huawei.com>
From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Mon, 2 Sep 2019 14:08:31 +0800
> The NUMA node id in sparc64 system is defined by DT semantics?
Sometimes, and in other cases other methods are used to determine
the NUMA node id.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC, v5, 1/5] media: dt-bindings: mt8183: Added camera ISP Pass 1
From: Rob Herring @ 2019-09-02 15:17 UTC (permalink / raw)
To: Jungo Lin
Cc: ryan.yu, frankie.chiu, laurent.pinchart, robh, Rynn.Wu, suleiman,
Jerry-ch.Chen, jungo.lin, frederic.chen, linux-media, devicetree,
hverkuil-cisco, shik, yuzhao, linux-mediatek, matthias.bgg,
mchehab, linux-arm-kernel, Sean.Cheng, srv_heupstream, sj.huang,
tfiga, zwisler, ddavenport
In-Reply-To: <20190902075135.1332-2-jungo.lin@mediatek.com>
On Mon, 2 Sep 2019 15:51:31 +0800, Jungo Lin wrote:
> This patch adds DT binding document for the Pass 1 (P1) unit
> in Mediatek's camera ISP system. The Pass 1 unit grabs the sensor
> data out from the sensor interface, applies ISP image effects
> from tuning data and outputs the image data or statistics data to DRAM.
>
> Signed-off-by: Jungo Lin <jungo.lin@mediatek.com>
> ---
> .../bindings/media/mediatek,camisp.txt | 73 +++++++++++++++++++
> 1 file changed, 73 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek,camisp.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 04/11] PCI: designware-ep: Modify MSI and MSIX CAP way of finding
From: Andrew Murray @ 2019-09-02 15:07 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, devicetree,
jingoohan1, zhiqiang.hou, linuxppc-dev, linux-pci, linux-kernel,
kishon, minghuan.Lian, robh+dt, gregkh, linux-arm-kernel,
gustavo.pimentel, leoyang.li, shawnguo, mingkai.hu
In-Reply-To: <20190902031716.43195-5-xiaowei.bao@nxp.com>
On Mon, Sep 02, 2019 at 11:17:09AM +0800, Xiaowei Bao wrote:
> Each PF of EP device should have it's own MSI or MSIX capabitily
> struct, so create a dw_pcie_ep_func struct and remover the msi_cap
remover?
> and msix_cap to this struce, and manage the PFs with a list.
struce?
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> v1:
> - This is a new patch, to fix the issue of MSI and MSIX CAP way of
> finding.
> v2:
> - No change.
> v3:
> - No change.
This makes it look like you introduced the patch in v1 and haven't
changed it since.
I think it's more common to have a history like this:
---
v3:
- Introduced new patch, to fix the issue of MSI and MSIX CAP way of
finding.
>
> drivers/pci/controller/dwc/pcie-designware-ep.c | 135 +++++++++++++++++++++---
> drivers/pci/controller/dwc/pcie-designware.h | 18 +++-
> 2 files changed, 134 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index c3bc7bd..144eb12 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -19,6 +19,19 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> pci_epc_linkup(epc);
> }
>
> +struct dw_pcie_ep_func *
> +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no)
> +{
> + struct dw_pcie_ep_func *ep_func;
> +
> + list_for_each_entry(ep_func, &ep->func_list, list) {
> + if (ep_func->func_no == func_no)
> + return ep_func;
> + }
> +
> + return NULL;
> +}
> +
> static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8 func_no)
> {
> unsigned int func_offset = 0;
> @@ -59,6 +72,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
> __dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
> }
>
> +static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8 func_no,
> + u8 cap_ptr, u8 cap)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + unsigned int func_offset = 0;
> + u8 cap_id, next_cap_ptr;
> + u16 reg;
> +
> + if (!cap_ptr)
> + return 0;
> +
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
> + cap_id = (reg & 0x00ff);
> +
> + if (cap_id > PCI_CAP_ID_MAX)
> + return 0;
> +
> + if (cap_id == cap)
> + return cap_ptr;
> +
> + next_cap_ptr = (reg & 0xff00) >> 8;
> + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap);
> +}
Which tree have you based this patchset on? v5.3-rc3 and pci/dwc both already
have this function (without the func_no). See beb4641a787d
("PCI: dwc: Add MSI-X callbacks handler").
> +
> +static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8 func_no, u8 cap)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + unsigned int func_offset = 0;
> + u8 next_cap_ptr;
> + u16 reg;
> +
> + func_offset = dw_pcie_ep_func_select(ep, func_no);
> +
> + reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
> + next_cap_ptr = (reg & 0x00ff);
> +
> + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap);
> +}
> +
> static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> struct pci_epf_header *hdr)
> {
> @@ -246,13 +300,18 @@ static int dw_pcie_ep_get_msi(struct pci_epc *epc, u8 func_no)
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> unsigned int func_offset = 0;
> + struct dw_pcie_ep_func *ep_func;
>
> - if (!ep->msi_cap)
> + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> + if (!ep_func)
> + return -EINVAL;
> +
> + if (!ep_func->msi_cap)
> return -EINVAL;
>
> func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> - reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> + reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> if (!(val & PCI_MSI_FLAGS_ENABLE))
> return -EINVAL;
> @@ -268,13 +327,18 @@ static int dw_pcie_ep_set_msi(struct pci_epc *epc, u8 func_no, u8 interrupts)
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> unsigned int func_offset = 0;
> + struct dw_pcie_ep_func *ep_func;
> +
> + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> + if (!ep_func)
> + return -EINVAL;
>
> - if (!ep->msi_cap)
> + if (!ep_func->msi_cap)
> return -EINVAL;
>
> func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> - reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> + reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> val &= ~PCI_MSI_FLAGS_QMASK;
> val |= (interrupts << 1) & PCI_MSI_FLAGS_QMASK;
> @@ -291,13 +355,18 @@ static int dw_pcie_ep_get_msix(struct pci_epc *epc, u8 func_no)
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> unsigned int func_offset = 0;
> + struct dw_pcie_ep_func *ep_func;
> +
> + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> + if (!ep_func)
> + return -EINVAL;
>
> - if (!ep->msix_cap)
> + if (!ep_func->msix_cap)
> return -EINVAL;
>
> func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> - reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> + reg = ep_func->msix_cap + func_offset + PCI_MSIX_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> if (!(val & PCI_MSIX_FLAGS_ENABLE))
> return -EINVAL;
> @@ -313,13 +382,18 @@ static int dw_pcie_ep_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts)
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 val, reg;
> unsigned int func_offset = 0;
> + struct dw_pcie_ep_func *ep_func;
>
> - if (!ep->msix_cap)
> + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> + if (!ep_func)
> + return -EINVAL;
> +
> + if (!ep_func->msix_cap)
> return -EINVAL;
>
> func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> - reg = ep->msix_cap + func_offset + PCI_MSIX_FLAGS;
> + reg = ep_func->msix_cap + func_offset + PCI_MSIX_FLAGS;
> val = dw_pcie_readw_dbi(pci, reg);
> val &= ~PCI_MSIX_FLAGS_QSIZE;
> val |= interrupts;
> @@ -404,6 +478,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
> u8 interrupt_num)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct dw_pcie_ep_func *ep_func;
> struct pci_epc *epc = ep->epc;
> unsigned int aligned_offset;
> unsigned int func_offset = 0;
> @@ -413,25 +488,29 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
> bool has_upper;
> int ret;
>
> - if (!ep->msi_cap)
> + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> + if (!ep_func)
> + return -EINVAL;
> +
> + if (!ep_func->msi_cap)
> return -EINVAL;
>
> func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> - reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> + reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
> msg_ctrl = dw_pcie_readw_dbi(pci, reg);
> has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> - reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> + reg = ep_func->msi_cap + func_offset + PCI_MSI_ADDRESS_LO;
> msg_addr_lower = dw_pcie_readl_dbi(pci, reg);
> if (has_upper) {
> - reg = ep->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> + reg = ep_func->msi_cap + func_offset + PCI_MSI_ADDRESS_HI;
> msg_addr_upper = dw_pcie_readl_dbi(pci, reg);
> - reg = ep->msi_cap + func_offset + PCI_MSI_DATA_64;
> + reg = ep_func->msi_cap + func_offset + PCI_MSI_DATA_64;
> msg_data = dw_pcie_readw_dbi(pci, reg);
> } else {
> msg_addr_upper = 0;
> - reg = ep->msi_cap + func_offset + PCI_MSI_DATA_32;
> + reg = ep_func->msi_cap + func_offset + PCI_MSI_DATA_32;
> msg_data = dw_pcie_readw_dbi(pci, reg);
> }
> aligned_offset = msg_addr_lower & (epc->mem->page_size - 1);
> @@ -467,6 +546,7 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> u16 interrupt_num)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct dw_pcie_ep_func *ep_func;
> struct pci_epc *epc = ep->epc;
> u16 tbl_offset, bir;
> unsigned int func_offset = 0;
> @@ -477,9 +557,16 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> void __iomem *msix_tbl;
> int ret;
>
> + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> + if (!ep_func)
> + return -EINVAL;
> +
> + if (!ep_func->msix_cap)
> + return -EINVAL;
> +
> func_offset = dw_pcie_ep_func_select(ep, func_no);
>
> - reg = ep->msix_cap + func_offset + PCI_MSIX_TABLE;
> + reg = ep_func->msix_cap + func_offset + PCI_MSIX_TABLE;
> tbl_offset = dw_pcie_readl_dbi(pci, reg);
> bir = (tbl_offset & PCI_MSIX_TABLE_BIR);
> tbl_offset &= PCI_MSIX_TABLE_OFFSET;
> @@ -558,6 +645,7 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> int i;
> int ret;
> u32 reg;
> + u8 func_no;
> void *addr;
> unsigned int nbars;
> unsigned int offset;
> @@ -565,6 +653,9 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct device *dev = pci->dev;
> struct device_node *np = dev->of_node;
> + struct dw_pcie_ep_func *ep_func;
> +
> + INIT_LIST_HEAD(&ep->func_list);
>
> if (!pci->dbi_base || !pci->dbi_base2) {
> dev_err(dev, "dbi_base/dbi_base2 is not populated\n");
> @@ -624,9 +715,19 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> if (ret < 0)
> epc->max_functions = 1;
>
> - ep->msi_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> + for (func_no = 0; func_no < epc->max_functions; func_no++) {
> + ep_func = devm_kzalloc(dev, sizeof(*ep_func), GFP_KERNEL);
> + if (!ep_func)
> + return -ENOMEM;
>
> - ep->msix_cap = dw_pcie_find_capability(pci, PCI_CAP_ID_MSIX);
> + ep_func->func_no = func_no;
> + ep_func->msi_cap = dw_pcie_ep_find_capability(ep, func_no,
> + PCI_CAP_ID_MSI);
> + ep_func->msix_cap = dw_pcie_ep_find_capability(ep, func_no,
> + PCI_CAP_ID_MSIX);
> +
> + list_add_tail(&ep_func->list, &ep->func_list);
> + }
Whilst your patch addresses the issue of giving each function the ability to
have differing capabilities - I feel that this solution doesn't go deep enough.
In my view the root issue here is that 'struct dw_pcie_ep' represents both a
EP controller and a *single* EP function. I think that there should be a
representation for an EP controller and a representation for a EP function
(i.e. some separation). Thus allowing one EP controller to have many EP
functions. This isn't too dissimilar to host bridges and their functions.
Others here may have different views.
It may be unlikely now, but EP functions belonging to the same bit of IP may
have differing functionality - your approach addresses that for MSI/MSI
capabilities, but what about other differences?
(It would be really nice as well if an EP controller could provide config
read/write ops such that existing functions in the core such as
__pci_find_next_capability could be reused - instead of copying them
like dw_pcie_ep_find_capability. However I don't think this is feasible.)
Thanks,
Andrew Murray
>
> if (ep->ops->ep_init)
> ep->ops->ep_init(ep);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 56789be..a57743c 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -221,8 +221,16 @@ struct dw_pcie_ep_ops {
> unsigned int (*func_conf_select)(struct dw_pcie_ep *ep, u8 func_no);
> };
>
> +struct dw_pcie_ep_func {
> + struct list_head list;
> + u8 func_no;
> + u8 msi_cap; /* MSI capability offset */
> + u8 msix_cap; /* MSI-X capability offset */
> +};
> +
> struct dw_pcie_ep {
> struct pci_epc *epc;
> + struct list_head func_list;
> const struct dw_pcie_ep_ops *ops;
> phys_addr_t phys_base;
> size_t addr_size;
> @@ -235,8 +243,6 @@ struct dw_pcie_ep {
> u32 num_ob_windows;
> void __iomem *msi_mem;
> phys_addr_t msi_mem_phys;
> - u8 msi_cap; /* MSI capability offset */
> - u8 msix_cap; /* MSI-X capability offset */
> };
>
> struct dw_pcie_ops {
> @@ -425,6 +431,8 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
> u16 interrupt_num);
> void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> +struct dw_pcie_ep_func *
> +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no);
> #else
> static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> {
> @@ -466,5 +474,11 @@ static inline int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep,
> static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
> {
> }
> +
> +struct dw_pcie_ep_func *
> +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no)
> +{
> + return NULL;
> +}
> #endif
> #endif /* _PCIE_DESIGNWARE_H */
> --
> 2.9.5
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] drm/mcde: Fix DSI transfers
From: Stephan Gerhold @ 2019-09-02 15:04 UTC (permalink / raw)
To: Linus Walleij
Cc: kbuild test robot, Maxime Ripard, Maarten Lankhorst, dri-devel,
Sean Paul, linux-arm-kernel
In-Reply-To: <20190831075013.21993-1-linus.walleij@linaro.org>
On Sat, Aug 31, 2019 at 09:50:13AM +0200, Linus Walleij wrote:
> There were bugs in the DSI transfer (read and write) function
> as it was only tested with displays ever needing a single byte
> to be written. Fixed it up and tested so we can now write
> messages of up to 16 bytes and read up to 4 bytes from the
> display.
>
> Tested with a Sony ACX424AKP display: this display now self-
> identifies and can control backlight in command mode.
>
> Cc: Stephan Gerhold <stephan@gerhold.net>
> Reported-by: kbuild test robot <lkp@intel.com>
> Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - Fix a print modifier for dev_err() found by the build robot.
> ---
> drivers/gpu/drm/mcde/mcde_dsi.c | 70 ++++++++++++++++++++++-----------
> 1 file changed, 47 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c b/drivers/gpu/drm/mcde/mcde_dsi.c
> index 07f7090d08b3..90659d190d78 100644
> --- a/drivers/gpu/drm/mcde/mcde_dsi.c
> +++ b/drivers/gpu/drm/mcde/mcde_dsi.c
> @@ -178,22 +178,26 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
> const u32 loop_delay_us = 10; /* us */
> const u8 *tx = msg->tx_buf;
> u32 loop_counter;
> - size_t txlen;
> + size_t txlen = msg->tx_len;
> + size_t rxlen = msg->rx_len;
> u32 val;
> int ret;
> int i;
>
> - txlen = msg->tx_len;
> - if (txlen > 12) {
> + if (txlen > 16) {
> dev_err(d->dev,
> - "dunno how to write more than 12 bytes yet\n");
> + "dunno how to write more than 16 bytes yet\n");
> + return -EIO;
> + }
> + if (rxlen > 4) {
> + dev_err(d->dev,
> + "dunno how to read more than 4 bytes yet\n");
> return -EIO;
> }
>
> dev_dbg(d->dev,
> - "message to channel %d, %zd bytes",
> - msg->channel,
> - txlen);
> + "message to channel %d, write %zd bytes read %zd bytes\n",
> + msg->channel, txlen, rxlen);
>
> /* Command "nature" */
> if (MCDE_DSI_HOST_IS_READ(msg->type))
> @@ -210,9 +214,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
> if (mipi_dsi_packet_format_is_long(msg->type))
> val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LONGNOTSHORT;
> val |= 0 << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_ID_SHIFT;
> - /* Add one to the length for the MIPI DCS command */
> - val |= txlen
> - << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
> + val |= txlen << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_SIZE_SHIFT;
> val |= DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_LP_EN;
> val |= msg->type << DSI_DIRECT_CMD_MAIN_SETTINGS_CMD_HEAD_SHIFT;
> writel(val, d->regs + DSI_DIRECT_CMD_MAIN_SETTINGS);
> @@ -249,17 +251,36 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
> writel(1, d->regs + DSI_DIRECT_CMD_SEND);
>
> loop_counter = 1000 * 1000 / loop_delay_us;
> - while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> - DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
> - && --loop_counter)
> - usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> -
> - if (!loop_counter) {
> - dev_err(d->dev, "DSI write timeout!\n");
> - return -ETIME;
> + if (MCDE_DSI_HOST_IS_READ(msg->type)) {
> + /* Read command */
> + while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> + (DSI_DIRECT_CMD_STS_READ_COMPLETED |
> + DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR))
> + && --loop_counter)
> + usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> + if (!loop_counter) {
> + dev_err(d->dev, "DSI write timeout!\n");
"DSI read timeout!" might be more apppropriate here?
> + return -ETIME;
> + }
> + } else {
> + /* Writing only */
> + while (!(readl(d->regs + DSI_DIRECT_CMD_STS) &
> + DSI_DIRECT_CMD_STS_WRITE_COMPLETED)
> + && --loop_counter)
> + usleep_range(loop_delay_us, (loop_delay_us * 3) / 2);
> +
> + if (!loop_counter) {
> + dev_err(d->dev, "DSI write timeout!\n");
> + return -ETIME;
> + }
> }
>
> val = readl(d->regs + DSI_DIRECT_CMD_STS);
> + if (val & DSI_DIRECT_CMD_STS_READ_COMPLETED_WITH_ERR) {
> + dev_err(d->dev, "read completed with error\n");
> + writel(1, d->regs + DSI_DIRECT_CMD_RD_INIT);
> + return -EIO;
> + }
> if (val & DSI_DIRECT_CMD_STS_ACKNOWLEDGE_WITH_ERR_RECEIVED) {
> val >>= DSI_DIRECT_CMD_STS_ACK_VAL_SHIFT;
> dev_err(d->dev, "error during transmission: %04x\n",
> @@ -269,10 +290,7 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
>
> if (!MCDE_DSI_HOST_IS_READ(msg->type)) {
> /* Return number of bytes written */
> - if (mipi_dsi_packet_format_is_long(msg->type))
> - ret = 4 + txlen;
> - else
> - ret = 4;
> + ret = txlen;
> } else {
> /* OK this is a read command, get the response */
> u32 rdsz;
> @@ -282,7 +300,13 @@ static ssize_t mcde_dsi_host_transfer(struct mipi_dsi_host *host,
> rdsz = readl(d->regs + DSI_DIRECT_CMD_RD_PROPERTY);
> rdsz &= DSI_DIRECT_CMD_RD_PROPERTY_RD_SIZE_MASK;
> rddat = readl(d->regs + DSI_DIRECT_CMD_RDDAT);
> - for (i = 0; i < 4 && i < rdsz; i++)
> + if (rdsz < rxlen) {
> + dev_err(d->dev, "read error, requested %zd got %d\n",
> + msg->rx_len, rdsz);
Using rxlen instead of msg->rx_len would be more consistent
with the if condition.
These are just minor nitpicks, so with or without changes:
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
_______________________________________________
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 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Dongchun Zhu @ 2019-09-02 15:01 UTC (permalink / raw)
To: Tomasz Figa
Cc: mark.rutland, devicetree, srv_heupstream, shengnan.wang,
louis.kuo, sj.huang, robh+dt, linux-mediatek, sakari.ailus,
matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20190823081723.GA33937@chromium.org>
Hi Tomasz,
On Fri, 2019-08-23 at 17:17 +0900, Tomasz Figa wrote:
> Hi Dongchun,
>
> On Mon, Jul 08, 2019 at 06:06:41PM +0800, dongchun.zhu@mediatek.com wrote:
> > From: Dongchun Zhu <dongchun.zhu@mediatek.com>
> >
> > This patch adds a V4L2 sub-device driver for DW9768 lens voice coil,
> > and provides control to set the desired focus.
> >
> > The DW9807 is a 10 bit DAC from Dongwoon, designed for linear
> > control of voice coil motor.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/media/i2c/Kconfig | 10 +
> > drivers/media/i2c/Makefile | 1 +
> > drivers/media/i2c/dw9768.c | 458 +++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 470 insertions(+)
> > create mode 100644 drivers/media/i2c/dw9768.c
> >
>
> Thanks for the patch! Please see my comments inline.
>
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8f6ac93..17152d7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -4877,6 +4877,7 @@ M: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > L: linux-media@vger.kernel.org
> > T: git git://linuxtv.org/media_tree.git
> > S: Maintained
> > +F: drivers/media/i2c/dw9768.c
> > F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
> >
> > DONGWOON DW9807 LENS VOICE COIL DRIVER
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index 7793358..8ff6c95 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -1014,6 +1014,16 @@ config VIDEO_DW9714
> > capability. This is designed for linear control of
> > voice coil motors, controlled via I2C serial interface.
> >
> > +config VIDEO_DW9768
> > + tristate "DW9768 lens voice coil support"
> > + depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> > + depends on VIDEO_V4L2_SUBDEV_API
> > + help
> > + This is a driver for the DW9768 camera lens voice coil.
> > + DW9768 is a 10 bit DAC with 100mA output current sink
> > + capability. This is designed for linear control of
> > + voice coil motors, controlled via I2C serial interface.
> > +
> > config VIDEO_DW9807_VCM
> > tristate "DW9807 lens voice coil support"
> > depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> > index d8ad9da..944fbf6 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -24,6 +24,7 @@ obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
> > obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
> > obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
> > obj-$(CONFIG_VIDEO_DW9714) += dw9714.o
> > +obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
> > obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
> > obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
> > obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
> > diff --git a/drivers/media/i2c/dw9768.c b/drivers/media/i2c/dw9768.c
> > new file mode 100644
> > index 0000000..f5b5591
> > --- /dev/null
> > +++ b/drivers/media/i2c/dw9768.c
> > @@ -0,0 +1,458 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 MediaTek Inc.
> > + */
> > +
> > +#include <linux/delay.h>
> > +#include <linux/i2c.h>
> > +#include <linux/module.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/pm_runtime.h>
> > +#include <media/v4l2-ctrls.h>
> > +#include <media/v4l2-device.h>
> > +#include <media/v4l2-subdev.h>
> > +
> > +#define DW9768_VOLTAGE_ANALOG 2800000
>
> This is a platform detail and should be defined in the platform data, for
> example DTS on platforms using DT.
>
Thanks for your reminder.
This would be fixed in next release.
> > +#define DW9768_NAME "dw9768"
>
> The chip we seem to be using this driver for is called gt9769. Shouldn't we
> call the driver the same?
>
It is also called DW9768 from camera module specification, which was
initially confirmed with vendor.
> > +#define DW9768_MAX_FOCUS_POS 1023
> > +/*
> > + * This sets the minimum granularity for the focus positions.
> > + * A value of 1 gives maximum accuracy for a desired focus position
> > + */
> > +#define DW9768_FOCUS_STEPS 1
> > +
> > +#define DW9768_CTRL_DELAY_US 5000
> > +
> > +#define DW9768_REG_DAC_MSB 0x03
> > +#define DW9768_REG_DAC_LSB 0x04
> > +#define DW9768_REG_NULL 0xff
> > +
> > +#define DW9768_DAC_SHIFT 8
> > +
> > +#define DW9768_REG_VALUE_16BIT 2
>
> This driver seems to always write 16-bit values. Can we simplify it to just
> always assume so?
>
Fixed in next release.
> > +
> > +/* dw9768 device structure */
> > +struct dw9768_device {
> > + struct v4l2_ctrl_handler ctrls;
> > + struct v4l2_subdev sd;
> > + struct regulator *analog_regulator;
> > + /*
> > + * Serialize control access, get/set format, get selection
> > + * and start streaming.
> > + */
> > + struct mutex power_lock;
> > +
> > + int power_count;
> > + bool standby;
> > +};
> > +
> > +static inline struct dw9768_device *to_dw9768_vcm(struct v4l2_ctrl *ctrl)
> > +{
> > + return container_of(ctrl->handler, struct dw9768_device, ctrls);
> > +}
> > +
> > +static inline struct dw9768_device *sd_to_dw9768_vcm(struct v4l2_subdev *subdev)
> > +{
> > + return container_of(subdev, struct dw9768_device, sd);
> > +}
> > +
> > +static int dw9768_i2c_write(struct dw9768_device *dw9768_dev, u8 *data,
> > + int size)
> > +{
> > + struct i2c_client *client = v4l2_get_subdevdata(&dw9768_dev->sd);
> > + struct i2c_msg msg;
> > + u8 *w_buf = NULL;
> > + u8 retry_cnt = 3;
> > + int ret;
> > +
> > + if (!client->adapter)
> > + return -ENODEV;
>
> This isn't possible.
>
Removed in next release.
> > +
> > + if (size != 1 && size != 2)
> > + return -EINVAL;
>
> All the calls always pass 2.
>
Fixed in next release.
> > +
> > + memset(&msg, 0, sizeof(struct i2c_msg));
> > +
> > + w_buf = kzalloc(size, GFP_KERNEL);
> > + if (!w_buf)
> > + return -1;
>
> The size is fixed to 2. Is it necessary to allocate the buffer dynamically?
>
Fixed in next release.
> > +
> > + memcpy(w_buf, data, size);
> > +
> > + msg.addr = client->addr;
> > + msg.flags = 0;
> > + msg.len = size;
> > + msg.buf = w_buf;
>
> Actually, why don't we just use data directly?
>
Fixed in next release.
> > +
> > + do {
> > + ret = i2c_transfer(client->adapter, &msg, 1);
> > + if (ret != 1)
> > + dev_err(&client->dev, "write fail, ret:%d, retry:%d\n",
> > + ret, retry_cnt);
> > + else
> > + break;
> > + retry_cnt--;
> > + } while (retry_cnt != 0);
> > +
> > + if (retry_cnt == 0) {
> > + dev_err(&client->dev, "i2c write fail(%d)\n", ret);
> > + return -EIO;
> > + }
>
> Why do we need to handle retries here? I don't see the hardware datasheet
> refer to any need to do those. Are you seeing some issues with transfers?
>
This is used to processing i2c transfer showing abnormality in some
cases.
Retries handler would be removed in next release.
> > +
> > + kfree(w_buf);
> > +
> > + return 0;
> > +}
> > +
> > +static int dw9768_release(struct dw9768_device *dw9768_dev)
> > +{
> > + unsigned char i;
> > + int ret;
> > +
> > + char puSendCmdArray[4][2] = {
>
> Please use the correct kernel coding style.
>
Fixed in next release.
> > + {0x02, 0x00}, {DW9768_REG_NULL, DW9768_REG_NULL},
> > + {0x01, 0x00}, {DW9768_REG_NULL, DW9768_REG_NULL},
>
> We only check the first element for this specific value, so we don't need
> to initialize the second one.
>
> Also, could we call it DW9768_CMD_DELAY instead?
>
> Also, please define macros for the magic values used in the array.
>
This would be fixed in next release.
> > + };
> > +
> > + for (i = 0; i < (sizeof(puSendCmdArray) / sizeof(char)) /
> > + (sizeof(puSendCmdArray[0]) / sizeof(char)); i++) {
>
> Wouldn't ARRAY_SIZE() work here?
>
Fixed in next release.
> > + if (puSendCmdArray[i][0] != DW9768_REG_NULL) {
> > + ret = dw9768_i2c_write(dw9768_dev, puSendCmdArray[i],
> > + DW9768_REG_VALUE_16BIT);
> > + if (ret < 0)
> > + return ret;
>
> Hmm, isn't this command array actually a pair of addreses and values?
> Please define a struct for the entries.
>
> Could we just use i2c_smbus_write_byte_data() instead of the custom
> dw9768_i2c_write()?
>
Thanks for great suggestion.
We would try i2c_smbus_write_byte_data API for write i2c register.
> > + } else {
> > + usleep_range(DW9768_CTRL_DELAY_US,
> > + DW9768_CTRL_DELAY_US + 100);
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int dw9768_init(struct dw9768_device *dw9768_dev)
> > +{
> > + unsigned char i;
> > + int ret;
> > +
> > + char puSendCmdArray[5][2] = {
> > + {0x02, 0x02}, {DW9768_REG_NULL, DW9768_REG_NULL},
> > + {0x06, 0x41}, {0x07, 0x39}, {DW9768_REG_NULL, DW9768_REG_NULL},
> > + };
> > +
> > + for (i = 0; i < (sizeof(puSendCmdArray) / sizeof(char)) /
> > + (sizeof(puSendCmdArray[0]) / sizeof(char)); i++) {
> > + if (puSendCmdArray[i][0] != DW9768_REG_NULL) {
> > + ret = dw9768_i2c_write(dw9768_dev, puSendCmdArray[i],
> > + DW9768_REG_VALUE_16BIT);
> > + if (ret < 0)
> > + return ret;
> > + } else {
> > + usleep_range(DW9768_CTRL_DELAY_US,
> > + DW9768_CTRL_DELAY_US + 100);
> > + }
> > + }
>
> The code here is duplicated, just different command array is used. Could we
> move the command array handling to a helper function? (+ all the comments
> I mentioned above)
>
Fixed in next release.
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Power handling
> > + */
> > +static int dw9768_power_off(struct dw9768_device *dw9768_dev, bool standby)
> > +{
> > + struct i2c_client *client = v4l2_get_subdevdata(&dw9768_dev->sd);
> > + int ret;
> > +
> > + /*
> > + * Go to standby first as real power off my be denied by the hardware
> > + * (single power line control for both dw9768_dev and sensor).
>
> What do you mean here? The regulator subsystem already properly handles
> reference counting.
>
Understood.
> > + */
> > + if (standby) {
> > + dw9768_dev->standby = true;
> > + ret = dw9768_release(dw9768_dev);
> > + if (ret)
> > + dev_err(&client->dev, "dw9768_release failed!\n");
>
> Shouldn't we always call this when we power off?
>
> > + }
> > + ret = regulator_disable(dw9768_dev->analog_regulator);
> > + if (ret)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +static int dw9768_power_on(struct dw9768_device *dw9768_dev, bool restore)
> > +{
> > + int ret;
> > +
> > + ret = regulator_enable(dw9768_dev->analog_regulator);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (restore) {
> > + /* Restore the hardware settings. */
> > + dw9768_dev->standby = false;
> > + ret = dw9768_init(dw9768_dev);
> > + if (ret < 0)
> > + goto fail;
>
> Shouldn't we always call this when we power on, without any condition?
>
> > + }
> > +
> > + return 0;
> > +
> > +fail:
> > + dw9768_dev->standby = true;
> > + regulator_disable(dw9768_dev->analog_regulator);
> > +
> > + return ret;
> > +}
>
> The two functions above should be called from the runtime PM suspend/resume
> callbacks.
>
Fixed in next release.
> > +
> > +/*
> > + * Calculate status word and write it to the device based on current
> > + * values of V4L2 controls. It is assumed that the stored V4L2 control
> > + * values are properly limited and rounded.
> > + */
> > +static int dw9768_update_hw(struct dw9768_device *dw9768_dev, u16 val)
> > +{
> > + unsigned char i;
> > + int ret;
> > +
> > + char puSendCmdArray[2][2] = {
> > + {DW9768_REG_DAC_MSB, (char)(val >> DW9768_DAC_SHIFT)},
> > + {DW9768_REG_DAC_LSB, (char)(val & 0xFF)},
> > + };
> > +
> > + for (i = 0; i < (sizeof(puSendCmdArray) / sizeof(char)) /
> > + (sizeof(puSendCmdArray[0]) / sizeof(char)); i++) {
> > + ret = dw9768_i2c_write(dw9768_dev, puSendCmdArray[i],
> > + DW9768_REG_VALUE_16BIT);
> > + if (ret)
> > + return ret;
> > + }
>
> Since the two registers are actually one after another, perhaps you could
> use i2c_smbus_write_block_data() to batch them into one transfer?
>
We would have a try.
> > +
> > + return 0;
> > +}
> > +
> > +static int dw9768_set_ctrl(struct v4l2_ctrl *ctrl)
> > +{
> > + struct dw9768_device *dw9768_dev = to_dw9768_vcm(ctrl);
> > +
> > + if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
> > + return dw9768_update_hw(dw9768_dev, ctrl->val);
>
> I think we could just inline the contents of that function here, because
> this function doesn't do anything else.
>
Fixed in next release.
> > +
> > + return 0;
> > +}
> > +
> > +static const struct v4l2_ctrl_ops dw9768_vcm_ctrl_ops = {
> > + .s_ctrl = dw9768_set_ctrl,
> > +};
> > +
> > +static int
> > +dw9768_set_power(struct v4l2_subdev *subdev, int on)
> > +{
> > + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(subdev);
> > + int ret = 0;
> > +
> > + mutex_lock(&dw9768_dev->power_lock);
> > +
> > + /*
> > + * If the power count is modified from 0 to != 0 or from != 0 to 0,
> > + * update the power state.
> > + */
> > + if (dw9768_dev->power_count == !on) {
> > + ret = on ? dw9768_power_on(dw9768_dev, true) :
> > + dw9768_power_off(dw9768_dev, true);
> > + if (ret < 0)
> > + goto done;
> > + }
>
> If we use runtime PM, we get the reference count handling done for us by
> the subsystem.
>
Understood.
> > +
> > + /* Update the power count. */
> > + dw9768_dev->power_count += on ? 1 : -1;
> > + WARN_ON(dw9768_dev->power_count < 0);
> > +
> > +done:
> > + mutex_unlock(&dw9768_dev->power_lock);
> > + return ret;
> > +}
> > +
> > +static int dw9768_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> > +{
> > + return dw9768_set_power(sd, 1);
>
> We could just call pm_runtime_get_sync() here.
>
Fixed in next release.
> > +}
> > +
> > +static int dw9768_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> > +{
> > + return dw9768_set_power(sd, 0);
>
> And pm_runtime_put() here.
>
Fixed in next release.
> > +}
> > +
> > +static const struct v4l2_subdev_internal_ops dw9768_int_ops = {
> > + .open = dw9768_open,
> > + .close = dw9768_close,
> > +};
> > +
> > +static const struct v4l2_subdev_ops dw9768_ops = { };
> > +
> > +static void dw9768_subdev_cleanup(struct dw9768_device *dw9768_dev)
> > +{
> > + v4l2_async_unregister_subdev(&dw9768_dev->sd);
> > + v4l2_ctrl_handler_free(&dw9768_dev->ctrls);
> > + media_entity_cleanup(&dw9768_dev->sd.entity);
> > +}
> > +
> > +static int dw9768_init_controls(struct dw9768_device *dw9768_dev)
> > +{
> > + struct v4l2_ctrl_handler *hdl = &dw9768_dev->ctrls;
> > + const struct v4l2_ctrl_ops *ops = &dw9768_vcm_ctrl_ops;
> > +
> > + v4l2_ctrl_handler_init(hdl, 1);
> > +
> > + v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE,
> > + 0, DW9768_MAX_FOCUS_POS, DW9768_FOCUS_STEPS, 0);
> > +
> > + if (hdl->error) {
> > + dev_err(dw9768_dev->sd.dev, "%s fail error: 0x%x\n",
> > + __func__, hdl->error);
> > + return hdl->error;
> > + }
> > +
> > + dw9768_dev->sd.ctrl_handler = hdl;
> > +
> > + return 0;
> > +}
> > +
> > +static int dw9768_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = &client->dev;
> > + struct dw9768_device *dw9768_dev;
>
> nit: Could we drop the _device and _dev suffixes to shorten the names?
>
Fixed in next release.
> > + int rval;
> > +
> > + dw9768_dev = devm_kzalloc(&client->dev, sizeof(*dw9768_dev),
> > + GFP_KERNEL);
> > + if (!dw9768_dev)
> > + return -ENOMEM;
> > +
> > + dw9768_dev->analog_regulator = devm_regulator_get(dev, "afvdd");
>
> "avfdd" is the name on our camera module, not the chip. It should be "vdd".
>
Fixed in next release.
> > + if (IS_ERR(dw9768_dev->analog_regulator)) {
> > + dev_err(dev, "cannot get analog regulator\n");
> > + return PTR_ERR(dw9768_dev->analog_regulator);
> > + }
>
> We also need 1 more regulator here for the I2C interface. The datasheet
> calls it "vin".
>
Fixed in next release.
> > +
> > + rval = regulator_set_voltage(dw9768_dev->analog_regulator,
> > + DW9768_VOLTAGE_ANALOG,
> > + DW9768_VOLTAGE_ANALOG);
> > + if (rval < 0) {
> > + dev_err(dev, "cannot set analog voltage\n");
> > + return rval;
> > + }
>
> This should be set in the platform code. For example, on systems using DT
> it can be done by setting the regulator min and max constraints in the DTS.
>
Fixed in next release.
> > +
> > + mutex_init(&dw9768_dev->power_lock);
> > +
> > + v4l2_i2c_subdev_init(&dw9768_dev->sd, client, &dw9768_ops);
> > + dw9768_dev->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > + dw9768_dev->sd.internal_ops = &dw9768_int_ops;
> > +
> > + rval = dw9768_init_controls(dw9768_dev);
> > + if (rval)
> > + goto err_cleanup;
> > +
> > + rval = media_entity_pads_init(&dw9768_dev->sd.entity, 0, NULL);
> > + if (rval < 0)
> > + goto err_cleanup;
> > +
> > + dw9768_dev->sd.entity.function = MEDIA_ENT_F_LENS;
> > +
> > + rval = v4l2_async_register_subdev(&dw9768_dev->sd);
> > + if (rval < 0)
> > + goto err_cleanup;
> > +
> > + pm_runtime_set_active(dev);
>
> We shouldn't call this if we didn't fully power up the device ourselves and
> I don't see the code above enabling the regulator. Given the privacy LED
> concerns, we actually shouldn't attempt to power on in probe.
>
Understood.
> > + pm_runtime_enable(dev);
> > + pm_runtime_idle(dev);
>
> Ditto for idle, which is not needed if the device was not set active.
>
Fixed in next release.
> > +
> > + return 0;
> > +
> > +err_cleanup:
> > + mutex_destroy(&dw9768_dev->power_lock);
> > + dw9768_subdev_cleanup(dw9768_dev);
> > + dev_err(dev, "Probe failed: %d\n", rval);
> > + return rval;
> > +}
> > +
> > +static int dw9768_remove(struct i2c_client *client)
> > +{
> > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(sd);
> > +
> > + pm_runtime_disable(&client->dev);
>
> Technically we need to check if (!pm_runtime_state_suspended()) and power
> down manually and set_suspended if that was the case.
>
Fixed in next release.
> > + dw9768_subdev_cleanup(dw9768_dev);
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * This function sets the vcm position, so it consumes least current
> > + * The lens position is gradually moved in units of DW9768_CTRL_STEPS,
> > + * to make the movements smoothly.
> > + */
> > +static int __maybe_unused dw9768_vcm_suspend(struct device *dev)
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(sd);
> > +
> > + if (!dw9768_dev->power_count)
> > + return 0;
> > +
> > + return dw9768_power_off(dw9768_dev, false);
> > +}
> > +
> > +/*
> > + * This function sets the vcm position to the value set by the user
> > + * through v4l2_ctrl_ops s_ctrl handler
> > + * The lens position is gradually moved in units of DW9768_CTRL_STEPS,
> > + * to make the movements smoothly.
> > + */
> > +static int __maybe_unused dw9768_vcm_resume(struct device *dev)
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > + struct dw9768_device *dw9768_dev = sd_to_dw9768_vcm(sd);
> > +
> > + if (!dw9768_dev->power_count)
> > + return 0;
> > +
> > + return dw9768_power_on(dw9768_dev, true);
> > +}
> > +
> > +static const struct i2c_device_id dw9768_id_table[] = {
> > + { DW9768_NAME, 0 },
> > + { { 0 } }
> > +};
> > +MODULE_DEVICE_TABLE(i2c, dw9768_id_table);
> > +
> > +static const struct of_device_id dw9768_of_table[] = {
> > + { .compatible = "dongwoon,dw9768" },
> > + { { 0 } }
> > +};
> > +MODULE_DEVICE_TABLE(of, dw9768_of_table);
> > +
> > +static const struct dev_pm_ops dw9768_pm_ops = {
> > + SET_SYSTEM_SLEEP_PM_OPS(dw9768_vcm_suspend, dw9768_vcm_resume)
> > + SET_RUNTIME_PM_OPS(dw9768_vcm_suspend, dw9768_vcm_resume, NULL)
>
> Okay, so we already provided the callbacks, but we never called
> pm_runtime_get/put().
>
> Also, I'm not sure if we can provide the same callbacks for runtime and
> system PM ops, but I think we could use pm_runtime_force_suspend() and
> pm_runtime_force_resume() as system ones to achieve the same.
>
SET_SYSTEM_SLEEP_PM_OPS would use pm_runtime_force_suspend/resume in
next release.
> Best regards,
> Tomasz
_______________________________________________
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 v4 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Peter Rosin @ 2019-09-02 14:40 UTC (permalink / raw)
To: Eugen.Hristev@microchip.com, wsa@the-dreams.de,
mark.rutland@arm.com, Ludovic.Desroches@microchip.com,
linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, pierre-yves.mordret@st.com,
alexandre.belloni@bootlin.com, robh+dt@kernel.org
In-Reply-To: <b6528812-65d3-6561-38e7-c0545af900d8@microchip.com>
On 2019-09-02 16:15, Eugen.Hristev@microchip.com wrote:
>
>
> On 02.09.2019 13:49, Peter Rosin wrote:
>
>> On 2019-09-02 12:12, Eugen.Hristev@microchip.com wrote:
>>> From: Eugen Hristev <eugen.hristev@microchip.com>
>>>
>>> Some i2c controllers have a built-in digital or analog filter.
>>> This is specifically required depending on the hardware PCB/board.
>>> Some controllers also allow specifying the maximum width of the
>>> spikes that can be filtered. The width length can be specified in nanoseconds.
>>>
>>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>>> ---
>>> Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++++++++++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
>>> index 44efafd..8dbff67 100644
>>> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
>>> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
>>> @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below.
>>> Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
>>> specification.
>>>
>>> +- i2c-analog-filter
>>> + Enable analog filter for i2c lines.
>>> +
>>> +- i2c-digital-filter
>>> + Enable digital filter for i2c lines.
>>> +
>>> +- i2c-filter-width-ns
>>> + Width of spikes which can be filtered by either digital or analog
>>> + filters (i2c-analog-filtr or i2c-digital-filtr). This width is specified
>>
>> filtr -> filter (two instances)
>>
>> What if you want/need to have different bandwidth for the digital and analog
>> filters? After all, this is a generic binding...
>
> Hi Peter,
>
> For our needs, this is enough: the purpose of the filters is to avoid
> noise on the lines, the noise is as big as it is for the digital and for
> the analog filters, since we use an absolute measurement for them. So I
> do not know how useful it would be to make a difference.
I think my gripe is that the description also seems non-generic. Analog
filters never (ok, usually, but I have a hard time seeing how a simple
analog filter can) work in terms of some "width of spikes". That phrasing
seems like something inherent to trivial digital filters. For analog
filters, specifying the bandwidth or cut-off frequency seems much more
appropriate. And bandwidth would work equally well for digital filters,
methinks.
I also think it should be mentioned explicitly that this binding is for
LP filters. I don't think anything else would be useful, but better safe
than sorry...
Hmm, would it be good or bad to specify the bandwidth relative to the
current maximum bus speed?
Cheers,
Peter
> Wolfram, what do you think ?
>
> Eugen
>
>
>>
>> Cheers,
>> Peter
>>
>>> + in nanoseconds.
>>> +
>>> - interrupts
>>> interrupts used by the device.
>>>
>>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] pwm: rockchip: set polarity unconditionally in .get_state()
From: Uwe Kleine-König @ 2019-09-02 14:39 UTC (permalink / raw)
To: Thierry Reding, Heiko Stuebner
Cc: linux-pwm, linux-arm-kernel, linux-rockchip
Don't rely on *state being zero initialized and PWM_POLARITY_NORMAL
being zero. So always assign .polarity.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
drivers/pwm/pwm-rockchip.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 51b96cb7dd25..8eb2db59741d 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -90,10 +90,10 @@ static void rockchip_pwm_get_state(struct pwm_chip *chip,
state->enabled = ((val & enable_conf) == enable_conf) ?
true : false;
- if (pc->data->supports_polarity) {
- if (!(val & PWM_DUTY_POSITIVE))
- state->polarity = PWM_POLARITY_INVERSED;
- }
+ if (pc->data->supports_polarity && !(val & PWM_DUTY_POSITIVE))
+ state->polarity = PWM_POLARITY_INVERSED;
+ else
+ state->polarity = PWM_POLARITY_NORMAL;
clk_disable(pc->pclk);
}
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH ARM64 v4.4 V3 12/44] arm64: cpufeature: Test 'matches' pointer to find the end of the list
From: Mark Rutland @ 2019-09-02 14:27 UTC (permalink / raw)
To: Viresh Kumar
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <617ad445043f040c5ab986b9620b2ba7847b561e.1567077734.git.viresh.kumar@linaro.org>
On Thu, Aug 29, 2019 at 05:03:57PM +0530, Viresh Kumar wrote:
> From: James Morse <james.morse@arm.com>
>
> commit 644c2ae198412c956700e55a2acf80b2541f6aa5 upstream.
>
> CPU feature code uses the desc field as a test to find the end of the list,
> this means every entry must have a description. This generates noise for
> entries in the list that aren't really features, but combinations of them.
> e.g.
> > CPU features: detected feature: Privileged Access Never
> > CPU features: detected feature: PAN and not UAO
>
> These combination features are needed for corner cases with alternatives,
> where cpu features interact.
>
> Change all walkers of the arm64_features[] and arm64_hwcaps[] lists to test
> 'matches' not 'desc', and only print 'desc' if it is non-NULL.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> Reviewed-by : Suzuki K Poulose <suzuki.poulose@arm.com>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> arch/arm64/kernel/cpufeature.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
From looking at my 4.9.y/{meltdown,spectre} banches on kernel.org [1,2],
and chasing the history v4.4..v4.9, there are a number of patches I'd
expect to have alongside this that I don't spot in this series:
* e3661b128e53ee281e1e7c589a5b647890bd6d7c ("arm64: Allow a capability to be checked on a single CPU")
* 8f4137588261d7504f4aa022dc9d1a1fd1940e8e ("arm64: Allow checking of a CPU-local erratum")
* 67948af41f2e6818edeeba5182811c704d484949 ("arm64: capabilities: Handle duplicate entries for a capability")
* edf298cfce47ab7279d03b5203ae2ef3a58e49db ("arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early")
... which IIUC are necessary for big.LITTLE to work correctly.
Have you verified this for big.LITTLE?
Thanks,
Mark.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=stable/4.9.y/meltdown
[2] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=stable/4.9.y/spectre
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index c1eddc07d996..bdb4cd9ffccf 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -744,7 +744,7 @@ static void setup_cpu_hwcaps(void)
> int i;
> const struct arm64_cpu_capabilities *hwcaps = arm64_hwcaps;
>
> - for (i = 0; hwcaps[i].desc; i++)
> + for (i = 0; hwcaps[i].matches; i++)
> if (hwcaps[i].matches(&hwcaps[i]))
> cap_set_hwcap(&hwcaps[i]);
> }
> @@ -754,11 +754,11 @@ void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
> {
> int i;
>
> - for (i = 0; caps[i].desc; i++) {
> + for (i = 0; caps[i].matches; i++) {
> if (!caps[i].matches(&caps[i]))
> continue;
>
> - if (!cpus_have_cap(caps[i].capability))
> + if (!cpus_have_cap(caps[i].capability) && caps[i].desc)
> pr_info("%s %s\n", info, caps[i].desc);
> cpus_set_cap(caps[i].capability);
> }
> @@ -772,7 +772,7 @@ static void enable_cpu_capabilities(const struct arm64_cpu_capabilities *caps)
> {
> int i;
>
> - for (i = 0; caps[i].desc; i++)
> + for (i = 0; caps[i].matches; i++)
> if (caps[i].enable && cpus_have_cap(caps[i].capability))
> /*
> * Use stop_machine() as it schedules the work allowing
> @@ -884,7 +884,7 @@ void verify_local_cpu_capabilities(void)
> return;
>
> caps = arm64_features;
> - for (i = 0; caps[i].desc; i++) {
> + for (i = 0; caps[i].matches; i++) {
> if (!cpus_have_cap(caps[i].capability) || !caps[i].sys_reg)
> continue;
> /*
> @@ -897,7 +897,7 @@ void verify_local_cpu_capabilities(void)
> caps[i].enable(NULL);
> }
>
> - for (i = 0, caps = arm64_hwcaps; caps[i].desc; i++) {
> + for (i = 0, caps = arm64_hwcaps; caps[i].matches; i++) {
> if (!cpus_have_hwcap(&caps[i]))
> continue;
> if (!feature_matches(__raw_read_system_reg(caps[i].sys_reg), &caps[i]))
> --
> 2.21.0.rc0.269.g1a574e7a288b
>
_______________________________________________
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 2/2] of: Let of_for_each_phandle fallback to non-negative cell_count
From: Rob Herring @ 2019-09-02 14:26 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree, Will Deacon, Joerg Roedel, linux-kernel, iommu,
linux-mediatek, kernel, Matthias Brugger, Frank Rowand,
linux-arm-kernel, Robin Murphy
In-Reply-To: <20190824132846.8589-2-u.kleine-koenig@pengutronix.de>
On Sat, Aug 24, 2019 at 03:28:46PM +0200, Uwe Kleine-König wrote:
> Referencing device tree nodes from a property allows to pass arguments.
> This is for example used for referencing gpios. This looks as follows:
>
> gpio_ctrl: gpio-controller {
> #gpio-cells = <2>
> ...
> }
>
> someothernode {
> gpios = <&gpio_ctrl 5 0 &gpio_ctrl 3 0>;
> ...
> }
>
> To know the number of arguments this must be either fixed, or the
> referenced node is checked for a $cells_name (here: "#gpio-cells")
> property and with this information the start of the second reference can
> be determined.
>
> Currently regulators are referenced with no additional arguments. To
> allow some optional arguments without having to change all referenced
> nodes this change introduces a way to specify a default cell_count. So
> when a phandle is parsed we check for the $cells_name property and use
> it as before if present. If it is not present we fall back to
> cells_count if non-negative and only fail if cells_count is smaller than
> zero.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> drivers/of/base.c | 25 +++++++++++++++++--------
> 1 file changed, 17 insertions(+), 8 deletions(-)
Looks fine to me. I can apply with an ack from the iommu folks on patch
1.
Rob
_______________________________________________
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 2/3] dt-bindings: sound: Add Xilinx logicPD-I2S FPGA IP bindings
From: Rob Herring @ 2019-09-02 14:24 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Linux-ALSA, Takashi Iwai, Liam Girdwood,
Mark Brown, alexandre, Thomas Petazzoni, Jaroslav Kysela,
Michal Simek,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190902155113.40b00fa0@xps13>
On Mon, Sep 2, 2019 at 2:51 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Rob,
>
> Thanks for the review, one question below.
>
> Rob Herring <robh@kernel.org> wrote on Mon, 02 Sep 2019 14:39:09 +0100:
>
> > On Fri, Aug 30, 2019 at 11:06:06PM +0200, Miquel Raynal wrote:
> > > Document the logicPD I2S FPGA block bindings in yaml.
> > >
> > > Syntax verified with dt-doc-validate.
> > >
> > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > ---
> > > .../bindings/sound/xlnx,logicpd-i2s.yaml | 57 +++++++++++++++++++
> > > 1 file changed, 57 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml b/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> > > new file mode 100644
> > > index 000000000000..cbff641af199
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/sound/xlnx,logicpd-i2s.yaml
> > > @@ -0,0 +1,57 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/sound/xlnx,logicpd-i2s.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Device-Tree bindings for Xilinx logicPD I2S FPGA block
> > > +
> > > +maintainers:
> > > + - Miquel Raynal <miquel.raynal@bootlin.com>
> > > +
> > > +description: |
> > > + The IP supports I2S playback/capture audio. It acts as a slave and
> > > + clocks should come from the codec. It only supports two channels and
> > > + S16_LE format.
> > > +
> > > +properties:
> > > + compatible:
> > > + items:
> > > + - const: xlnx,logicpd-i2s
> > > +
> > > + reg:
> > > + maxItems: 1
> > > + description:
> > > + Base address and size of the IP core instance.
> > > +
> > > + interrupts:
> > > + minItems: 1
> > > + maxItems: 2
> > > + items:
> > > + - description: tx interrupt
> > > + - description: rx interrupt
> > > + description:
> > > + Either the Tx interruption or the Rx interruption or both.
> >
> > The schema says either tx or both. Doesn't really matter here as it's
> > just numbers.
>
> I see , I'll drop the 'items' entry.
>
> >
> > > +
> > > + interrupt-names:
> > > + minItems: 1
> > > + maxItems: 2
> > > + items:
> > > + - const: tx
> > > + - const: rx
> >
> > But here it does matter.
> >
> > The easiest way to express this is:
> >
> > oneOf:
> > - items:
> > - enum: [ tx, rx ]
> > - items:
> > - const: tx
> > - const: rx
> >
>
> Does this enforce an order? (I don't know if it matters, though, but in
> the bellow example I put the Rx interrupt first).
Yes. It does matter and should be defined what the order it.
Rob
_______________________________________________
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 v4 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Alexandre Belloni @ 2019-09-02 14:22 UTC (permalink / raw)
To: Eugen.Hristev
Cc: mark.rutland, devicetree, wsa, linux-kernel, pierre-yves.mordret,
Ludovic.Desroches, robh+dt, linux-i2c, peda, linux-arm-kernel
In-Reply-To: <b6528812-65d3-6561-38e7-c0545af900d8@microchip.com>
Eugen,
On 02/09/2019 14:15:14+0000, Eugen.Hristev@microchip.com wrote:
> On 02.09.2019 13:49, Peter Rosin wrote:
>
> > On 2019-09-02 12:12, Eugen.Hristev@microchip.com wrote:
> >> From: Eugen Hristev <eugen.hristev@microchip.com>
> >>
> >> Some i2c controllers have a built-in digital or analog filter.
> >> This is specifically required depending on the hardware PCB/board.
> >> Some controllers also allow specifying the maximum width of the
> >> spikes that can be filtered. The width length can be specified in nanoseconds.
> >>
> >> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> >> ---
> >> Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++++++++++
> >> 1 file changed, 11 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
> >> index 44efafd..8dbff67 100644
> >> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
> >> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
> >> @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below.
> >> Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
> >> specification.
> >>
> >> +- i2c-analog-filter
> >> + Enable analog filter for i2c lines.
> >> +
> >> +- i2c-digital-filter
> >> + Enable digital filter for i2c lines.
> >> +
> >> +- i2c-filter-width-ns
> >> + Width of spikes which can be filtered by either digital or analog
> >> + filters (i2c-analog-filtr or i2c-digital-filtr). This width is specified
> >
> > filtr -> filter (two instances)
> >
> > What if you want/need to have different bandwidth for the digital and analog
> > filters? After all, this is a generic binding...
>
> For our needs, this is enough: the purpose of the filters is to avoid
> noise on the lines, the noise is as big as it is for the digital and for
> the analog filters, since we use an absolute measurement for them. So I
> do not know how useful it would be to make a difference.
>
You are adding generic properties so they have to be generic and not
tied to your particular use case.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.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 v5 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Rob Herring @ 2019-09-02 14:20 UTC (permalink / raw)
To: Peng Fan
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
f.fainelli@gmail.com, andre.przywara@arm.com,
jassisinghbrar@gmail.com, linux-kernel@vger.kernel.org,
dl-linux-imx, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <5d6d1b86.1c69fb81.f86b5.3988@mx.google.com>
On Mon, Sep 2, 2019 at 2:39 PM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Aug 28, 2019 at 03:02:58AM +0000, Peng Fan wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
> > actions in software layers running in the EL2 or EL3 exception levels.
> > The term "ARM" here relates to the SMC instruction as part of the ARM
> > instruction set, not as a standard endorsed by ARM Ltd.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../devicetree/bindings/mailbox/arm-smc.yaml | 125 +++++++++++++++++++++
> > 1 file changed, 125 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > new file mode 100644
> > index 000000000000..f8eb28d5e307
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
> > @@ -0,0 +1,125 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: ARM SMC Mailbox Interface
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +description: |
> > + This mailbox uses the ARM smc (secure monitor call) and hvc (hypervisor
> > + call) instruction to trigger a mailbox-connected activity in firmware,
> > + executing on the very same core as the caller. By nature this operation
> > + is synchronous and this mailbox provides no way for asynchronous messages
> > + to be delivered the other way round, from firmware to the OS, but
> > + asynchronous notification could also be supported. However the value of
> > + r0/w0/x0 the firmware returns after the smc call is delivered as a received
> > + message to the mailbox framework, so a synchronous communication can be
> > + established, for a asynchronous notification, no value will be returned.
> > + The exact meaning of both the action the mailbox triggers as well as the
> > + return value is defined by their users and is not subject to this binding.
> > +
> > + One use case of this mailbox is the SCMI interface, which uses shared memory
> > + to transfer commands and parameters, and a mailbox to trigger a function
> > + call. This allows SoCs without a separate management processor (or when
> > + such a processor is not available or used) to use this standardized
> > + interface anyway.
> > +
> > + This binding describes no hardware, but establishes a firmware interface.
> > + Upon receiving an SMC using one of the described SMC function identifiers,
> > + the firmware is expected to trigger some mailbox connected functionality.
> > + The communication follows the ARM SMC calling convention.
> > + Firmware expects an SMC function identifier in r0 or w0. The supported
> > + identifiers are passed from consumers, or listed in the the arm,func-ids
> > + properties as described below. The firmware can return one value in
> > + the first SMC result register, it is expected to be an error value,
> > + which shall be propagated to the mailbox client.
> > +
> > + Any core which supports the SMC or HVC instruction can be used, as long as
> > + a firmware component running in EL3 or EL2 is handling these calls.
> > +
> > +properties:
> > + compatible:
> > + const: arm,smc-mbox
> > +
> > + "#mbox-cells":
> > + const: 1
> > +
> > + arm,num-chans:
> > + description: The number of channels supported.
> > + items:
> > + minimum: 1
> > + maximum: 4096 # Should be enough?
> > +
> > + method:
> > + - enum:
>
> Did you build this with 'make dt_binding_check' as this should be a
> warning. This should not be a list entry (i.e. drop the '-').
>
> > + - smc
> > + - hvc
> > +
> > + transports:
>
> arm,transports
>
> > + - enum:
> > + - mem
> > + - reg
> > +
> > + arm,func-ids:
> > + description: |
> > + An array of 32-bit values specifying the function IDs used by each
> > + mailbox channel. Those function IDs follow the ARM SMC calling
> > + convention standard [1].
> > +
> > + There is one identifier per channel and the number of supported
> > + channels is determined by the length of this array.
> > + $ref: /schemas/types.yaml#/definitions/uint32-array
Also, this doesn't work. You need:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
> > + minItems: 0
> > + maxItems: 4096 # Should be enough?
_______________________________________________
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 03/26] m68k, microblaze: remove ioremap_fullcache
From: Michal Simek @ 2019-09-02 14:16 UTC (permalink / raw)
To: Christoph Hellwig, Arnd Bergmann, Guo Ren, Greentime Hu,
Vincent Chen, Guan Xuetao, x86
Cc: linux-arch, linux-s390, linux-ia64, linux-parisc, linux-sh,
linux-hexagon, linux-xtensa, linux-mips, linux-kernel, linux-m68k,
openrisc, linux-mtd, linux-alpha, sparclinux, nios2-dev,
linux-riscv, linux-snps-arc, linux-arm-kernel
In-Reply-To: <20190817073253.27819-4-hch@lst.de>
[-- Attachment #1.1.1: Type: text/plain, Size: 1977 bytes --]
On 17. 08. 19 9:32, Christoph Hellwig wrote:
> No callers of this function.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/m68k/include/asm/kmap.h | 7 -------
> arch/microblaze/include/asm/io.h | 1 -
> 2 files changed, 8 deletions(-)
>
> diff --git a/arch/m68k/include/asm/kmap.h b/arch/m68k/include/asm/kmap.h
> index aac7f045f7f0..03d904fe6087 100644
> --- a/arch/m68k/include/asm/kmap.h
> +++ b/arch/m68k/include/asm/kmap.h
> @@ -43,13 +43,6 @@ static inline void __iomem *ioremap_wt(unsigned long physaddr,
> return __ioremap(physaddr, size, IOMAP_WRITETHROUGH);
> }
>
> -#define ioremap_fullcache ioremap_fullcache
> -static inline void __iomem *ioremap_fullcache(unsigned long physaddr,
> - unsigned long size)
> -{
> - return __ioremap(physaddr, size, IOMAP_FULL_CACHING);
> -}
> -
> #define memset_io memset_io
> static inline void memset_io(volatile void __iomem *addr, unsigned char val,
> int count)
> diff --git a/arch/microblaze/include/asm/io.h b/arch/microblaze/include/asm/io.h
> index c7968139486f..86c95b2a1ce1 100644
> --- a/arch/microblaze/include/asm/io.h
> +++ b/arch/microblaze/include/asm/io.h
> @@ -40,7 +40,6 @@ extern void iounmap(volatile void __iomem *addr);
>
> extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
> #define ioremap_nocache(addr, size) ioremap((addr), (size))
> -#define ioremap_fullcache(addr, size) ioremap((addr), (size))
> #define ioremap_wc(addr, size) ioremap((addr), (size))
> #define ioremap_wt(addr, size) ioremap((addr), (size))
>
>
Acked-by: Michal Simek <monstr@monstr.eu> (for Microblaze)
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5] perf machine: arm/arm64: Improve completeness for kernel address space
From: Leo Yan @ 2019-09-02 14:15 UTC (permalink / raw)
To: Adrian Hunter
Cc: Song Liu, Mathieu Poirier, Daniel Borkmann, Suzuki Poulouse,
Alexander Shishkin, netdev, coresight, Alexei Starovoitov,
Arnaldo Carvalho de Melo, linux-kernel, clang-built-linux,
Peter Zijlstra, Yonghong Song, Namhyung Kim, bpf, Jiri Olsa,
Martin KaFai Lau, linux-arm-kernel
In-Reply-To: <20190826125105.GA3288@leoy-ThinkPad-X240s>
Hi Adrian,
On Mon, Aug 26, 2019 at 08:51:05PM +0800, Leo Yan wrote:
> Hi Adrian,
>
> On Fri, Aug 16, 2019 at 04:00:02PM +0300, Adrian Hunter wrote:
> > On 16/08/19 4:45 AM, Leo Yan wrote:
> > > Hi Adrian,
> > >
> > > On Thu, Aug 15, 2019 at 02:45:57PM +0300, Adrian Hunter wrote:
> > >
> > > [...]
> > >
> > >>>> How come you cannot use kallsyms to get the information?
> > >>>
> > >>> Thanks for pointing out this. Sorry I skipped your comment "I don't
> > >>> know how you intend to calculate ARM_PRE_START_SIZE" when you reviewed
> > >>> the patch v3, I should use that chance to elaborate the detailed idea
> > >>> and so can get more feedback/guidance before procceed.
> > >>>
> > >>> Actually, I have considered to use kallsyms when worked on the previous
> > >>> patch set.
> > >>>
> > >>> As mentioned in patch set v4's cover letter, I tried to implement
> > >>> machine__create_extra_kernel_maps() for arm/arm64, the purpose is to
> > >>> parse kallsyms so can find more kernel maps and thus also can fixup
> > >>> the kernel start address. But I found the 'perf script' tool directly
> > >>> calls machine__get_kernel_start() instead of running into the flow for
> > >>> machine__create_extra_kernel_maps();
> > >>
> > >> Doesn't it just need to loop through each kernel map to find the lowest
> > >> start address?
> > >
> > > Based on your suggestion, I worked out below change and verified it
> > > can work well on arm64 for fixing up start address; please let me know
> > > if the change works for you?
> >
> > How does that work if take a perf.data file to a machine with a different
> > architecture?
>
> Sorry I delayed so long to respond to your question; I didn't have
> confidence to give out very reasonale answer and this is the main reason
> for delaying.
Could you take chance to review my below replying? I'd like to get
your confirmation before I send out offical patch.
Thanks,
Leo Yan
>
> For your question for taking a perf.data file to a machine with a
> different architecture, we can firstly use command 'perf buildid-list'
> to print out the buildid for kallsyms, based on the dumped buildid we
> can find out the location for the saved kallsyms file; then we can use
> option '--kallsyms' to specify the offline kallsyms file and use the
> offline kallsyms to fixup kernel start address. The detailed commands
> are listed as below:
>
> root@debian:~# perf buildid-list
> 7b36dfca8317ef74974ebd7ee5ec0a8b35c97640 [kernel.kallsyms]
> 56b84aa88a1bcfe222a97a53698b92723a3977ca /usr/lib/systemd/systemd
> 0956b952e9cd673d48ff2cfeb1a9dbd0c853e686 /usr/lib/aarch64-linux-gnu/libm-2.28.so
> [...]
>
> root@debian:~# perf script --kallsyms ~/.debug/\[kernel.kallsyms\]/7b36dfca8317ef74974ebd7ee5ec0a8b35c97640/kallsyms
>
> The amended patch is as below, please review and always welcome
> any suggestions or comments!
>
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index 5734460fc89e..593f05cc453f 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -2672,9 +2672,26 @@ int machine__nr_cpus_avail(struct machine *machine)
> return machine ? perf_env__nr_cpus_avail(machine->env) : 0;
> }
>
> +static int machine__fixup_kernel_start(void *arg,
> + const char *name __maybe_unused,
> + char type,
> + u64 start)
> +{
> + struct machine *machine = arg;
> +
> + type = toupper(type);
> +
> + /* Fixup for text, weak, data and bss sections. */
> + if (type == 'T' || type == 'W' || type == 'D' || type == 'B')
> + machine->kernel_start = min(machine->kernel_start, start);
> +
> + return 0;
> +}
> +
> int machine__get_kernel_start(struct machine *machine)
> {
> struct map *map = machine__kernel_map(machine);
> + char filename[PATH_MAX];
> int err = 0;
>
> /*
> @@ -2696,6 +2713,22 @@ int machine__get_kernel_start(struct machine *machine)
> if (!err && !machine__is(machine, "x86_64"))
> machine->kernel_start = map->start;
> }
> +
> + if (symbol_conf.kallsyms_name != NULL) {
> + strncpy(filename, symbol_conf.kallsyms_name, PATH_MAX);
> + } else {
> + machine__get_kallsyms_filename(machine, filename, PATH_MAX);
> +
> + if (symbol__restricted_filename(filename, "/proc/kallsyms"))
> + goto out;
> + }
> +
> + if (kallsyms__parse(filename, machine, machine__fixup_kernel_start))
> + pr_warning("Fail to fixup kernel start address. skipping...\n");
> +
> +out:
> return err;
> }
>
>
> Thanks,
> Leo Yan
_______________________________________________
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 v4 2/9] dt-bindings: i2c: add bindings for i2c analog and digital filter
From: Eugen.Hristev @ 2019-09-02 14:15 UTC (permalink / raw)
To: peda, wsa, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
In-Reply-To: <9a9c209c-2fb8-0a4c-4e0a-b04fefda3360@axentia.se>
On 02.09.2019 13:49, Peter Rosin wrote:
> On 2019-09-02 12:12, Eugen.Hristev@microchip.com wrote:
>> From: Eugen Hristev <eugen.hristev@microchip.com>
>>
>> Some i2c controllers have a built-in digital or analog filter.
>> This is specifically required depending on the hardware PCB/board.
>> Some controllers also allow specifying the maximum width of the
>> spikes that can be filtered. The width length can be specified in nanoseconds.
>>
>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>> ---
>> Documentation/devicetree/bindings/i2c/i2c.txt | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt
>> index 44efafd..8dbff67 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c.txt
>> @@ -55,6 +55,17 @@ wants to support one of the below features, it should adapt the bindings below.
>> Number of nanoseconds the SDA signal takes to fall; t(f) in the I2C
>> specification.
>>
>> +- i2c-analog-filter
>> + Enable analog filter for i2c lines.
>> +
>> +- i2c-digital-filter
>> + Enable digital filter for i2c lines.
>> +
>> +- i2c-filter-width-ns
>> + Width of spikes which can be filtered by either digital or analog
>> + filters (i2c-analog-filtr or i2c-digital-filtr). This width is specified
>
> filtr -> filter (two instances)
>
> What if you want/need to have different bandwidth for the digital and analog
> filters? After all, this is a generic binding...
Hi Peter,
For our needs, this is enough: the purpose of the filters is to avoid
noise on the lines, the noise is as big as it is for the digital and for
the analog filters, since we use an absolute measurement for them. So I
do not know how useful it would be to make a difference.
Wolfram, what do you think ?
Eugen
>
> Cheers,
> Peter
>
>> + in nanoseconds.
>> +
>> - interrupts
>> interrupts used by the device.
>>
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
_______________________________________________
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 v4 1/9] dt-bindings: i2c: at91: add new compatible
From: Eugen.Hristev @ 2019-09-02 14:12 UTC (permalink / raw)
To: peda, wsa, mark.rutland, Ludovic.Desroches, linux-i2c, devicetree,
linux-arm-kernel, linux-kernel, pierre-yves.mordret,
alexandre.belloni, robh+dt
In-Reply-To: <47d618da-263f-199c-3cc6-35e8f8c6015d@axentia.se>
On 02.09.2019 13:44, Peter Rosin wrote:
>
> On 2019-09-02 12:11, Eugen.Hristev@microchip.com wrote:
>> From: Eugen Hristev <eugen.hristev@microchip.com>
>>
>> Add compatible for new Microchip SoC, sam9x60
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>> ---
>> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
>> index b7cec17..2210f43 100644
>> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
>> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
>> @@ -3,7 +3,8 @@ I2C for Atmel platforms
>> Required properties :
>> - compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
>> "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c",
>> - "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c" or "atmel,sama5d2-i2c"
>> + "atmel,at91sam9x5-i2c", "atmel,sama5d4-i2c", "atmel,sama5d2-i2c" or
>> + "microchip,sam9x60-i2c"
>
> IIUC, this list should ideally be reformatted with one compatible per line.
>
> Side note; unfortunate naming with SAM9x60, when there is a preexisting 9260
> fitting the "wildcard" (AFAICT, it's not a wildcard in this case, but it sure
> looks like one).
>
Yes, this is a separate SoC. It is named SAM9X60 and not related to old
9260
Reformatting the list would be useful perhaps in a different cosmetic
patch ?
> Cheers,
> Peter
>
>> - reg: physical base address of the controller and length of memory mapped
>> region.
>> - interrupts: interrupt number to the cpu.
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
_______________________________________________
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