Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2 01/11] asm-generic: add dma_zone_size
From: Nicolas Saenz Julienne @ 2019-08-26 13:46 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: catalin.marinas, linux-mm, linux-riscv, will, m.szyprowski,
	linux-arch, f.fainelli, frowand.list, devicetree, Arnd Bergmann,
	marc.zyngier, robh+dt, linux-rpi-kernel, linux-arm-kernel, phill,
	mbrugger, eric, linux-kernel, iommu, wahrenst, akpm, Robin Murphy
In-Reply-To: <20190826070939.GD11331@lst.de>


[-- Attachment #1.1: Type: text/plain, Size: 1724 bytes --]

On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote:
> On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote:
> > Some architectures have platform specific DMA addressing limitations.
> > This will allow for hardware description code to provide the constraints
> > in a generic manner, so as for arch code to properly setup it's memory
> > zones and DMA mask.
> 
> I know this just spreads the arm code, but I still kinda hate it.

Rob's main concern was finding a way to pass the constraint from HW definition
to arch without widening fdt's architecture specific function surface. I'd say
it's fair to argue that having a generic mechanism makes sense as it'll now
traverse multiple archs and subsystems.

I get adding globals like this is not very appealing, yet I went with it as it
was the easier to integrate with arm's code. Any alternative suggestions?

> MAX_DMA_ADDRESS is such an oddly defined concepts.  We have the mm
> code that uses it to start allocating after the dma zones, but
> I think that would better be done using a function returning
> 1 << max(zone_dma_bits, 32) or so.  Then we have about a handful
> of drivers using it that all seem rather bogus, and one of which
> I think are usable on arm64.

Is it safe to assume DMA limitations will always be a power of 2? I ask as RPi4
kinda isn't: ZONE_DMA is 0x3c000000 bytes big, I'm approximating the zone mask
to 30 as [0x3c000000 0x3fffffff] isn't defined as memory so it's unlikely that
we´ll encounter buffers there. But I don't know how it could affect mm
initialization code.

This also rules out 'zone_dma_bits' as a mechanism to pass ZONE_DMA's size from
HW definition code to arch's.


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 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 v4 01/14] dt-bindings: Add binding for MT2712 MIPI-CSI2
From: Sakari Ailus @ 2019-08-26 14:05 UTC (permalink / raw)
  To: Stu Hsieh
  Cc: Mark Rutland, devicetree, srv_heupstream,
	Linux Kernel Mailing List, Tomasz Figa, Matthias Brugger,
	Rob Herring, moderated list:ARM/Mediatek SoC support, CK Hu,
	Mauro Carvalho Chehab,
	list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
	Linux Media Mailing List
In-Reply-To: <CAAFQd5DDE-L7mW8sTXVYOTLZ8yi3+X6Q3O73fJ61e1aUoeddgg@mail.gmail.com>

On Mon, Jun 10, 2019 at 04:58:02PM +0900, Tomasz Figa wrote:
> On Mon, Jun 10, 2019 at 4:51 PM CK Hu <ck.hu@mediatek.com> wrote:
> >
> > Hi, Tomasz:
> >
> > On Mon, 2019-06-10 at 12:32 +0900, Tomasz Figa wrote:
> > > Hi CK, Stu,
> > >
> > > On Mon, Jun 10, 2019 at 11:34 AM CK Hu <ck.hu@mediatek.com> wrote:
> > > >
> > > > Hi, Stu:
> > > >
> > > > "mediatek,mt2712-mipicsi" and "mediatek,mt2712-mipicsi-common" have many
> > > > common part with "mediatek,mt8183-seninf", and I've a discussion in [1],
> > > > so I would like these two to be merged together.
> > > >
> > > > [1] https://patchwork.kernel.org/patch/10979131/
> > > >
> > >
> > > Thanks CK for spotting this.
> > >
> > > I also noticed that the driver in fact handles two hardware blocks at
> > > the same time - SenInf and CamSV. Unless the architecture is very
> > > different from MT8183, I'd suggest splitting it.
> > >
> > > On a general note, the MT8183 SenInf driver has received several
> > > rounds of review comments already, but I couldn't find any comments
> > > posted for this one.
> > >
> > > Given the two aspects above and also based on my quick look at code
> > > added by this series, I'd recommend adding MT2712 support on top of
> > > the MT8183 series.
> >
> > In [1], "mediatek,mt8183-seninf" use one device to control multiple csi
> > instance, so it duplicate many register definition. In [2], one
> > "mediatek,mt2712-mipicsi" device control one csi instance, so there are
> > multiple device and the register definition does not duplicate.
> 
> I guess we didn't catch that in the review yet. It should be fixed.
> 
> > You
> > recommend adding MT2712 support on top of the MT8183 series, do you mean
> > that "mediatek,mt2712-mipicsi" should use one device to control multiple
> > csi instance and duplicate the register setting?
> 
> There are some aspects of MT8183 series that are done better than the
> MT2712 series, but apparently there are also some better aspects in
> MT2712. We should take the best aspects of both series. :)

Stu: Are the two devices similar enough or not; does this look like a
feasible approach to you?

-- 
Sakari Ailus

_______________________________________________
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 00/15] Improvements and fixes for mxsfb DRM driver
From: Stefan Agner @ 2019-08-26 14:35 UTC (permalink / raw)
  To: Guido Günther
  Cc: Marek Vasut, Mark Rutland, Pengutronix Kernel Team, devicetree,
	David Airlie, Fabio Estevam, Sascha Hauer, linux-kernel,
	dri-devel, Rob Herring, NXP Linux Team, Daniel Vetter,
	Robert Chiras, Shawn Guo, linux-arm-kernel
In-Reply-To: <20190826120548.GA14316@bogon.m.sigxcpu.org>

On 2019-08-26 14:05, Guido Günther wrote:
> Hi,
> On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
>> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
>> and 8QXP). Following, are the new features added and fixes from this
>> patch-set:
> 
> I've applied this whole series on top of my NWL work and it looks good
> with a DSI panel. Applying the whole series also fixes an issue where
> after unblank the output was sometimes shifted about half a screen width
> to the right (which didn't happen with DCSS). So at least from the parts
> I could test:
> 
>   Tested-by: Guido Günther <agx@sigxcpu.org> 
> 
> for the whole thing.

Thanks for testing! What SoC did you use? I think it would be good to
also give this a try on i.MX 7 or i.MX 6ULL before merging.

--
Stefan


> Cheers,
>  -- Guido
>>
>> 1. Add support for drm_bridge
>> On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
>> display connector, where an LCD panel can be attached, but instead it is
>> connected to DSI controller. Since this DSI stands between the display
>> controller (eLCDIF) and the physical connector, the DSI can be implemented
>> as a DRM bridge. So, in order to be able to connect the mxsfb driver to
>> the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
>> driver (the actual driver for the eLCDIF block).
>>
>> 2. Add support for additional pixel formats
>> Some of the pixel formats needed by Android were not implemented in this
>> driver, but they were actually supported. So, add support for them.
>>
>> 3. Add support for horizontal stride
>> Having support for horizontal stride allows the use of eLCDIF with a GPU
>> (for example) that can only output resolution sizes multiple of a power of
>> 8. For example, 1080 is not a power of 16, so in order to support 1920x1080
>> output from GPUs that can produce linear buffers only in sizes multiple to 16,
>> this feature is needed.
>>
>> 3. Few minor features and bug-fixing
>> The addition of max-res DT property was actually needed in order to limit
>> the bandwidth usage of the eLCDIF block. This is need on systems where
>> multiple display controllers are presend and the memory bandwidth is not
>> enough to handle all of them at maximum capacity (like it is the case on
>> 8MQ, where there are two display controllers: DCSS and eLCDIF).
>> The rest of the patches are bug-fixes.
>>
>> v3:
>> - Removed the max-res property patches and added support for
>>   max-memory-bandwidth property, as it is also implemented in other drivers
>> - Removed unnecessary drm_vblank_off in probe
>>
>> v2:
>> - Collected Tested-by from Guido
>> - Split the first patch, which added more than one feature into relevant
>>   patches, explaining each feature added
>> - Also split the second patch into more patches, to differentiate between
>>   the feature itself (additional pixel formats support) and the cleanup
>>   of the register definitions for a better representation (guido)
>> - Included a patch submitted by Guido, while he was testing my patch-set
>>
>> Guido Günther (1):
>>   drm/mxsfb: Read bus flags from bridge if present
>>
>> Mirela Rabulea (1):
>>   drm/mxsfb: Signal mode changed when bpp changed
>>
>> Robert Chiras (13):
>>   drm/mxsfb: Update mxsfb to support a bridge
>>   drm/mxsfb: Add defines for the rest of registers
>>   drm/mxsfb: Reset vital registers for a proper initialization
>>   drm/mxsfb: Update register definitions using bit manipulation defines
>>   drm/mxsfb: Update mxsfb with additional pixel formats
>>   drm/mxsfb: Fix the vblank events
>>   drm/mxsfb: Add max-memory-bandwidth property for MXSFB
>>   dt-bindings: display: Add max-memory-bandwidth property for mxsfb
>>   drm/mxsfb: Update mxsfb to support LCD reset
>>   drm/mxsfb: Improve the axi clock usage
>>   drm/mxsfb: Clear OUTSTANDING_REQS bits
>>   drm/mxsfb: Add support for horizontal stride
>>   drm/mxsfb: Add support for live pixel format change
>>
>>  .../devicetree/bindings/display/mxsfb.txt          |   5 +
>>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c                 | 287 ++++++++++++++++++---
>>  drivers/gpu/drm/mxsfb/mxsfb_drv.c                  | 203 +++++++++++++--
>>  drivers/gpu/drm/mxsfb/mxsfb_drv.h                  |  12 +-
>>  drivers/gpu/drm/mxsfb/mxsfb_out.c                  |  26 +-
>>  drivers/gpu/drm/mxsfb/mxsfb_regs.h                 | 193 +++++++++-----
>>  6 files changed, 589 insertions(+), 137 deletions(-)
>>
>> --
>> 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

* [PATCH] drm/meson: vclk: use the correct G12A frac max value
From: Neil Armstrong @ 2019-08-26 14:46 UTC (permalink / raw)
  To: dri-devel; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong

When calculating the HDMI PLL settings for a DMT mode PHY frequency,
use the correct max fractional PLL value for G12A VPU.

With this fix, we can finally setup the 1024x76-60 mode.

Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/gpu/drm/meson/meson_vclk.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_vclk.c b/drivers/gpu/drm/meson/meson_vclk.c
index ac491a781952..f690793ae2d5 100644
--- a/drivers/gpu/drm/meson/meson_vclk.c
+++ b/drivers/gpu/drm/meson/meson_vclk.c
@@ -638,13 +638,18 @@ static bool meson_hdmi_pll_validate_params(struct meson_drm *priv,
 		if (frac >= HDMI_FRAC_MAX_GXBB)
 			return false;
 	} else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXM) ||
-		   meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXL) ||
-		   meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
+		   meson_vpu_is_compatible(priv, VPU_COMPATIBLE_GXL)) {
 		/* Empiric supported min/max dividers */
 		if (m < 106 || m > 247)
 			return false;
 		if (frac >= HDMI_FRAC_MAX_GXL)
 			return false;
+	} else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A)) {
+		/* Empiric supported min/max dividers */
+		if (m < 106 || m > 247)
+			return false;
+		if (frac >= HDMI_FRAC_MAX_G12A)
+			return false;
 	}
 
 	return true;
-- 
2.22.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 0/2] coresight: Add barrier packet when moving offset forward
From: Mathieu Poirier @ 2019-08-26 14:59 UTC (permalink / raw)
  To: Yabin Cui
  Cc: Suzuki K Poulose, Alexander Shishkin, Linux Kernel Mailing List,
	Mike Leach, Leo Yan, linux-arm-kernel
In-Reply-To: <20190824003002.87657-1-yabinc@google.com>

Hi Yabin,

On Fri, 23 Aug 2019 at 18:30, Yabin Cui <yabinc@google.com> wrote:
>
> Thanks for fixing this problem. I didn't realize it because I usually use a
> buffer size >= the default ETR buffer size, which is harder to reproduce the
> problem.
> The patches LGTM, maybe you also want to fix the problem commented by Leo Yan.

I will look into the issue reported by Leo later today.

> I tested the patches by recording etm data with a buffer size smaller than the
> default ETR buffer size. Then I saw barrier packets when decoding with OpenCSD.
> And I could decode successfully without error message.

Can I add your Tested-by ?

_______________________________________________
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 3/7] media: aspeed-video: address a protential usage of an unit var
From: Eddie James @ 2019-08-26 15:12 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Linux Media Mailing List
  Cc: linux-aspeed, Andrew Jeffery, openbmc, Eddie James,
	Mauro Carvalho Chehab, linux-arm-kernel
In-Reply-To: <7c85f7dc159927a7316dc13f52697f157fb6e2bd.1566502743.git.mchehab+samsung@kernel.org>


On 8/22/19 2:39 PM, Mauro Carvalho Chehab wrote:
> While this might not occur in practice, if the device is doing
> the right thing, it would be teoretically be possible to have
> both hsync_counter and vsync_counter negatives.
>
> If this ever happen, ctrl will be undefined, but the driver
> will still call:
>
> 	aspeed_video_update(video, VE_CTRL, 0, ctrl);
>
> Change the code to prevent this to happen.
>
> This was warned by cppcheck:
>
> 	[drivers/media/platform/aspeed-video.c:653]: (error) Uninitialized variable: ctrl


Thanks Mauro.


Reviewed-by: Eddie James <eajames@linux.ibm.com>


>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
>   drivers/media/platform/aspeed-video.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/aspeed-video.c b/drivers/media/platform/aspeed-video.c
> index f899ac3b4a61..4ef37cfc8446 100644
> --- a/drivers/media/platform/aspeed-video.c
> +++ b/drivers/media/platform/aspeed-video.c
> @@ -630,7 +630,7 @@ static void aspeed_video_check_and_set_polarity(struct aspeed_video *video)
>   	}
>   
>   	if (hsync_counter < 0 || vsync_counter < 0) {
> -		u32 ctrl;
> +		u32 ctrl = 0;
>   
>   		if (hsync_counter < 0) {
>   			ctrl = VE_CTRL_HSYNC_POL;
> @@ -650,7 +650,8 @@ static void aspeed_video_check_and_set_polarity(struct aspeed_video *video)
>   				V4L2_DV_VSYNC_POS_POL;
>   		}
>   
> -		aspeed_video_update(video, VE_CTRL, 0, ctrl);
> +		if (ctrl)
> +			aspeed_video_update(video, VE_CTRL, 0, ctrl);
>   	}
>   }
>   

_______________________________________________
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] bus: imx-weim: remove __init from 2 functions
From: Nathan Chancellor @ 2019-08-26 15:15 UTC (permalink / raw)
  To: Ilie Halip
  Cc: clang-built-linux, Sascha Hauer, Shawn Guo, linux-kernel,
	linux-arm-kernel
In-Reply-To: <20190826095828.8948-1-ilie.halip@gmail.com>

On Mon, Aug 26, 2019 at 12:58:28PM +0300, Ilie Halip wrote:
> A previous commit removed __init from weim_probe(), but this attribute is
> still present for other functions called from it. Thus, these warnings
> are triggered:
>     WARNING: Section mismatch in reference from the function weim_probe() to the function .init.text:imx_weim_gpr_setup()
>     WARNING: Section mismatch in reference from the function weim_probe() to the function .init.text:weim_timing_setup()
> 
> Remove the __init attribute from these functions as well, since they
> don't seem to be used anywhere else.
> 
> Signed-off-by: Ilie Halip <ilie.halip@gmail.com>
> Reported-by: "kernelci.org bot" <bot@kernelci.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: clang-built-linux@googlegroups.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org

Reviewed-by: Nathan Chancellor <natechancellor@gmail.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: [RESEND PATCHv4 1/1] drivers/amba: add reset control to amba bus probe
From: Dinh Nguyen @ 2019-08-26 15:27 UTC (permalink / raw)
  To: Philipp Zabel, Linus Walleij
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	Daniel Thompson, Tony Luck, Manivannan Sadhasivam, Kees Cook,
	Rob Herring, Anton Vorontsov, Russell King,
	linux-kernel@vger.kernel.org, Colin Cross, Frank Rowand,
	Linux ARM
In-Reply-To: <1566809829.3842.4.camel@pengutronix.de>

Hi Philipp,

On 8/26/19 3:57 AM, Philipp Zabel wrote:
> Hi Dinh, Linus,
> 
> On Fri, 2019-08-23 at 10:42 -0500, Dinh Nguyen wrote:
>>
>> On 8/23/19 4:19 AM, Linus Walleij wrote:
>>> On Tue, Aug 20, 2019 at 4:58 PM Dinh Nguyen <dinguyen@kernel.org> wrote:
>>>
>>>> @@ -401,6 +402,26 @@ static int amba_device_try_add(struct amba_device *dev, struct resource *parent)
>>>>         ret = amba_get_enable_pclk(dev);
>>>>         if (ret == 0) {
>>>>                 u32 pid, cid;
>>>> +               int count;
>>>> +               struct reset_control *rstc;
>>>> +
>>>> +               /*
>>>> +                * Find reset control(s) of the amba bus and de-assert them.
>>>> +                */
>>>> +               count = reset_control_get_count(&dev->dev);
> 
> The reset_control_get_count() inline stub returns -ENOENT, so the
> compiler can throw away the complete loop.
> 
>>>> +               while (count > 0) {
>>>> +                       rstc = of_reset_control_get_shared_by_index(dev->dev.of_node, count - 1);
> 
> Since resets are looked up with of_reset_control_get, I'd use
> of_reset_control_get_count() above for consistency. But see below:
> 

reset_control_get_count() ultimately calls of_reset_control_get_count()
and it looks like of_reset_control_get_count() is not exported.

>>>> +                       if (IS_ERR(rstc)) {
>>>> +                               if (PTR_ERR(rstc) == -EPROBE_DEFER)
>>>> +                                       ret = -EPROBE_DEFER;
>>>> +                               else
>>>> +                                       dev_err(&dev->dev, "Can't get amba reset!\n");
>>>> +                               break;
>>>> +                       }
>>>> +                       reset_control_deassert(rstc);
>>>> +                       reset_control_put(rstc);
>>>> +                       count--;
>>>> +               }
> 
> It looks like the order of deassertions is irrelevant. If so,
> You can use of_reset_control_array_get() to simplify this:
> 
> +		rstc = of_reset_control_array_get_optional_shared(dev->dev.of_node);
> +		if (IS_ERR(rstc)) {
> +			if (PTR_ERR(rstc) != -EPROBE_DEFER)
> +				dev_err(&dev->dev, "Can't get amba reset!\n");
> +			return PTR_ERR(rstc);
> +		}
> +		reset_control_deassert(rstc);
> +		reset_control_put(rstc);
> 

Thanks for the review! I'll post v5 shortly.

Dinh

_______________________________________________
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 PATCH 5/7] arm64: smp: use generic SMP stop common code
From: Christoph Hellwig @ 2019-08-26 15:32 UTC (permalink / raw)
  To: Cristian Marussi
  Cc: linux-arch, mark.rutland, peterz, catalin.marinas, linux-kernel,
	takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
	dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-6-cristian.marussi@arm.com>

> +config ARCH_USE_COMMON_SMP_STOP
> +	def_bool y if SMP

The option belongs into common code and the arch code shoud only
select it.

_______________________________________________
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 PATCH 0/7] Unify SMP stop generic logic to common code
From: Christoph Hellwig @ 2019-08-26 15:34 UTC (permalink / raw)
  To: Cristian Marussi
  Cc: linux-arch, mark.rutland, peterz, catalin.marinas, linux-kernel,
	takahiro.akashi, james.morse, hidehiro.kawai.ez, tglx, will,
	dave.martin, linux-arm-kernel
In-Reply-To: <20190823115720.605-1-cristian.marussi@arm.com>

On Fri, Aug 23, 2019 at 12:57:13PM +0100, Cristian Marussi wrote:
> An architecture willing to rely on this SMP common logic has to define its
> own helpers and set CONFIG_ARCH_USE_COMMON_SMP_STOP=y.
> The series wire this up for arm64.
> 
> Behaviour is not changed for architectures not adopting this new common
> logic.

Seens like this common code only covers arm64.  I think we should
generally have at least two users for common code.

_______________________________________________
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/3] perf: imx8_ddr_perf: add AXI ID filter support
From: Frank Li @ 2019-08-26 15:36 UTC (permalink / raw)
  To: Joakim Zhang, Mark Rutland
  Cc: will@kernel.org, robin.murphy@arm.com, dl-linux-imx,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB7PR04MB4618D2474D4A3574118F07AFE6A10@DB7PR04MB4618.eurprd04.prod.outlook.com>



> -----Original Message-----
> From: Joakim Zhang
> Sent: Monday, August 26, 2019 2:12 AM
> To: Mark Rutland <mark.rutland@arm.com>
> Cc: robin.murphy@arm.com; will@kernel.org; Frank Li <frank.li@nxp.com>;
> linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter support
> 
> 
> > -----Original Message-----
> > From: Mark Rutland <mark.rutland@arm.com>
> > Sent: 2019年8月23日 20:57
> > To: Joakim Zhang <qiangqing.zhang@nxp.com>
> > Cc: robin.murphy@arm.com; will@kernel.org; Frank Li
> > <frank.li@nxp.com>; linux-arm-kernel@lists.infradead.org; dl-linux-imx
> > <linux-imx@nxp.com>
> > Subject: Re: [PATCH V5 1/3] perf: imx8_ddr_perf: add AXI ID filter
> > support
> >
> > On Thu, Aug 08, 2019 at 06:45:29AM +0000, Joakim Zhang wrote:
> > > AXI filtering is used by CSV modes 0x41 and 0x42 to count reads or
> > > writes with an ARID or AXID matching filter setting. Granularity is
> > > at subsystem level. Implementation does not allow filtring between
> > > masters within a subsystem. Filter is defined with 2 configuration registers.
> > >
> > > --AXI_ID defines AxID matching value --AXI_MASKING defines which
> > > bits of AxID are meaningful for the matching
> > >
> > > When non-masked bits are matching corresponding AXI_ID bits then
> > > counter is incremented. This filter allows counting read or write
> > > access from a subsystem or multiple subsystems.
> > >
> > > Perf counter is incremented if AxID && AXI_MASKING == AXI_ID &&
> > > AXI_MASKING
> >
> > Just to check, the filter does not affect other events, right?
> 
> [Joakim] Yes, this filter is only for events 0x41 and 0x42.
> 
> > >
> > > AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance
> > counter.
> > >
> > > Read and write AXI ID filter should write same value to DPCR1 if
> > > want to specify at the same time as this filter is shared between counters.
> > >
> > > e.g.
> > > perf stat -a -e
> > >
> > imx8_ddr0/axi-id-read,axi_id=0xMMMMDDDD/,imx8_ddr0/axi-id-write,axi_id
> > > =0xMMMMDDDD/ cmd
> > > MMMM: AXI_MASKING
> > > DDDD: AXI_ID
> >
> > You might want to expose this to userspace as two fields:
> >
> > 	axi_id=DDDD
> > 	axi_mask=MMMM
> >
> > ... where axi_mask is inverted (i.e. set bits are bits to ignore), so
> > that the user can just specify axi_id to monitor a specific id, rather
> > than having to specifiy axi_id=0xffff<id>.
> 
> [Joakim] No, axi_mask is not inverted, should specify axi_id = 0xffff<id> for the
> particular AXI ID. I will improve the commit message.
> 		0: corresponding bit is masked
> 		1: corresponding bit is not masked, i.e. used to do the matching
> 

 [Frank Li] Joakim,  mark's means is that revert it at your driver.
Most case user just want to filter a AXID. For example 0x12

If you revert mask at driver,  user just need input axi_id = 0x12 instead of axi_id=0xffff0012.


> > >
> > > ChangeLog:
> > > V1 -> V2:
> > > 	* add error log if user specifies read/write AXI ID filter at
> > > 	the same time.
> > > 	* of_device_get_match_data() instead of of_match_device(), and
> > > 	remove the check of return value.
> > > V2 -> V3:
> > > 	* move the AXI ID check to event_add().
> > > 	* add support for same value of axi_id.
> > > V3 -> V4:
> > > 	* move the AXI ID check to event_init().
> > > V4 -> V5:
> > > 	* reject event group if AXI ID not consistent in event_init().
> > >
> > > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > ---
> > >  drivers/perf/fsl_imx8_ddr_perf.c | 63
> > > +++++++++++++++++++++++++++++++-
> > >  1 file changed, 61 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/perf/fsl_imx8_ddr_perf.c
> > > b/drivers/perf/fsl_imx8_ddr_perf.c
> > > index 63fe21600072..f25cf5cbe156 100644
> > > --- a/drivers/perf/fsl_imx8_ddr_perf.c
> > > +++ b/drivers/perf/fsl_imx8_ddr_perf.c
> > > @@ -42,9 +42,22 @@
> > >
> > >  static DEFINE_IDA(ddr_ida);
> > >
> > > +/* DDR Perf hardware feature */
> > > +#define DDR_CAP_AXI_ID_FILTER		0x1	/* support AXI ID filter
> */
> > > +
> > > +struct fsl_ddr_devtype_data {
> > > +	unsigned int quirks;	/* quirks needed for different DDR Perf core */
> > > +};
> > > +
> > > +static const struct fsl_ddr_devtype_data imx8_devtype_data;
> > > +
> > > +static const struct fsl_ddr_devtype_data imx8m_devtype_data = {
> > > +	.quirks = DDR_CAP_AXI_ID_FILTER,
> > > +};
> > > +
> > >  static const struct of_device_id imx_ddr_pmu_dt_ids[] = {
> > > -	{ .compatible = "fsl,imx8-ddr-pmu",},
> > > -	{ .compatible = "fsl,imx8m-ddr-pmu",},
> > > +	{ .compatible = "fsl,imx8-ddr-pmu", .data = &imx8_devtype_data},
> > > +	{ .compatible = "fsl,imx8m-ddr-pmu", .data = &imx8m_devtype_data},
> > >  	{ /* sentinel */ }
> > >  };
> >
> > Are new DDR PMUs going to lack this feature?
> >
> > If all PMUs the driver supports have it, then we don't need this
> > quirk/feature list.
> >
> > That would make the subsequent code a bit nicer, as all the filtering
> > code would lose a level of indentation.
> 
> [Joakim] This feature may drop, some coming SOCs will improve this AXI ID
> filtering, let it can filter from different ID separately, and ang other extensions.
> 
> > >
> > > @@ -57,6 +70,7 @@ struct ddr_pmu {
> > >  	struct perf_event *events[NUM_COUNTERS];
> > >  	int active_events;
> > >  	enum cpuhp_state cpuhp_state;
> > > +	const struct fsl_ddr_devtype_data *devtype_data;
> > >  	int irq;
> > >  	int id;
> > >  };
> > > @@ -128,6 +142,8 @@ static struct attribute *ddr_perf_events_attrs[] = {
> > >  	IMX8_DDR_PMU_EVENT_ATTR(refresh, 0x37),
> > >  	IMX8_DDR_PMU_EVENT_ATTR(write, 0x38),
> > >  	IMX8_DDR_PMU_EVENT_ATTR(raw-hazard, 0x39),
> > > +	IMX8_DDR_PMU_EVENT_ATTR(axi-id-read, 0x41),
> > > +	IMX8_DDR_PMU_EVENT_ATTR(axi-id-write, 0x42),
> > >  	NULL,
> > >  };
> > >
> > > @@ -137,9 +153,11 @@ static struct attribute_group
> > > ddr_perf_events_attr_group = {  };
> > >
> > >  PMU_FORMAT_ATTR(event, "config:0-7");
> > > +PMU_FORMAT_ATTR(axi_id, "config1:0-31");
> > >
> > >  static struct attribute *ddr_perf_format_attrs[] = {
> > >  	&format_attr_event.attr,
> > > +	&format_attr_axi_id.attr,
> > >  	NULL,
> > >  };
> > >
> > > @@ -189,6 +207,16 @@ static u32 ddr_perf_read_counter(struct ddr_pmu
> > *pmu, int counter)
> > >  	return readl_relaxed(pmu->base + COUNTER_READ + counter * 4);  }
> > >
> > > +static bool ddr_perf_is_filtered(struct perf_event *event) {
> > > +	return event->attr.config == 0x41 || event->attr.config == 0x42; }
> > > +
> > > +static u32 ddr_perf_filter_val(struct perf_event *event) {
> > > +	return event->attr.config1;
> > > +}
> > > +
> >
> > Let's add another helper:
> >
> > static bool ddr_perf_filters_compatible(struct perf_event *a,
> > 					struct perf_event *b)
> > {
> > 	if (!ddr_perf_is_filtered(a))
> > 		return true;
> > 	if (!ddr_perf_is_filtered(b))
> > 		return true;
> > 	return ddr_perf_filter_val(a) == ddr_perf_filter_val(b); }
> >
> > >  static int ddr_perf_event_init(struct perf_event *event)  {
> > >  	struct ddr_pmu *pmu = to_ddr_pmu(event->pmu); @@ -215,6 +243,18
> > @@
> > > static int ddr_perf_event_init(struct perf_event *event)
> > >  			!is_software_event(event->group_leader))
> > >  		return -EINVAL;
> > >
> > > +	if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > +		bool is_filtered = ddr_perf_is_filtered(event);
> > > +		u32 filter_val = ddr_perf_filter_val(event);
> > > +
> > > +		for_each_sibling_event(sibling, event->group_leader) {
> > > +			if (is_filtered && ddr_perf_is_filtered(sibling) &&
> > > +			    ddr_perf_filter_val(sibling) != filter_val) {
> > > +				return -EINVAL;
> > > +			}
> > > +		}
> > > +	}
> >
> > ... so this can be:
> >
> > 	if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > 		if (!ddr_perf_filters_compatible(event, event->group_leader))
> > 			return -EINVAL;
> > 		for_each_sibling_event(sibling, event->group_leader) {
> > 			if (!ddr_perf_filters_compatible(event, sibling))
> > 				return -EINVAL;
> > 		}
> > 	}
> 
> [Joakim] Got it.
> 
> > Note: that checks group_leader, which you mised above. When the event
> > is the group leader, it's trivially compatible with itself, so we
> > don't need a special case there.
> >
> > > +
> > >  	for_each_sibling_event(sibling, event->group_leader) {
> > >  		if (sibling->pmu != event->pmu &&
> > >  				!is_software_event(sibling))
> > > @@ -288,6 +328,23 @@ static int ddr_perf_event_add(struct perf_event
> > *event, int flags)
> > >  	int counter;
> > >  	int cfg = event->attr.config;
> > >
> > > +	if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > > +		int i;
> > > +		bool is_filtered = ddr_perf_is_filtered(event);
> > > +		u32 filter_val = ddr_perf_filter_val(event);
> > > +
> > > +		for (i = 1; i < NUM_COUNTERS; i++) {
> > > +			if (is_filtered && pmu->events[i] &&
> > > +			    ddr_perf_is_filtered(pmu->events[i]) &&
> > > +			    ddr_perf_filter_val(pmu->events[i]) != filter_val) {
> > > +				dev_dbg(pmu->dev, "Contradictory axi id filter
> value\n");
> > > +				return -EINVAL;
> > > +			}
> > > +		}
> >
> > ... and likewise:
> >
> > 	if (pmu->devtype_data->quirks & DDR_CAP_AXI_ID_FILTER) {
> > 		int i;
> >
> > 		for (i = 1; i < NUM_COUNTERS; i++) {
> > 			if (!ddr_perf_filters_compatible(event, pmu->events[i]))
> > 				return -EINVAL;
> > 		}
> > 	}
> >
> > Please drop the dev_dbg() here, since when perf rotates events this
> > can happen many times per second, and it's entirely legitimate.
> 
> [Joakim] Got it.
> 
> > Otherwise, this looks good to me.
> 
> [Joakim] Thanks Mark, I will sent out a V6, please help review.
> 
> Best Regards,
> Joakim Zhang
> > Thanks,
> > Mark.
> >
> > > +
> > > +		writel(filter_val, pmu->base + COUNTER_DPCR1);
> > > +	}
> > > +
> > >  	counter = ddr_perf_alloc_counter(pmu, cfg);
> > >  	if (counter < 0) {
> > >  		dev_dbg(pmu->dev, "There are not enough counters\n"); @@ -
> 472,6
> > > +529,8 @@ static int ddr_perf_probe(struct platform_device *pdev)
> > >  	if (!name)
> > >  		return -ENOMEM;
> > >
> > > +	pmu->devtype_data = of_device_get_match_data(&pdev->dev);
> > > +
> > >  	pmu->cpu = raw_smp_processor_id();
> > >  	ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN,
> > >  				      DDR_CPUHP_CB_NAME,
> > > --
> > > 2.17.1
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 01/12] ARM: dts: imx7d: cl-som-imx7 imx7d-sbc-imx7: move USB
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team

Whether and which USB port is enabled and how they
are powered is a function of the carrier board, not
of the SoM. Different carrier boards can have different
ports enabled / wired up, and power them differently;
so this should really move into the respective DTS.

Do so and update the USB power supply to reflect
the actual situation on the sbc-imx7 carrier board.

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 24 ------------------------
 arch/arm/boot/dts/imx7d-sbc-imx7.dts    | 13 +++++++++++++
 2 files changed, 13 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 62d5e9a4a781..6f7e85cf0c28 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -22,15 +22,6 @@
 		device_type = "memory";
 		reg = <0x80000000 0x10000000>; /* 256 MB - minimal configuration */
 	};
-
-	reg_usb_otg1_vbus: regulator-vbus {
-		compatible = "regulator-fixed";
-		regulator-name = "usb_otg1_vbus";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-	};
 };
 
 &cpu0 {
@@ -193,13 +184,6 @@
 	status = "okay";
 };
 
-&usbotg1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_usbotg1>;
-	vbus-supply = <&reg_usb_otg1_vbus>;
-	status = "okay";
-};
-
 &usdhc3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc3>;
@@ -278,11 +262,3 @@
 		>;
 	};
 };
-
-&iomuxc_lpsr {
-	pinctrl_usbotg1: usbotg1grp {
-		fsl,pins = <
-			MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5	0x14 /* OTG PWREN */
-		>;
-	};
-};
diff --git a/arch/arm/boot/dts/imx7d-sbc-imx7.dts b/arch/arm/boot/dts/imx7d-sbc-imx7.dts
index f8a868552707..aab646903de3 100644
--- a/arch/arm/boot/dts/imx7d-sbc-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-sbc-imx7.dts
@@ -15,6 +15,14 @@
 / {
 	model = "CompuLab SBC-iMX7";
 	compatible = "compulab,sbc-imx7", "compulab,cl-som-imx7", "fsl,imx7d";
+
+	reg_usb_vbus: regulator-usb-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
 };
 
 &usdhc1 {
@@ -26,6 +34,11 @@
 	status = "okay";
 };
 
+&&usbotg1 {
+	vbus-supply = <&reg_usb_vbus>;
+	status = "okay";
+};
+
 &iomuxc {
 	pinctrl_usdhc1: usdhc1grp {
 		fsl,pins = <
-- 
2.23.0.rc1


_______________________________________________
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 02/12] ARM: dts: imx7d: cl-som-imx7: add phy-reset-gpios
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

According to the design team:
* reset input PHY0 is directly connected to the
  corresponding pin GPIO1_4 in the i.MX7
* reset for PHY1 is done using the gpio expander bit 4

While touching this area, also add a 'compatible'
to the phy to make it more clear what this is and
which driver handles this - an Ethernet phy attached
to mdio, handled by of_mdio.c

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 6f7e85cf0c28..e0432a3aa36f 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -30,13 +30,14 @@
 
 &fec1 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_enet1>;
+	pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet1phy>;
 	assigned-clocks = <&clks IMX7D_ENET1_TIME_ROOT_SRC>,
 			  <&clks IMX7D_ENET1_TIME_ROOT_CLK>;
 	assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>;
 	assigned-clock-rates = <0>, <100000000>;
 	phy-mode = "rgmii-id";
 	phy-handle = <&ethphy0>;
+	phy-reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
 	fsl,magic-packet;
 	status = "okay";
 
@@ -45,10 +46,12 @@
 		#size-cells = <0>;
 
 		ethphy0: ethernet-phy@0 {
+			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <0>;
 		};
 
 		ethphy1: ethernet-phy@1 {
+			compatible = "ethernet-phy-ieee802.3-c22";
 			reg = <1>;
 		};
 	};
@@ -63,6 +66,7 @@
 	assigned-clock-rates = <0>, <100000000>;
 	phy-mode = "rgmii-id";
 	phy-handle = <&ethphy1>;
+	phy-reset-gpios = <&pca9555 4 GPIO_ACTIVE_LOW>;
 	fsl,magic-packet;
 	status = "okay";
 };
@@ -262,3 +266,11 @@
 		>;
 	};
 };
+
+&iomuxc_lpsr {
+	pinctrl_enet1phy: enet1phygrp {
+		fsl,pins = <
+			MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4	0x34
+		>;
+	};
+};
-- 
2.23.0.rc1


_______________________________________________
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 03/12] ARM: dts: imx7d: cl-som-imx7: fix i2c2
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

I2C2 is configured incorrectly at the moment:
* update i2c2 to actually work (fix incorrect pinctrl assignments)
* add the i2c2 bus recovery information [1]

[1] Note that scl is being marked as GPIO_OPEN_DRAIN even
though the i.MX pinctrl driver does not support enabling
open drain directly - it is enabled by the fixed pinmux
entry.
So while this flag has no effect in practice, it needs
to be there purely so as to fix the following warning
from gpiolib:
    gpio-6 (scl): enforced open drain please flag it properly in DT/ACPI DSDT/board file
as that is the mode requested by i2c-imx.c

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 26 +++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index e0432a3aa36f..ec82f4738c4f 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -72,8 +72,11 @@
 };
 
 &i2c2 {
-	pinctrl-names = "default";
+	pinctrl-names = "default", "gpio";
 	pinctrl-0 = <&pinctrl_i2c2>;
+	pinctrl-1 = <&pinctrl_i2c2_recovery>;
+	sda-gpios = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+	scl-gpios = <&gpio1 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
 	status = "okay";
 
 	pmic: pmic@8 {
@@ -236,13 +239,6 @@
 		>;
 	};
 
-	pinctrl_i2c2: i2c2grp {
-		fsl,pins = <
-			MX7D_PAD_I2C2_SDA__I2C2_SDA		0x4000007f
-			MX7D_PAD_I2C2_SCL__I2C2_SCL		0x4000007f
-		>;
-	};
-
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
 			MX7D_PAD_UART1_TX_DATA__UART1_DCE_TX	0x79
@@ -273,4 +269,18 @@
 			MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4	0x34
 		>;
 	};
+
+	pinctrl_i2c2: i2c2grp {
+		fsl,pins = <
+			MX7D_PAD_LPSR_GPIO1_IO07__I2C2_SDA	0x4000000f
+			MX7D_PAD_LPSR_GPIO1_IO06__I2C2_SCL	0x4000000f
+		>;
+	};
+
+	pinctrl_i2c2_recovery: i2c2recoverygrp {
+		fsl,pins = <
+			MX7D_PAD_LPSR_GPIO1_IO07__GPIO1_IO7	0x4000007f
+			MX7D_PAD_LPSR_GPIO1_IO06__GPIO1_IO6	0x4000007f
+		>;
+	};
 };
-- 
2.23.0.rc1


_______________________________________________
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 04/12] ARM: dts: imx7d: cl-som-imx7: add emmicro,em3027 RTC
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

add/enable RTC support using the on-board EM3027 real time
clock on i2c2.

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index ec82f4738c4f..481bd3971c55 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -181,6 +181,11 @@
 		reg = <0x50>;
 		pagesize = <16>;
 	};
+
+	rtc@56 {
+		compatible = "emmicro,em3027";
+		reg = <0x56>;
+	};
 };
 
 &uart1 {
-- 
2.23.0.rc1


_______________________________________________
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 05/12] ARM: dts: imx7d: cl-som-imx7: update pfuze3000 max voltage
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

The max voltage of SW1A is 3.3V on PF3000 as per
http://cache.freescale.com/files/analog/doc/data_sheet/PF3000.pdf?fsrch=1&sr=1&pageNum=1

While at it, remove the unnecessary leading zero from
the i2c address.

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 481bd3971c55..78046633d91b 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -81,12 +81,12 @@
 
 	pmic: pmic@8 {
 		compatible = "fsl,pfuze3000";
-		reg = <0x08>;
+		reg = <0x8>;
 
 		regulators {
 			sw1a_reg: sw1a {
 				regulator-min-microvolt = <700000>;
-				regulator-max-microvolt = <1475000>;
+				regulator-max-microvolt = <3300000>;
 				regulator-boot-on;
 				regulator-always-on;
 				regulator-ramp-delay = <6250>;
-- 
2.23.0.rc1


_______________________________________________
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 06/12] ARM: dts: imx7d: cl-som-imx7: add / enable watchdog
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

add / enable watchdog which is connected via
WDOG_B to the PMIC, due to i.MX7 Errata e10574

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 78046633d91b..ca3c5d95d6c3 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -207,6 +207,12 @@
 	status = "okay";
 };
 
+&wdog1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdog>;
+	fsl,ext-reset-output;
+};
+
 &iomuxc {
 	pinctrl_enet1: enet1grp {
 		fsl,pins = <
@@ -288,4 +294,10 @@
 			MX7D_PAD_LPSR_GPIO1_IO06__GPIO1_IO6	0x4000007f
 		>;
 	};
+
+	pinctrl_wdog: wdoggrp {
+		fsl,pins = <
+			MX7D_PAD_LPSR_GPIO1_IO00__WDOG1_WDOG_B	0x74
+		>;
+	};
 };
-- 
2.23.0.rc1


_______________________________________________
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 07/12] ARM: dts: imx7d: cl-som-imx7: add/enable SPI flash on spi1
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

add/enable SPI flash on spi1 using the default vendor's
partition layout as per downstream kernel

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 45 +++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index ca3c5d95d6c3..d4637a8ca223 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -28,6 +28,36 @@
 	cpu-supply = <&sw1a_reg>;
 };
 
+&ecspi1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;
+	cs-gpios = <&gpio4 19 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+
+	flash@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "jedec,spi-nor";
+		spi-max-frequency = <20000000>;
+		reg = <0>;
+
+		partition@0 {
+			label = "uboot";
+			reg = <0x0 0xc0000>;
+		};
+
+		partition@c0000 {
+			label = "uboot environment";
+			reg = <0xc0000 0x40000>;
+		};
+
+		partition@100000 {
+			label = "splash";
+			reg = <0x100000 0x100000>;
+		};
+	};
+};
+
 &fec1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet1phy>;
@@ -214,6 +244,21 @@
 };
 
 &iomuxc {
+	pinctrl_ecspi1: ecspi1grp {
+		fsl,pins = <
+			MX7D_PAD_ECSPI1_MOSI__ECSPI1_MOSI		0xf
+			MX7D_PAD_ECSPI1_MISO__ECSPI1_MISO		0xf
+			MX7D_PAD_ECSPI1_SCLK__ECSPI1_SCLK		0xf
+		>;
+	};
+
+	pinctrl_ecspi1_cs: ecspi1_cs_grp {
+		fsl,pins = <
+			/* SPI flash chipselect */
+			MX7D_PAD_ECSPI1_SS0__GPIO4_IO19			0x34
+		>;
+	};
+
 	pinctrl_enet1: enet1grp {
 		fsl,pins = <
 			MX7D_PAD_SD2_CD_B__ENET1_MDIO			0x30
-- 
2.23.0.rc1


_______________________________________________
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 08/12] ARM: dts: imx7d: cl-som-imx7: update UART1 (debug) clock
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

assign OSC as uart1 (debug) clock to achieve low power,
so that the PLL doesn't need to be kept on

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index d4637a8ca223..f80be855b4ec 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -222,7 +222,7 @@
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_uart1>;
 	assigned-clocks = <&clks IMX7D_UART1_ROOT_SRC>;
-	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+	assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
 	status = "okay";
 };
 
-- 
2.23.0.rc1


_______________________________________________
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 10/12] ARM: dts: imx7d: cl-som-imx7: add WiLink8 WLAN support
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

add / enable TI's WiLink8 WLAN module on SDIO2.

Notes:
* power is always enabled (because of bluetooth)
* the downstream delay of 70ms after power-on
  doesn't seem to reliably work, hence it was
  bumped to 700ms

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 60 +++++++++++++++++++++++++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index a16cbb070a12..4cb36decef3d 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -28,6 +28,24 @@
 		compatible = "smsc,usb3503";
 		reset-gpios = <&pca9555 6 GPIO_ACTIVE_LOW>;
 	};
+
+	pwrseq_ti_wifi: ti-wifi-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		reset-gpios = <&pca9555 0 GPIO_ACTIVE_LOW>;
+		post-power-on-delay-ms = <700>;
+		/* 10μs during shutdown, but 60μs between two enables */
+		power-off-delay-us = "60";
+	};
+
+	reg_ti_wifi: regulator-ti-wifi {
+		compatible = "regulator-fixed";
+		regulator-name = "wilink-regulator";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		gpio = <&pca9555 9 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+		regulator-always-on;
+	};
 };
 
 &cpu0 {
@@ -232,6 +250,31 @@
 	status = "okay";
 };
 
+&usdhc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc2>;
+	bus-width = <4>;
+	no-1-8-v;
+	keep-power-in-suspend;
+	wakeup-source;
+	vmmc-supply = <&reg_ti_wifi>;
+	mmc-pwrseq = <&pwrseq_ti_wifi>;
+	non-removable;
+	cap-power-off-card;
+	status = "okay";
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+	wlcore: wlcore@2 {
+		compatible = "ti,wl1835";
+		reg = <2>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usdhc2_wlcore>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <15 IRQ_TYPE_LEVEL_HIGH>;
+	};
+};
+
 &usdhc3 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc3>;
@@ -308,6 +351,23 @@
 		>;
 	};
 
+	pinctrl_usdhc2: usdhc2grp {
+		fsl,pins = <
+			MX7D_PAD_SD2_CMD__SD2_CMD		0x59
+			MX7D_PAD_SD2_CLK__SD2_CLK		0x19
+			MX7D_PAD_SD2_DATA0__SD2_DATA0		0x59
+			MX7D_PAD_SD2_DATA1__SD2_DATA1		0x59
+			MX7D_PAD_SD2_DATA2__SD2_DATA2		0x59
+			MX7D_PAD_SD2_DATA3__SD2_DATA3		0x59
+		>;
+	};
+
+	pinctrl_usdhc2_wlcore: usdhc2wlcoregrp {
+		fsl,pins = <
+			MX7D_PAD_GPIO1_IO15__GPIO1_IO15		0x34
+		>;
+	};
+
 	pinctrl_usdhc3: usdhc3grp {
 		fsl,pins = <
 			MX7D_PAD_SD3_CMD__SD3_CMD		0x59
-- 
2.23.0.rc1


_______________________________________________
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 09/12] ARM: dts: imx7d: cl-som-imx7: add SMSC USB3503 usb hub
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

As per the SoM design, add the SMSC USB3503 that is
used as a PHY in hardware-only mode, connected
to the imx7d's &usbh interface, providing additional
USB ports for USB and mini-PCIe.

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index f80be855b4ec..a16cbb070a12 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -22,6 +22,12 @@
 		device_type = "memory";
 		reg = <0x80000000 0x10000000>; /* 256 MB - minimal configuration */
 	};
+
+	/* SMSC USB3503 connected to &usbh */
+	usb_hub: usb-hub {
+		compatible = "smsc,usb3503";
+		reset-gpios = <&pca9555 6 GPIO_ACTIVE_LOW>;
+	};
 };
 
 &cpu0 {
-- 
2.23.0.rc1


_______________________________________________
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 11/12] ARM: dts: imx7d: cl-som-imx7: add WiLink Bluetooth support
From: André Draszik @ 2019-08-26 15:37 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

add / enable TI's WiLink8 Bluetooth module on UART3.

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
index 4cb36decef3d..08fb43f7ae1d 100644
--- a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -250,6 +250,21 @@
 	status = "okay";
 };
 
+&uart3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart3>;
+	assigned-clocks = <&clks IMX7D_UART3_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+	uart-has-rtscts;
+	status = "okay";
+
+	bluetooth {
+		compatible = "ti,wl1835-st";
+		enable-gpios = <&pca9555 1 GPIO_ACTIVE_HIGH>;
+		max-speed = <3000000>;
+	};
+};
+
 &usdhc2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usdhc2>;
@@ -351,6 +366,15 @@
 		>;
 	};
 
+	pinctrl_uart3: uart3grp {
+		fsl,pins = <
+			MX7D_PAD_UART3_TX_DATA__UART3_DCE_TX	0x79
+			MX7D_PAD_UART3_RX_DATA__UART3_DCE_RX	0x79
+			MX7D_PAD_UART3_CTS_B__UART3_DCE_CTS	0x79
+			MX7D_PAD_UART3_RTS_B__UART3_DCE_RTS	0x79
+		>;
+	};
+
 	pinctrl_usdhc2: usdhc2grp {
 		fsl,pins = <
 			MX7D_PAD_SD2_CMD__SD2_CMD		0x59
-- 
2.23.0.rc1


_______________________________________________
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 12/12] ARM: dts: imx7d: sbc-iot-imx7: add basic board support
From: André Draszik @ 2019-08-26 15:38 UTC (permalink / raw)
  To: linux-kernel
  Cc: Mark Rutland, devicetree, Fabio Estevam, linux-arm-kernel,
	André Draszik, Sascha Hauer, Rob Herring, Igor Grinberg,
	Pengutronix Kernel Team, Shawn Guo, Ilya Ledvich, NXP Linux Team
In-Reply-To: <20190826153800.35400-1-git@andred.net>

This is a forward-port of Compulab's downstream commit
against linux 4.9.11.

Original commit message:
    The SB-IOT-iMX7 base board together with CL-SOM-iMX7
    SoM forms SBC-IOT-iMX7 single board computer.
    SBC-IOT-iMX7 is a single board computer optimized for
    industrial control and monitoring, extensive wireless
    and wired connectivity, ideal solution for
    cost-sensitive systems. It is based on the Freescale
    i.MX7 system-on-chip. SBC-IOT-iMX7 is implemented with
    the CL-SOM-iMX7 System-on-Module providing most of the
    functions,and SB-IOT-iMX7 carrier board providing
    additional peripheral functions and connectors.

    https://www.compulab.com/products/computer-on-modules/cl-som-imx7-freescale-i-mx-7-system-on-module/
    https://www.compulab.com/products/sbcs/sbc-iot-imx7-nxp-i-mx-7-internet-of-things-single-board-computer/

This commit adds basic board support, including:
* SD-card (note that write-protect is not connected
  on this carrier board)
* SPI (available on expansion header)
* i2c3 & i2c4 (including bus recovery information)
* additional UARTs
* all USB ports

Compared to the downtream commit, this commit doesn't
add / enable the PCIe and LCD interface, as PCIe
support needs an additional patch to the PCI controller
first, and I can't test the LCD.

Signed-off-by: André Draszik <git@andred.net>
Cc: Ilya Ledvich <ilya@compulab.co.il>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/Makefile               |   1 +
 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts | 198 +++++++++++++++++++++++
 2 files changed, 199 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..78d51f2f9930 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -591,6 +591,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
 	imx7d-pico-hobbit.dtb \
 	imx7d-pico-pi.dtb \
 	imx7d-sbc-imx7.dtb \
+	imx7d-sbc-iot-imx7.dtb \
 	imx7d-sdb.dtb \
 	imx7d-sdb-reva.dtb \
 	imx7d-sdb-sht11.dtb \
diff --git a/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
new file mode 100644
index 000000000000..6f2af5aa439e
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-sbc-iot-imx7.dts
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+//
+// Copyright 2017 CompuLab Ltd. - http://www.compulab.co.il/
+/*
+ * Support for CompuLab SBC-IOT-iMX7 Single Board Computer
+ */
+
+#include "imx7d-cl-som-imx7.dts"
+
+/ {
+	model = "CompuLab,SBC-IOT-iMX7";
+	compatible = "compulab,sbc-iot-imx7", "compulab,cl-som-imx7", "fsl,imx7d";
+
+	reg_usb_vbus: regulator-usb-vbus {
+		compatible = "regulator-fixed";
+		regulator-name = "usb_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-always-on;
+	};
+};
+
+&ecspi3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
+	cs-gpios = <&gpio4 11 GPIO_ACTIVE_HIGH>;
+	status = "okay";
+};
+
+&i2c3 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c3>;
+	pinctrl-1 = <&pinctrl_i2c3_recovery>;
+	sda-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+	scl-gpios = <&gpio1 8 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	status = "okay";
+};
+
+&i2c4 {
+	clock-frequency = <100000>;
+	pinctrl-names = "default", "gpio";
+	pinctrl-0 = <&pinctrl_i2c4>;
+	pinctrl-1 = <&pinctrl_i2c4_recovery>;
+	sda-gpios = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+	scl-gpios = <&gpio1 10 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+	status = "okay";
+
+	eeprom_iot@54 {
+		compatible = "atmel,24c08";
+		reg = <0x54>;
+		pagesize = <16>;
+	};
+};
+
+&iomuxc {
+	pinctrl-1 = <&pinctrl_xpen>;
+
+	/* SB-IOT-iMX7 Xpension Header P7 */
+	pinctrl_xpen: xpengrp {
+		fsl,pins = <
+			MX7D_PAD_LCD_DATA13__GPIO3_IO18		0x34 /* P7-4 - gpio82 */
+			MX7D_PAD_LCD_DATA12__GPIO3_IO17		0x34 /* P7-5 - gpio81 */
+		>;
+	};
+
+	pinctrl_ecspi3: ecspi3grp {
+		fsl,pins = <
+			MX7D_PAD_I2C1_SDA__ECSPI3_MOSI		0xf /* P7-7 */
+			MX7D_PAD_I2C1_SCL__ECSPI3_MISO		0xf /* P7-8 */
+			MX7D_PAD_I2C2_SCL__ECSPI3_SCLK		0xf /* P7-6 */
+		>;
+	};
+
+	pinctrl_ecspi3_cs: ecspi3_cs_grp {
+		fsl,pins = <
+			MX7D_PAD_I2C2_SDA__GPIO4_IO11		0x34 /* P7-9 */
+		>;
+	};
+
+	pinctrl_i2c3: i2c3grp {
+		fsl,pins = <
+			MX7D_PAD_GPIO1_IO09__I2C3_SDA		0x4000000f /* P7-3 */
+			MX7D_PAD_GPIO1_IO08__I2C3_SCL		0x4000000f /* P7-2 */
+		>;
+	};
+
+	pinctrl_i2c3_recovery: i2c3recoverygrp {
+		fsl,pins = <
+			MX7D_PAD_GPIO1_IO09__GPIO1_IO9		0x4000000f /* P7-3 */
+			MX7D_PAD_GPIO1_IO08__GPIO1_IO8		0x4000000f /* P7-2 */
+		>;
+	};
+
+	pinctrl_i2c4: i2c4grp {
+		fsl,pins = <
+			MX7D_PAD_GPIO1_IO11__I2C4_SDA		0x4000000f
+			MX7D_PAD_GPIO1_IO10__I2C4_SCL		0x4000000f
+		>;
+	};
+
+	pinctrl_i2c4_recovery: i2c4recoverygrp {
+		fsl,pins = <
+			MX7D_PAD_GPIO1_IO11__GPIO1_IO11		0x4000000f
+			MX7D_PAD_GPIO1_IO10__GPIO1_IO10		0x4000000f
+		>;
+	};
+
+	pinctrl_uart2: uart2grp {
+		fsl,pins = <
+			MX7D_PAD_LCD_ENABLE__UART2_DCE_TX	0x79 /* P7-12 */
+			MX7D_PAD_LCD_CLK__UART2_DCE_RX		0x79 /* P7-13 */
+			MX7D_PAD_LCD_VSYNC__UART2_DCE_CTS	0x79 /* P7-11 */
+			MX7D_PAD_LCD_HSYNC__UART2_DCE_RTS	0x79 /* P7-10 */
+		>;
+	};
+
+	pinctrl_uart5: uart5grp {
+		fsl,pins = <
+			MX7D_PAD_I2C4_SDA__UART5_DCE_TX		0x79 /* RS232-TX */
+			MX7D_PAD_I2C4_SCL__UART5_DCE_RX		0x79 /* RS232-RX */
+			MX7D_PAD_I2C3_SDA__UART5_DCE_RTS	0x79 /* RS232-RTS */
+			MX7D_PAD_I2C3_SCL__UART5_DCE_CTS	0x79 /* RS232-CTS */
+		>;
+	};
+
+	pinctrl_uart7: uart7grp {
+		fsl,pins = <
+			MX7D_PAD_ECSPI2_MOSI__UART7_DCE_TX	0x79 /* R485-TX */
+			MX7D_PAD_ECSPI2_SCLK__UART7_DCE_RX	0x79 /* R485-RX */
+			MX7D_PAD_ECSPI2_SS0__UART7_DCE_CTS	0x79 /* R485-CTS */
+			MX7D_PAD_ECSPI2_MISO__UART7_DCE_RTS	0x79 /* R485-TTS */
+		>;
+	};
+
+	pinctrl_usdhc1: usdhc1grp {
+		fsl,pins = <
+			MX7D_PAD_SD1_CMD__SD1_CMD		0x59
+			MX7D_PAD_SD1_CLK__SD1_CLK		0x19
+			MX7D_PAD_SD1_DATA0__SD1_DATA0		0x59
+			MX7D_PAD_SD1_DATA1__SD1_DATA1		0x59
+			MX7D_PAD_SD1_DATA2__SD1_DATA2		0x59
+			MX7D_PAD_SD1_DATA3__SD1_DATA3		0x59
+			MX7D_PAD_SD1_CD_B__GPIO5_IO0		0x59 /* CD */
+		>;
+	};
+};
+
+&uart2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart2>;
+	assigned-clocks = <&clks IMX7D_UART2_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&uart5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart5>;
+	assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&uart7 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_uart7>;
+	assigned-clocks = <&clks IMX7D_UART7_ROOT_SRC>;
+	assigned-clock-parents = <&clks IMX7D_PLL_SYS_MAIN_240M_CLK>;
+	fsl,uart-has-rtscts;
+	status = "okay";
+};
+
+&usbotg1 {
+	vbus-supply = <&reg_usb_vbus>;
+	status = "okay";
+};
+
+&usbotg2 {
+	dr_mode = "host";
+	vbus-supply = <&reg_usb_vbus>;
+	status = "okay";
+};
+
+&usbh {
+	vbus-supply = <&reg_usb_vbus>;
+	status = "okay";
+};
+
+&usdhc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc1>;
+	cd-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>;
+	wakeup-source;
+	status = "okay";
+};
-- 
2.23.0.rc1


_______________________________________________
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] remoteproc: stm32: clear MCU PDDS at firmware start
From: Fabien Dessenne @ 2019-08-26 15:38 UTC (permalink / raw)
  To: Maxime Coquelin, Alexandre Torgue, Ohad Ben-Cohen,
	Bjorn Andersson, linux-stm32, linux-arm-kernel, linux-kernel,
	linux-remoteproc
  Cc: Arnaud Pouliquen, Loic Pallardy, Fabien Dessenne

When remoteproc stops a firmware, it sets the MCU PDDS flag, allowing
the platform to reach the Standby power mode if needed.
Symmetrically, clear this flag before running a firmware.
This fixes the issue where the system goes to Standby mode when the
MCU crashes while MPU is in CSTOP mode.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
 drivers/remoteproc/stm32_rproc.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index e2da719..1c95913 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -383,10 +383,21 @@ static void stm32_rproc_add_coredump_trace(struct rproc *rproc)
 
 static int stm32_rproc_start(struct rproc *rproc)
 {
+	struct stm32_rproc *ddata = rproc->priv;
 	int err;
 
 	stm32_rproc_add_coredump_trace(rproc);
 
+	/* clear remote proc Deep Sleep */
+	if (ddata->pdds.map) {
+		err = regmap_update_bits(ddata->pdds.map, ddata->pdds.reg,
+					 ddata->pdds.mask, 0);
+		if (err) {
+			dev_err(&rproc->dev, "failed to clear pdds\n");
+			return err;
+		}
+	}
+
 	err = stm32_rproc_set_hold_boot(rproc, false);
 	if (err)
 		return err;
-- 
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] remoteproc: stm32: manage the get_irq probe defer case
From: Fabien Dessenne @ 2019-08-26 15:38 UTC (permalink / raw)
  To: Maxime Coquelin, Alexandre Torgue, Ohad Ben-Cohen,
	Bjorn Andersson, linux-stm32, linux-arm-kernel, linux-kernel,
	linux-remoteproc
  Cc: Arnaud Pouliquen, Loic Pallardy, Fabien Dessenne

Manage the -EPROBE_DEFER error case for "wdg" IRQ.

Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
---
 drivers/remoteproc/stm32_rproc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/remoteproc/stm32_rproc.c b/drivers/remoteproc/stm32_rproc.c
index 1c95913..2cf4b29 100644
--- a/drivers/remoteproc/stm32_rproc.c
+++ b/drivers/remoteproc/stm32_rproc.c
@@ -517,6 +517,9 @@ static int stm32_rproc_parse_dt(struct platform_device *pdev)
 	int err, irq;
 
 	irq = platform_get_irq(pdev, 0);
+	if (irq == -EPROBE_DEFER)
+		return -EPROBE_DEFER;
+
 	if (irq > 0) {
 		err = devm_request_irq(dev, irq, stm32_rproc_wdg, 0,
 				       dev_name(dev), rproc);
-- 
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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox