* [PATCH v2 0/9] drm/sun4i: Support multiple display pipelines
From: Chen-Yu Tsai @ 2017-04-21 8:38 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Rob Herring, Mark Rutland
Cc: Chen-Yu Tsai, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
Hi,
This is v2 of the series previously named "drm/sun4i: Support two
display pipelines". As the name change suggests, the driver now
supports any number of pipelines, though the hardware only has
2 or 3.
Changes since v1:
- Add component endpoint ID numbering scheme to device tree binding.
- Use lists to keep references to registered backends and tcons.
- Save pointer to device node for backends.
- Traverse the device tree of_graph starting from the tcons, going
up towards the inputs, and matching the device nodes with the
device nodes of registered backends, to find the one linked with
the tcon the search started from.
- Copy the ID for the tcon from its upstream backend, instead of
trying, and possibly failing, to figure it out from the device
tree.
- Split out hunk dropping trailing 0 from a backend error message.
Patch 1 adds the component endpoint ID numbering scheme to the
device tree binding. New in v2.
Patch 2 adds lists to track registered display backends and TCONs,
instead of just one pointer per component type. Previously added
arrays of pointers in v1.
Patch 3 drops the trailing 0 from one of the backend's bind error
messages. This was previously part of the patch "drm/sun4i: Support
two display pipelines".
Patch 4 adds a function to fetch a backend's ID from the device tree.
Unchanged.
Patch 5 adds a device node field to the backend data structure and
saves a reference to the underlying device node of the backend.
New in v2.
Patch 6 makes the tcon driver find its upstream backend by traversing
the of_graph and matching device nodes against the device nodes of
registered backends.
New in v2.
Patch 7 makes the tcon driver use the ID from its associated backend.
New in v2. This is not immediately used in this series, but will be
used in similar fashion for downstream encoders to figure out IDs and
muxing
Patch 8 adds device nodes for sun6i's second display pipeline.
Unchanged.
Patch 9 enables sun6i's tcon0 by default.
Unchanged.
With this series, the sun4i drm driver now supports registering multiple
display pipelines. However the driver does not guard against setups the
hardware does not support, such as driving 2 encoders with incompatible
dot clocks from the same source clock. Muxing of downstream encoders is
not supported either, as we have no drivers for hardware that uses them.
The WiP HDMI driver will be the first.
While this series enables the second display pipeline, there's no
usable output at the moment. For the A31, the second TCON's panel
interface uses the same pins as the Ethernet controller. However
Ethernet is used on most boards.
Regards
ChenYu
Chen-Yu Tsai (9):
dt-bindings: display: sun4i: Add component endpoint ID numbering
scheme
drm/sun4i: Use lists to track registered display backends and TCONs
drm/sun4i: backend: Drop trailing 0 from backend in error message
drm/sun4i: backend: Fetch backend ID from device tree
drm/sun4i: backend: Save pointer to device tree node
drm/sun4i: tcon: Find matching display backend by device node matching
drm/sun4i: tcon: Copy ID from associated backend
ARM: dts: sun6i: Add second display pipeline device nodes
ARM: dts: sun6i: Enable tcon0 by default
.../bindings/display/sunxi/sun4i-drm.txt | 10 ++
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 1 -
arch/arm/boot/dts/sun6i-a31.dtsi | 169 ++++++++++++++++++++-
drivers/gpu/drm/sun4i/sun4i_backend.c | 53 ++++++-
drivers/gpu/drm/sun4i/sun4i_backend.h | 8 +
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +
drivers/gpu/drm/sun4i/sun4i_drv.h | 4 +-
drivers/gpu/drm/sun4i/sun4i_tcon.c | 62 +++++++-
drivers/gpu/drm/sun4i/sun4i_tcon.h | 6 +
9 files changed, 307 insertions(+), 8 deletions(-)
--
2.11.0
^ permalink raw reply
* Re: [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers
From: icenowy-h8G6r0blFSE @ 2017-04-21 8:18 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Jernej Skrabec, David Airlie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Rob Herring, Chen-Yu Tsai,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170420083707.wdtrdlxpvocpzc7g@lukather>
于 2017年4月20日 GMT+08:00 下午4:37:07, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
> On Tue, Apr 18, 2017 at 06:47:56PM +0800, Icenowy Zheng wrote:
>> >> + /* Get the physical address of the buffer in memory */
>> >> + gem = drm_fb_cma_get_gem_obj(fb, 0);
>> >> +
>> >> + DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
>> >> +
>> >> + /* Compute the start of the displayed memory */
>> >> + bpp = fb->format->cpp[0];
>> >> + paddr = gem->paddr + fb->offsets[0];
>> >> + paddr += (state->src_x >> 16) * bpp;
>> >> + paddr += (state->src_y >> 16) * fb->pitches[0];
>> >> +
>> >> + DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
>> >> +
>> >> + paddr_u32 = (uint32_t) paddr;
>> >
>> >How does that work on 64-bits systems ?
>>
>> The hardware is not designed to work on 64-bit systems.
>>
>> Even 64-bit A64/H5 has also 3GiB memory limit.
>
> That's a fragile assumption.
Yes, it's only the basical reason.
>
>> The address cell in mixer hardware is also only 32-bit.
>>
>> So we should just keep the force conversion here. If we then really
>> met 4GiB-capable AW SoC without changing DE2, I think we should have
>> other way to limit CMA pool inside 4GiB.
>
> The register name looks like this is only the lower 32 bits that you
> can set here, and that there is another register for the upper 32 bits
> of that address somewhere.
Maybe... but no one can verify this as their's no currently any user
which has 4GiB+ DRAM.
I think we should keep this until Allwinner really made a 4GiB-capable
hardware.
>
> In that case, please use the lower_32_bits and upper_32_bits helper,
> and don't cast it that way.
>
> If it isn't the case, you should set the DMA mask (through
> dma_set_mask) so that we only allocate memory that can be accessed by
> this device.
How to do it?
>
> Maxime
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] media: mtk-vcodec: remove informative log
From: Tiffany Lin @ 2017-04-21 8:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: devicetree, daniel.thompson, Minghsiu Tsai, srv_heupstream,
Wu-Cheng Li, linux-mediatek, linux-kernel, Daniel Kurtz,
Rob Herring, Hans Verkuil, linux-arm-kernel, Matthias Brugger,
Yingjoe Chen, Eddie Huang, Pawel Osciak, linux-media
In-Reply-To: <20170419075643.0a04af21@vento.lan>
On Wed, 2017-04-19 at 07:56 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 5 Apr 2017 19:09:59 +0800
> Tiffany Lin <tiffany.lin@mediatek.com> escreveu:
>
> > On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> > > Driver is stable. Remove DEBUG definition from driver.
> > >
> > > There are debug message in /var/log/messages if DEBUG is defined,
> > > such as:
> > > [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> > > [MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
> > > [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
> > >
> > > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> > Acked-by:Tiffany Lin <Tiffany.lin@mediatek.com>
> >
> > > ---
> > > drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > index 7d55975..1248083 100644
> > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> > > @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> > > extern int mtk_v4l2_dbg_level;
> > > extern bool mtk_vcodec_dbg;
> > >
> > > -#define DEBUG 1
> > >
> > > #if defined(DEBUG)
> > >
>
> After this patch, building the Kernel with W=1 now shows warnings:
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c: In function 'mtk_vcodec_dec_pw_on':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c:114:51: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
> mtk_v4l2_err("pm_runtime_get_sync fail %d", ret);
> ^
>
> I wrote a patch fixing it, as this is really a trivial issue.
>
> Yet, after that, this one still remains:
>
>
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c: In function 'mtk_vdec_pic_info_update':
> drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c:284:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
> int ret;
> ^~~
>
>
> Shouldn't be mtk_vdec_pic_info_update() returning an error code?
>
>
> Also, IMHO, at least errors should be shown at dmesg.
>
Got it. We will upstream patch to fix warning and add dmesg when error.
best regards,
Tiffany
> Thanks,
> Mauro
^ permalink raw reply
* [PATCH 2/2 v3 resend] dt-bindings: display: imx: entry for AUS mode
From: Martin Kaiser @ 2017-04-21 7:45 UTC (permalink / raw)
To: linux-fbdev
Cc: Bartlomiej Zolnierkiewicz, Sascha Hauer, linux-kernel,
Rob Herring, Mark Rutland, devicetree, Martin Kaiser
In-Reply-To: <1492760753-8374-1-git-send-email-martin@kaiser.cx>
Allow setting the AUS mode for a display from the device tree.
Use an optional boolean property. AUS mode can be set only on imx21
and compatible chipsets.
Signed-off-by: Martin Kaiser <martin@kaiser.cx>
Acked-by: Rob Herring <robh@kernel.org>
---
re-sending v3, rebased against current linux-next
it seems this got lost along the way, there was a bit of confusion
whether to split this in two patches or not
v3:
use a boolean DT property instead of the register value
separate patches for DT binding and code changes
v2:
re-sending DT bindings and code changes as one patch
Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
index 7a5c0e2..cacae0e 100644
--- a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt
@@ -13,6 +13,8 @@ Required nodes:
Additional, the display node has to define properties:
- bits-per-pixel: Bits per pixel
- fsl,pcr: LCDC PCR value
+ A display node may optionally define
+ - fsl,aus_mode: boolean to enable AUS mode (only for imx21)
Optional properties:
- lcd-supply: Regulator for LCD supply voltage.
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2 v3 resend] video: fbdev: imxfb: support AUS mode
From: Martin Kaiser @ 2017-04-21 7:45 UTC (permalink / raw)
To: linux-fbdev-u79uwXL29TY76Z2rM5mHXA
Cc: Bartlomiej Zolnierkiewicz, Sascha Hauer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Martin Kaiser
In-Reply-To: <1488193030-13064-1-git-send-email-martin-XxZfDwE/svGeZLLa646FqQ@public.gmane.org>
Some displays require setting AUS mode in the LDCD AUS Mode Control
Register to work with the imxfb driver. Like the value of the Panel
Configuration Register, the AUS mode setting depends on the display
mode.
Allow setting AUS mode from the device tree by adding a boolean
property. Make this property optional to keep the DT ABI stable.
AUS mode can be set only on imx21 and compatible chipsets.
Signed-off-by: Martin Kaiser <martin-XxZfDwE/svGeZLLa646FqQ@public.gmane.org>
---
re-sending v3, rebased against current linux-next
it seems this got lost along the way, there was a bit of confusion
whether to split this in two patches or not
v3:
use a boolean DT property instead of the register value
separate patches for DT binding and code changes
v2:
re-sending DT bindings and code changes as one patch
drivers/video/fbdev/imxfb.c | 17 +++++++++++++++++
include/linux/platform_data/video-imxfb.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
index 1b0faad..463fbf2 100644
--- a/drivers/video/fbdev/imxfb.c
+++ b/drivers/video/fbdev/imxfb.c
@@ -117,6 +117,9 @@
#define IMXFB_LSCR1_DEFAULT 0x00120300
+#define LCDC_LAUSCR 0x80
+#define LAUSCR_AUS_MODE (1<<31)
+
/* Used fb-mode. Can be set on kernel command line, therefore file-static. */
static const char *fb_mode;
@@ -158,6 +161,7 @@ struct imxfb_info {
dma_addr_t dbar2;
u_int pcr;
+ u_int lauscr;
u_int pwmr;
u_int lscr1;
u_int dmacr;
@@ -422,6 +426,11 @@ static int imxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
pcr |= imxfb_mode->pcr & ~(0x3f | (7 << 25));
fbi->pcr = pcr;
+ /*
+ * The LCDC AUS Mode Control Register does not exist on imx1.
+ */
+ if (!is_imx1_fb(fbi) && imxfb_mode->aus_mode)
+ fbi->lauscr = LAUSCR_AUS_MODE;
/*
* Copy the RGB parameters for this display
@@ -638,6 +647,9 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
if (fbi->dmacr)
writel(fbi->dmacr, fbi->regs + LCDC_DMACR);
+ if (fbi->lauscr)
+ writel(fbi->lauscr, fbi->regs + LCDC_LAUSCR);
+
return 0;
}
@@ -734,6 +746,11 @@ static int imxfb_of_read_mode(struct device *dev, struct device_node *np,
imxfb_mode->bpp = bpp;
imxfb_mode->pcr = pcr;
+ /*
+ * fsl,aus_mode is optional
+ */
+ imxfb_mode->aus_mode = of_property_read_bool(np, "fsl,aus_mode");
+
return 0;
}
diff --git a/include/linux/platform_data/video-imxfb.h b/include/linux/platform_data/video-imxfb.h
index a5c0a71..cf9348b 100644
--- a/include/linux/platform_data/video-imxfb.h
+++ b/include/linux/platform_data/video-imxfb.h
@@ -50,6 +50,7 @@
struct imx_fb_videomode {
struct fb_videomode mode;
u32 pcr;
+ bool aus_mode;
unsigned char bpp;
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 0/6] add support for AXP20X and AXP22X battery power supply driver
From: Maxime Ripard @ 2017-04-21 7:43 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM,
liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170418073421.31351-1-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6108 bytes --]
On Tue, Apr 18, 2017 at 09:34:15AM +0200, Quentin Schulz wrote:
> This is a series for AXP20X and AXP22X battery power supply without the
> support for changing constant charge current from the DT. The patches for
> supporting the constant charge current from DT are ready and will be sent
> once the battery framework required to make this work has been merged.
>
> v6:
> - removed mention to fixed battery in DT-binding documentation,
>
> Quote from v4 cover letter:
>
> The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
> information and data of the various power supplies they support such as
> ACIN, battery and VBUS. For example, they expose the current battery
> voltage, charge or discharge, as well as ACIN and VBUS current voltages
> and currents, internal PMIC temperature and ADC on 2 different GPIOs
> when in the right mode (for the AXP209 only).
>
> The ACIN power supply driver is added by this patch. The AXP20X and
> AXP22X can both read the status and the "usability" of the power supply
> but only the AXP209 will be able to tell the current current and voltage
> of the power supply by reading ADC channels. It is simply not supported
> by the AXP22X PMICs.
>
> The battery power supply driver is also added by this patch. The AXP20X
> and AXP22X share most of their behaviour but have slight variations. The
> allowed target voltages for battery charging are not the same, the
> AXP22X PMIC are able to tell if the battery percentage computed by the
> PMIC is trustworthy and they have different formulas for computing max
> current for battery power supply. The driver is able to give the current
> voltage and current of the battery (be it charging or discharging), the
> maximal and minimal voltage and maximal current allowed for the battery,
> whether the battery is present and usable and its capacity. It will get
> the battery current current and voltage by reading the ADC channels. The
> PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
> AXP22X) that should not be used with Lithium-based batteries and since
> this PMIC is supposed to be used with Lithium-based batteries, they have
> been disabled. The values returned by the ADC driver are multipled by
> 1000 to scale from the mV returned by the ADC to the uV expected by the
> power supply framework.
>
> This series of patch adds DT bindings for ACIN power supply, ADC and
> battery power supply drivers for AXP20X and AXP22X PMICs and their
> documentation. It also enables the supported power supplies for the
> Nextthing Co. CHIP and Sinlinx SinA33 boards.
>
> The different drivers are also added to the MFD cells of the AXP20X and
> AXP22X cells and the writeable and volatile regs updated to work with
> the newly added drivers.
>
> This series of patch is based on a previous upstreaming attempt done by
> Bruno Prémont few months ago. It differs in three points: the ADC
> driver does not tell the battery temperature (TS_IN) as I do not have a
> board to test it with, it does not tell the instantaneous battery power
> as it returns crazy values for me and finally no support for OCV curves
> for the battery.
>
> You can test these patches from this repo and branch:
> https://github.com/QSchulz/linux/tree/axp2xx_adc_batt_ac_v4
>
> v4:
> - added the ability to set maximum constant charge current from sysfs,
> - added a warning when setting a higher than current maximum constant charge
> current,
> - set default to minimum possible value for current and maximum constant charge
> current when no battery DT is present or invalid battery DT,
> - fixed a forgotten custom formula to compute maximum constant charge current
> for AXP22X,
> - automatically lower the current constant charge current when it is higher
> than the maximum constant charge current about to be set,
>
> v3:
> - Removed DT property for constant charge current in favor of the WIP
> battery framework as requested by Sebastian Reichel,
> - Using a simple if condition instead of a switch in the ADC driver,
> - Fixed error handling in ADC driver's probe,
> - Fixed missing call to iio_map_array_unregister in the ADC driver's
> remove,
> - Removed ADC driver's DT node and documentation,
> - Merged IIO channel mapping patches into the original ADC driver
> patch,
> - Removed `adding V-OFF to writeable reg' patch as it's already in
> writeable reg range,
>
> v2:
> - Some registers' name have been changed to better reflect their
> purpose,
> - Make VBUS power supply driver use IIO channels when AXP ADC driver is
> enabled, but fall back on previous behavior when disabled. This is made
> to avoid the ADC driver overwritting registers for VBUS power supply
> ADC when removed,
> - Removed useless adding of data registers to volatile registers,
> - Reordered IIO channels, now grouped by same part of the PMIC (e.g.
> voltage and current of the battery have the same index in different
> IIO types),
> - Added structures for specific data instead of matching on IDs,
> - Switched from DT IIO channels mapping to iio_map structures IIO
> channels mapping,
>
> Quentin
>
> Quentin Schulz (6):
> dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
> power: supply: add battery driver for AXP20X and AXP22X PMICs
> ARM: dtsi: axp209: add battery power supply subnode
> ARM: dtsi: axp22x: add battery power supply subnode
> ARM: dts: sun8i: sina33: enable battery power supply subnode
> ARM: sun5i: chip: enable battery power supply subnode
Applied the last 4 patches.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH V5 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Maxime Ripard @ 2017-04-21 7:35 UTC (permalink / raw)
To: Viresh Kumar
Cc: arm, Rob Herring, Mark Rutland, Chen-Yu Tsai, linaro-kernel,
linux-arm-kernel, linux-pm, Rafael Wysocki, Krzysztof Kozlowski,
Masahiro Yamada, Rob Herring, devicetree, linux-kernel
In-Reply-To: <2eb4a6e227f7edfb51ebf3723d5df7e652c703b4.1492685450.git.viresh.kumar@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 797 bytes --]
On Thu, Apr 20, 2017 at 04:25:09PM +0530, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Rob Herring <robh@kernel.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] [RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 x 1 GiB) support
From: Geert Uytterhoeven @ 2017-04-21 7:04 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Geert Uytterhoeven, Simon Horman, Magnus Damm, Kuninori Morimoto,
Yoshihiro Shimoda, Rob Herring, Mark Rutland, Linux-Renesas,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170421054201.GR28868@bigcity.dyn.berto.se>
Hi Niklas,
On Fri, Apr 21, 2017 at 7:42 AM, Niklas Söderlund
<niklas.soderlund@ragnatech.se> wrote:
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
>> @@ -0,0 +1,36 @@
>> +/*
>> + * Device Tree Source for the r8j7795 SiP with 4 channels of 1 GiB RAM
>> + *
>> + * Copyright (C) 2015 Renesas Electronics Corp.
>
> 2017 right? If so same comment for patches 3 and 4.
As I just moved statements from an existing file, I retained the original
copyright information.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/8] [RFC] arm64: dts: renesas: Add R-Car H3 SiP (4 x 1 GiB) support
From: Niklas Söderlund @ 2017-04-21 5:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, Magnus Damm, Kuninori Morimoto, Yoshihiro Shimoda,
Rob Herring, Mark Rutland, linux-renesas-soc, devicetree,
linux-arm-kernel
In-Reply-To: <1492593351-13835-3-git-send-email-geert+renesas@glider.be>
Hi Geert,
Thanks for your work.
On 2017-04-19 11:15:45 +0200, Geert Uytterhoeven wrote:
> Add support for the R-Car H3 System-in-Package (r8j7795), which contains:
> - an R-Car H3 SoC (r8a7795),
> - 4 channels of 1 GiB of RAM (4 GiB total),
> - HyperFlash (not yet described).
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Questions:
> - Should this file be named r8j7795-4g.dtsi instead?
> - Do other versions (different memory configuration) of r8j7795 exist?
> If yes, how are they named?
> ---
> arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi | 36 +++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
> create mode 100644 arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
>
> diff --git a/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
> new file mode 100644
> index 0000000000000000..02e0ff4a60c53704
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8j7795-4x1g.dtsi
> @@ -0,0 +1,36 @@
> +/*
> + * Device Tree Source for the r8j7795 SiP with 4 channels of 1 GiB RAM
> + *
> + * Copyright (C) 2015 Renesas Electronics Corp.
2017 right? If so same comment for patches 3 and 4.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include "r8a7795.dtsi"
> +
> +/ {
> + compatible = "renesas,r8j7795", "renesas,r8a7795";
> +
> + memory@48000000 {
> + device_type = "memory";
> + /* first 128MB is reserved for secure area. */
> + reg = <0x0 0x48000000 0x0 0x38000000>;
> + };
> +
> + memory@500000000 {
> + device_type = "memory";
> + reg = <0x5 0x00000000 0 0x40000000>;
> + };
> +
> + memory@600000000 {
> + device_type = "memory";
> + reg = <0x6 0x00000000 0 0x40000000>;
> + };
> +
> + memory@700000000 {
> + device_type = "memory";
> + reg = <0x7 0x00000000 0 0x40000000>;
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH V5 4/7] ARM: pxa: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-21 5:30 UTC (permalink / raw)
To: Robert Jarzmik
Cc: arm, Daniel Mack, Haojian Zhuang, Rob Herring, Mark Rutland,
linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Krzysztof Kozlowski, Masahiro Yamada, Rob Herring, devicetree,
linux-kernel
In-Reply-To: <87a87a7s66.fsf@belgarion.home>
On 20-04-17, 22:14, Robert Jarzmik wrote:
> Viresh Kumar <viresh.kumar@linaro.org> writes:
>
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Thanks. But I need you to pick it up for your pull request for arm-soc.
--
viresh
^ permalink raw reply
* Re: [PATCH V5 3/7] ARM: exynos: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-21 5:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, Chanwoo Choi, MyungJoo Ham, Kyungmin Park, Kukjin Kim,
Javier Martinez Canillas, Rob Herring, Mark Rutland,
linaro-kernel, linux-arm-kernel, linux-pm, Rafael Wysocki,
Masahiro Yamada, Rob Herring, linux-samsung-soc, devicetree,
linux-kernel
In-Reply-To: <20170420160930.halyszjunt4q2634@kozik-lap>
On 20-04-17, 18:09, Krzysztof Kozlowski wrote:
> On Thu, Apr 20, 2017 at 04:25:07PM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp@1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Acked-by: Rob Herring <robh@kernel.org>
> > ---
> > .../devicetree/bindings/devfreq/exynos-bus.txt | 46 +++++++--------
> > arch/arm/boot/dts/exynos3250.dtsi | 46 +++++++--------
> > arch/arm/boot/dts/exynos4210.dtsi | 32 +++++------
> > arch/arm/boot/dts/exynos4412-prime.dtsi | 4 +-
> > arch/arm/boot/dts/exynos4412.dtsi | 66 +++++++++++-----------
> > arch/arm/boot/dts/exynos5420.dtsi | 40 ++++++-------
> > arch/arm/boot/dts/exynos5800.dtsi | 56 +++++++++---------
> > arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 48 ++++++++--------
> > arch/arm64/boot/dts/exynos/exynos5433.dtsi | 50 ++++++++--------
> > 9 files changed, 194 insertions(+), 194 deletions(-)
>
>
> Thanks, split ARM64 from ARM and applied (for v4.12). arm-soc keeps DTS
> separated between ARM architectures. Technically this should require a
> resend but we had way too many resends for this simple patch.
Bah! Will make sure to send separate patches from now on. Thanks.
--
viresh
^ permalink raw reply
* Re: [PATCH net-next v3] bindings: net: stmmac: add missing note about LPI interrupt
From: Giuseppe CAVALLARO @ 2017-04-21 5:26 UTC (permalink / raw)
To: Niklas Cassel, Rob Herring, Mark Rutland, David S. Miller,
Joao Pinto, Niklas Cassel, Alexandre TORGUE, Thierry Reding,
Eric Engestrom
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170418123955.21335-1-niklass-VrBV9hrLPhE@public.gmane.org>
On 4/18/2017 2:39 PM, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
>
> The hardware has a LPI interrupt.
> There is already code in the stmmac driver to parse and handle the
> interrupt. However, this information was missing from the DT binding.
>
> At the same time, improve the description of the existing interrupts.
>
> Signed-off-by: Niklas Cassel <niklas.cassel-VrBV9hrLPhE@public.gmane.org>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index f652b0c384ce..c3a7be6615c5 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -7,9 +7,12 @@ Required properties:
> - interrupt-parent: Should be the phandle for the interrupt controller
> that services interrupts for this device
> - interrupts: Should contain the STMMAC interrupts
> -- interrupt-names: Should contain the interrupt names "macirq"
> - "eth_wake_irq" if this interrupt is supported in the "interrupts"
> - property
> +- interrupt-names: Should contain a list of interrupt names corresponding to
> + the interrupts in the interrupts property, if available.
> + Valid interrupt names are:
> + - "macirq" (combined signal for various interrupt events)
> + - "eth_wake_irq" (the interrupt to manage the remote wake-up packet detection)
> + - "eth_lpi" (the interrupt that occurs when Tx or Rx enters/exits LPI state)
> - phy-mode: See ethernet.txt file in the same directory.
> - snps,reset-gpio gpio number for phy reset.
> - snps,reset-active-low boolean flag to indicate if phy reset is active low.
> @@ -152,8 +155,8 @@ Examples:
> compatible = "st,spear600-gmac";
> reg = <0xe0800000 0x8000>;
> interrupt-parent = <&vic1>;
> - interrupts = <24 23>;
> - interrupt-names = "macirq", "eth_wake_irq";
> + interrupts = <24 23 22>;
> + interrupt-names = "macirq", "eth_wake_irq", "eth_lpi";
> mac-address = [000000000000]; /* Filled in by U-Boot */
> max-frame-size = <3800>;
> phy-mode = "gmii";
Acked-by: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 08/13] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
From: Yinghai Lu @ 2017-04-21 5:04 UTC (permalink / raw)
To: Bjorn Helgaas, David Miller, Benjamin Herrenschmidt
Cc: Wei Yang, Khalid Aziz, linux-pci, linux-kernel, Yinghai Lu,
Grant Likely, Rob Herring, devicetree
In-Reply-To: <20170421050500.13957-1-yinghai@kernel.org>
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.
This patch set IORESOUCE_MEM_64 for 64bit resource during OF device
resource flags parsing.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Tested-by: Khalid Aziz <khalid.aziz@oracle.com>
---
drivers/of/address.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..d1bb76c 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -131,9 +131,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr)
flags |= IORESOURCE_IO;
break;
case 0x02: /* 32 bits */
- case 0x03: /* 64 bits */
flags |= IORESOURCE_MEM;
break;
+ case 0x03: /* 64 bits */
+ flags |= IORESOURCE_MEM | IORESOURCE_MEM_64;
+ break;
}
if (w & 0x40000000)
flags |= IORESOURCE_PREFETCH;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 1/3] dt-bindings: mt8173: Fix mdp device tree
From: Minghsiu Tsai @ 2017-04-21 4:06 UTC (permalink / raw)
To: Rob Herring
Cc: Hans Verkuil, daniel.thompson, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Houlong Wei,
srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek
In-Reply-To: <20170419213540.4vigeed3mx24ie4e@rob-hp-laptop>
On Wed, 2017-04-19 at 16:35 -0500, Rob Herring wrote:
> On Thu, Apr 13, 2017 at 03:33:05PM +0800, Minghsiu Tsai wrote:
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> >
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems. This also simplifies the
> > device tree.
>
> It may simplify the DT, but it also breaks compatibility with old DT.
> Not sure if that's a problem on Mediatek platforms, but please be
> explicit here that you are breaking compatibility and why that is okay.
>
I will add the following description for more information.
"
Although it fixes iommu assignment issue, it also break compatibility
with old device tree, so driver patch[1] is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.
In mtk_mdp_probe()
Old: for_each_child_of_node(dev->of_node, node)
New: for_each_child_of_node(dev->of_node->parent, node)
[1]https://patchwork.kernel.org/patch/9678833/
"
> >
> > Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
> > Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
>
> Should this have Daniel as the author?
This patch is provided by Daniel, so I keep he is the author.
I just split his patch into two parts. One is dts only, and the other is
for driver. I also provide another patch to modify dts bindings
according to this patch.
>
> >
> > ---
> > Documentation/devicetree/bindings/media/mediatek-mdp.txt | 12 +++---------
> > 1 file changed, 3 insertions(+), 9 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > index 4182063..0d03e3a 100644
> > --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > @@ -2,7 +2,7 @@
> >
> > Media Data Path is used for scaling and color space conversion.
> >
> > -Required properties (controller (parent) node):
> > +Required properties (controller node):
> > - compatible: "mediatek,mt8173-mdp"
> > - mediatek,vpu: the node of video processor unit, see
> > Documentation/devicetree/bindings/media/mediatek-vpu.txt for details.
> > @@ -32,21 +32,16 @@ Required properties (DMA function blocks, child node):
> > for details.
> >
> > Example:
> > -mdp {
> > - compatible = "mediatek,mt8173-mdp";
> > - #address-cells = <2>;
> > - #size-cells = <2>;
> > - ranges;
> > - mediatek,vpu = <&vpu>;
> > -
> > mdp_rdma0: rdma@14001000 {
> > compatible = "mediatek,mt8173-mdp-rdma";
> > + "mediatek,mt8173-mdp";
> > reg = <0 0x14001000 0 0x1000>;
> > clocks = <&mmsys CLK_MM_MDP_RDMA0>,
> > <&mmsys CLK_MM_MUTEX_32K>;
> > power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> > iommus = <&iommu M4U_PORT_MDP_RDMA0>;
> > mediatek,larb = <&larb0>;
> > + mediatek,vpu = <&vpu>;
> > };
> >
> > mdp_rdma1: rdma@14002000 {
> > @@ -106,4 +101,3 @@ mdp {
> > iommus = <&iommu M4U_PORT_MDP_WROT1>;
> > mediatek,larb = <&larb4>;
> > };
> > -};
> > --
> > 1.9.1
> >
^ permalink raw reply
* Re: [PATCH v6 1/6] dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
From: Chen-Yu Tsai @ 2017-04-21 3:51 UTC (permalink / raw)
To: Quentin Schulz
Cc: Rob Herring, Sebastian Reichel, Mark Rutland, Chen-Yu Tsai,
Russell King, Maxime Ripard, open list:THERMAL, linux-sunxi,
Icenowy Zheng, Liam Breck, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20170420155820.tzvvwqnl2ze63jel@rob-hp-laptop>
On Thu, Apr 20, 2017 at 11:58 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Apr 18, 2017 at 09:34:16AM +0200, Quentin Schulz wrote:
>> The X-Powers AXP20X and AXP22X PMICs can have a battery as power supply.
>>
>> This patch adds the DT binding documentation for the battery power
>> supply which gets various data from the PMIC, such as the battery status
>> (charging, discharging, full, dead), current max limit, current current,
>> battery capacity (in percentage), voltage max and min limits, current
>> voltage and battery capacity (in Ah).
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> ---
>> v6:
>> - removed mention to monitored-battery, will be sent when the battery
>> framework has been merged,
>>
>> v5:
>> - removed DT property example from monitored-battery,
>>
>> v4:
>> - added monitored-battery optional property,
>> - added example with battery,
>>
>> v3:
>> - removed constant charge current property, now should use the WIP
>> battery framework,
>>
>> v2:
>> - changed DT node name from ac_power_supply to ac-power-supply,
>> - removed io-channels and io-channel-names from DT (the IIO mapping is
>> done in the IIO ADC driver now),
>> - added x-powers,constant-charge-current property to set the maximal
>> default constant current charge of the battery,
>>
>> .../bindings/power/supply/axp20x_battery.txt | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
^ permalink raw reply
* [PATCH V5 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G
From: Chunyan Zhang @ 2017-04-21 3:47 UTC (permalink / raw)
To: arm
Cc: devicetree, orson.zhai, mathieu.poirier, zhang.lyra, linux-kernel,
chunyan.zhang, linux-arm-kernel
In-Reply-To: <20170419142425.GB12105@localhost>
From: Orson Zhai <orson.zhai@spreadtrum.com>
SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum.
According to regular hierarchy of sprd dts, whale2.dtsi contains SoC
peripherals IP nodes, sc9860.dtsi contains stuff related to ARM core stuff
and sp9860g dts is for the board level.
Signed-off-by: Orson Zhai <orson.zhai@spreadtrum.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang@spreadtrum.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
arch/arm64/boot/dts/sprd/Makefile | 3 +-
arch/arm64/boot/dts/sprd/sc9860.dtsi | 569 ++++++++++++++++++++++++++++++
arch/arm64/boot/dts/sprd/sp9860g-1h10.dts | 56 +++
arch/arm64/boot/dts/sprd/whale2.dtsi | 71 ++++
4 files changed, 698 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/sprd/sc9860.dtsi
create mode 100644 arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
create mode 100644 arch/arm64/boot/dts/sprd/whale2.dtsi
diff --git a/arch/arm64/boot/dts/sprd/Makefile b/arch/arm64/boot/dts/sprd/Makefile
index b658c5e..f0535e6 100644
--- a/arch/arm64/boot/dts/sprd/Makefile
+++ b/arch/arm64/boot/dts/sprd/Makefile
@@ -1,4 +1,5 @@
-dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb
+dtb-$(CONFIG_ARCH_SPRD) += sc9836-openphone.dtb \
+ sp9860g-1h10.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/sprd/sc9860.dtsi b/arch/arm64/boot/dts/sprd/sc9860.dtsi
new file mode 100644
index 0000000..7b7d8ce
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sc9860.dtsi
@@ -0,0 +1,569 @@
+/*
+ * Spreadtrum SC9860 SoC
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "whale2.dtsi"
+
+/ {
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+ core1 {
+ cpu = <&CPU1>;
+ };
+ core2 {
+ cpu = <&CPU2>;
+ };
+ core3 {
+ cpu = <&CPU3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU4>;
+ };
+ core1 {
+ cpu = <&CPU5>;
+ };
+ core2 {
+ cpu = <&CPU6>;
+ };
+ core3 {
+ cpu = <&CPU7>;
+ };
+ };
+ };
+
+ CPU0: cpu@530000 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530000>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU1: cpu@530001 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530001>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU2: cpu@530002 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530002>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU3: cpu@530003 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530003>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU4: cpu@530100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530100>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU5: cpu@530101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530101>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU6: cpu@530102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530102>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+
+ CPU7: cpu@530103 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x0 0x530103>;
+ enable-method = "psci";
+ cpu-idle-states = <&CORE_PD &CLUSTER_PD>;
+ };
+ };
+
+ idle-states{
+ entry-method = "arm,psci";
+
+ CORE_PD: core_pd {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <700>;
+ min-residency-us = <2500>;
+ local-timer-stop;
+ arm,psci-suspend-param = <0x00010002>;
+ };
+
+ CLUSTER_PD: cluster_pd {
+ compatible = "arm,idle-state";
+ entry-latency-us = <1000>;
+ exit-latency-us = <1000>;
+ min-residency-us = <3000>;
+ local-timer-stop;
+ arm,psci-suspend-param = <0x01010003>;
+ };
+ };
+
+ gic: interrupt-controller@12001000 {
+ compatible = "arm,gic-400";
+ reg = <0 0x12001000 0 0x1000>,
+ <0 0x12002000 0 0x2000>,
+ <0 0x12004000 0 0x2000>,
+ <0 0x12006000 0 0x2000>;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8)
+ | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a53-pmu", "arm,armv8-pmuv3";
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&CPU0>,
+ <&CPU1>,
+ <&CPU2>,
+ <&CPU3>,
+ <&CPU4>,
+ <&CPU5>,
+ <&CPU6>,
+ <&CPU7>;
+ };
+
+ soc {
+ funnel@10001000 { /* SoC Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x10001000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ soc_funnel_out_port: endpoint {
+ remote-endpoint = <&etb_in>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ soc_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&main_funnel_out_port>;
+ };
+ };
+
+ port@2 {
+ reg = <4>;
+ soc_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpioint =
+ <&stm_out_port>;
+ };
+ };
+ };
+ };
+
+ etb@10003000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x10003000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ port {
+ etb_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&soc_funnel_out_port>;
+ };
+ };
+ };
+
+ stm@10006000 {
+ compatible = "arm,coresight-stm", "arm,primecell";
+ reg = <0 0x10006000 0 0x1000>,
+ <0 0x01000000 0 0x180000>;
+ reg-names = "stm-base", "stm-stimulus-base";
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint =
+ <&soc_funnel_in_port1>;
+ };
+ };
+ };
+
+ funnel@11001000 { /* Cluster0 Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11001000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster0_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&cluster0_etf_in>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster0_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+
+ port@2 {
+ reg = <1>;
+ cluster0_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+
+ port@3 {
+ reg = <2>;
+ cluster0_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+ cluster0_funnel_in_port3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ };
+ };
+
+ funnel@11002000 { /* Cluster1 Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11002000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster1_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&cluster1_etf_in>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster1_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm4_out>;
+ };
+ };
+
+ port@2 {
+ reg = <1>;
+ cluster1_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm5_out>;
+ };
+ };
+
+ port@3 {
+ reg = <2>;
+ cluster1_funnel_in_port2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm6_out>;
+ };
+ };
+
+ port@4 {
+ reg = <3>;
+ cluster1_funnel_in_port3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm7_out>;
+ };
+ };
+ };
+ };
+
+ etf@11003000 { /* ETF on Cluster0 */
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x11003000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster0_etf_out: endpoint {
+ remote-endpoint =
+ <&main_funnel_in_port0>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster0_etf_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster0_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ etf@11004000 { /* ETF on Cluster1 */
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0 0x11004000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ cluster1_etf_out: endpoint {
+ remote-endpoint =
+ <&main_funnel_in_port1>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ cluster1_etf_in: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster1_funnel_out_port>;
+ };
+ };
+ };
+ };
+
+ funnel@11005000 { /* Main Funnel */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0 0x11005000 0 0x1000>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ main_funnel_out_port: endpoint {
+ remote-endpoint =
+ <&soc_funnel_in_port0>;
+ };
+ };
+
+ port@1 {
+ reg = <0>;
+ main_funnel_in_port0: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster0_etf_out>;
+ };
+ };
+
+ port@2 {
+ reg = <1>;
+ main_funnel_in_port1: endpoint {
+ slave-mode;
+ remote-endpoint =
+ <&cluster1_etf_out>;
+ };
+ };
+ };
+ };
+
+ etm@11440000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11440000 0 0x1000>;
+ cpu = <&CPU0>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port0>;
+ };
+ };
+ };
+
+ etm@11540000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11540000 0 0x1000>;
+ cpu = <&CPU1>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port1>;
+ };
+ };
+ };
+
+ etm@11640000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11640000 0 0x1000>;
+ cpu = <&CPU2>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port2>;
+ };
+ };
+ };
+
+ etm@11740000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11740000 0 0x1000>;
+ cpu = <&CPU3>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint =
+ <&cluster0_funnel_in_port3>;
+ };
+ };
+ };
+
+ etm@11840000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11840000 0 0x1000>;
+ cpu = <&CPU4>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm4_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port0>;
+ };
+ };
+ };
+
+ etm@11940000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11940000 0 0x1000>;
+ cpu = <&CPU5>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm5_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port1>;
+ };
+ };
+ };
+
+ etm@11a40000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11a40000 0 0x1000>;
+ cpu = <&CPU6>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm6_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port2>;
+ };
+ };
+ };
+
+ etm@11b40000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0 0x11b40000 0 0x1000>;
+ cpu = <&CPU7>;
+ clocks = <&ext_26m>;
+ clock-names = "apb_pclk";
+
+ port {
+ etm7_out: endpoint {
+ remote-endpoint =
+ <&cluster1_funnel_in_port3>;
+ };
+ };
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
new file mode 100644
index 0000000..ae0b28c
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/sp9860g-1h10.dts
@@ -0,0 +1,56 @@
+/*
+ * Spreadtrum SP9860g board
+ *
+ * Copyright (C) 2017, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/dts-v1/;
+
+#include "sc9860.dtsi"
+
+/ {
+ model = "Spreadtrum SP9860G 3GFHD Board";
+
+ compatible = "sprd,sp9860g-1h10", "sprd,sc9860";
+
+ aliases {
+ serial0 = &uart0; /* for Bluetooth */
+ serial1 = &uart1; /* UART console */
+ serial2 = &uart2; /* Reserved */
+ serial3 = &uart3; /* for GPS */
+ };
+
+ memory{
+ device_type = "memory";
+ reg = <0x0 0x80000000 0 0x60000000>,
+ <0x1 0x80000000 0 0x60000000>;
+ };
+
+ chosen {
+ stdout-path = "serial1:115200n8";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/sprd/whale2.dtsi b/arch/arm64/boot/dts/sprd/whale2.dtsi
new file mode 100644
index 0000000..7c217c5
--- /dev/null
+++ b/arch/arm64/boot/dts/sprd/whale2.dtsi
@@ -0,0 +1,71 @@
+/*
+ * Spreadtrum Whale2 platform peripherals
+ *
+ * Copyright (C) 2016, Spreadtrum Communications Inc.
+ *
+ * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+ */
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ap-apb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x70000000 0x10000000>;
+
+ uart0: serial@0 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x0 0x100>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart1: serial@100000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x100000 0x100>;
+ interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart2: serial@200000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x200000 0x100>;
+ interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+
+ uart3: serial@300000 {
+ compatible = "sprd,sc9860-uart",
+ "sprd,sc9836-uart";
+ reg = <0x300000 0x100>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ext_26m>;
+ status = "disabled";
+ };
+ };
+
+ };
+
+ ext_26m: ext-26m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ clock-output-names = "ext_26m";
+ };
+};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/3] ARM: sun8i: a83t: Rename pinmux setting names
From: Chen-Yu Tsai @ 2017-04-21 3:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, devicetree, linux-arm-kernel, linux-kernel,
linux-sunxi
In-Reply-To: <20170418042205.27894-4-wens-jdAy2FN1RRM@public.gmane.org>
On Tue, Apr 18, 2017 at 12:22 PM, Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> The pinmux setting nodes all have an address element in their node
> names, however the pinctrl node does not have #address-cells.
>
> Rename the existing pinmux setting nodes and labels in sun8i-a83t.dtsi,
> dropping identifiers for functions that only have one possible setting,
> and using the pingroup name if the function is identically available on
> different pingroups.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> arch/arm/boot/dts/sun8i-a83t-allwinner-h8homlet-v2.dts | 2 +-
> arch/arm/boot/dts/sun8i-a83t-cubietruck-plus.dts | 2 +-
> arch/arm/boot/dts/sun8i-a83t.dtsi | 10 +++++-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
[...]
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 82cb87f21b96..87b99338716b 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -174,7 +174,7 @@
> #interrupt-cells = <3>;
> #gpio-cells = <3>;
>
> - mmc0_pins_a: mmc0@0 {
> + mmc0_pins: mmc0_pins {
> pins = "PF0", "PF1", "PF2",
> "PF3", "PF4", "PF5";
> function = "mmc0";
> @@ -182,13 +182,13 @@
> bias-pull-up;
> };
>
> - uart0_pins_a: uart0@0 {
> - pins = "PF2", "PF4";
> + uart0_pb_pins: uart0_pb_pins {
Duh... Forgot to use hyphens instead of underscores in the node names.
I'll send a patch for you to squash in.
ChenYu
> + pins = "PB9", "PB10";
> function = "uart0";
> };
>
> - uart0_pins_b: uart0@1 {
> - pins = "PB9", "PB10";
> + uart0_pf_pins: uart0_pf_pins {
> + pins = "PF2", "PF4";
> function = "uart0";
> };
> };
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
From: Stefan Agner @ 2017-04-21 3:15 UTC (permalink / raw)
To: Marek Vasut
Cc: dwmw2, computersforpeace, boris.brezillon, richard,
cyrille.pitchen, robh+dt, mark.rutland, shawnguo, kernel, han.xu,
fabio.estevam, LW, linux-mtd, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <af3fe671-c5fb-d3cf-c891-e6b7c973baa1@gmail.com>
On 2017-04-20 19:03, Marek Vasut wrote:
> On 04/21/2017 03:07 AM, Stefan Agner wrote:
>> Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
>> clock architecture requiring only two clocks to be referenced.
>> The IP is slightly different compared to i.MX 6SoloX, but currently
>> none of this differences are in use so there is no detection needed
>> and the driver can reuse IS_MX6SX.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>> ---
>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> index c8bbf5da2ab8..4a45d37ddc80 100644
>> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> @@ -127,6 +127,18 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx = {
>> .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
>> };
>>
>> +static const char * const gpmi_clks_for_mx7d[] = {
>> + "gpmi_io", "gpmi_bch_apb",
>> +};
>> +
>> +static const struct gpmi_devdata gpmi_devdata_imx7d = {
>> + .type = IS_MX6SX,
>
> Would it make sense to use IS_MX7 here already to prevent future surprises ?
>
Yeah I was thinking we can do it once we have an actual reason to
distinguish.
But then, adding the type would only require 2-3 lines of change if I
add it to the GPMI_IS_MX6 macro...
--
Stefan
>> + .bch_max_ecc_strength = 62,
>> + .max_chain_delay = 12,
>> + .clks = gpmi_clks_for_mx7d,
>> + .clks_count = ARRAY_SIZE(gpmi_clks_for_mx7d),
>> +};
>> +
>> static irqreturn_t bch_irq(int irq, void *cookie)
>> {
>> struct gpmi_nand_data *this = cookie;
>> @@ -2071,6 +2083,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
>> }, {
>> .compatible = "fsl,imx6sx-gpmi-nand",
>> .data = &gpmi_devdata_imx6sx,
>> + }, {
>> + .compatible = "fsl,imx7d-gpmi-nand",
>> + .data = &gpmi_devdata_imx7d,
>> }, {}
>> };
>> MODULE_DEVICE_TABLE(of, gpmi_nand_id_table);
>>
^ permalink raw reply
* [PATCH RESEND v2 1/2] dt-binding: regulator: anatop: make regulator name property required
From: Dong Aisheng @ 2017-04-21 2:53 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: robh-DgEjT+Ai2ygdnm+yROfE0A, Dong Aisheng, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown
We actually can't allow the missing of the regualor name, thus update
the binding doc to make regulator-name property to be required.
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Dong Aisheng <aisheng.dong-3arQi8VN3Tc@public.gmane.org>
---
Documentation/devicetree/bindings/regulator/anatop-regulator.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
index 1d58c8c..a3106c7 100644
--- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt
@@ -2,6 +2,7 @@ Anatop Voltage regulators
Required properties:
- compatible: Must be "fsl,anatop-regulator"
+- regulator-name: A string used as a descriptive name for regulator outputs
- anatop-reg-offset: Anatop MFD register offset
- anatop-vol-bit-shift: Bit shift for the register
- anatop-vol-bit-width: Number of bits used in the register
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 0/5] mtd: nand: gpmi: add i.MX 7 support
From: Marek Vasut @ 2017-04-21 2:33 UTC (permalink / raw)
To: Stefan Agner, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
richard-/L3Ra7n9ekc, cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170421010755.18025-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On 04/21/2017 03:07 AM, Stefan Agner wrote:
> This patchset adds support for i.MX 7 SoC for the GPMI NAND controller.
> There have been similar patchsets already:
> https://lkml.org/lkml/2016/2/23/912
>
> However, this patchset does not make use of any of the new features.
> The current feature set seems to work fine, I successfully run the MTD
> tests on a Colibri iMX7.
>
> --
The rest of the patchset is IMO OK too, but you probably want the DT
changes Acked by Shawn or Fabio.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V8 5/6] ACPI: Support the probing on the devices which apply indirect-IO
From: zhichang.yuan @ 2017-04-21 2:22 UTC (permalink / raw)
To: dann frazier, zhichang.yuan, lorenzo.pieralisi, hanjun.guo,
sudeep.holla
Cc: Catalin Marinas, Will Deacon, Rob Herring, Frank Rowand,
Bjorn Helgaas, rafael, Arnd Bergmann, linux-arm-kernel,
Mark Rutland, Brian Starkey, olof, benh,
linux-kernel@vger.kernel.org, linux-acpi, linuxarm,
devicetree@vger.kernel.org, linux-pci, Corey Minyard,
Zou Rongrong, John Garry, Gabriele Paoloni
In-Reply-To: <CALdTtnuO=592n+PoR_kkdTyeFYRd90VyPf0JLwnEo7DtXwzoPA@mail.gmail.com>
Hi, Dann,
On 04/21/2017 04:57 AM, dann frazier wrote:
> On Thu, Mar 30, 2017 at 9:26 AM, zhichang.yuan
> <yuanzhichang@hisilicon.com> wrote:
>> On some platforms(such as Hip06/Hip07), the legacy ISA/LPC devices access I/O
>> with some special host-local I/O ports known on x86. To access the I/O
>> peripherals, an indirect-IO mechanism is introduced to mapped the host-local
>> I/O to system logical/fake PIO similar the PCI MMIO on architectures where no
>> separate I/O space exists. Just as PCI MMIO, the host I/O range should be
>> registered before probing the downstream devices and set up the I/O mapping.
>> But current ACPI bus probing doesn't support these indirect-IO hosts/devices.
>>
>> This patch introdueces a new ACPI handler for this device category. Through the
>> handler attach callback, the indirect-IO hosts I/O registration is done and
>> all peripherals' I/O resources are translated into logic/fake PIO before
>> starting the enumeration.
>>
>> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
>> ---
>> drivers/acpi/Makefile | 1 +
>> drivers/acpi/acpi_indirectio.c | 344 +++++++++++++++++++++++++++++++++++++++++
>> drivers/acpi/internal.h | 5 +
>> drivers/acpi/scan.c | 1 +
>> 4 files changed, 351 insertions(+)
>> create mode 100644 drivers/acpi/acpi_indirectio.c
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index a391bbc..10e5f2b 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
>> acpi-y += acpi_lpat.o
>> acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
>> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
>> +acpi-$(CONFIG_INDIRECT_PIO) += acpi_indirectio.o
>>
>> # These are (potentially) separate modules
>>
>> diff --git a/drivers/acpi/acpi_indirectio.c b/drivers/acpi/acpi_indirectio.c
>> new file mode 100644
>> index 0000000..c8c80b5
>> --- /dev/null
>> +++ b/drivers/acpi/acpi_indirectio.c
>> @@ -0,0 +1,344 @@
[snip]
>> +acpi_build_logiciores_template(struct acpi_device *adev,
>> + struct acpi_buffer *buffer)
>> +{
>> + acpi_handle handle = adev->handle;
>> + struct acpi_resource *resource;
>> + acpi_status status;
>> + int res_cnt = 0;
>> +
>> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> + acpi_count_logiciores, &res_cnt);
>> + if (ACPI_FAILURE(status) || !res_cnt) {
>> + dev_err(&adev->dev, "can't evaluate _CRS: %d\n", status);
>> + return -EINVAL;
>> + }
>> +
>> + buffer->length = sizeof(struct acpi_resource) * (res_cnt + 1) + 1;
>> + buffer->pointer = kzalloc(buffer->length - 1, GFP_KERNEL);
>
> (Seth Forshee noticed this issue, just passing it on)
>
> Should this just allocate the full buffer->length? That would keep the
> length attribute accurate (possibly avoiding an off-by-1 error later).
> It's not clear what the trailing byte is needed for, but other drivers
> allocate it as well (drivers/acpi/pci_link.c and
> drivers/platform/x86/sony-laptop.c).
Thanks for your suggestion!
I also curious why this one appended byte is needed as it seems the later
acpi_set_current_resources() doesn't use this byte.
And I tested without setting the buffer->length as the length of resource list
directly, it seems ok.
But anyway, it looks more reasonable to allocate the memory with the
buffer->length rather than buffer->length - 1;
I was made the V9 patch-set, and I can add your suggestion there. But I also
awaiting for ARM64 ACPI maintainer's comment about this patch before really
sending V9. I wonder whether there is better way to make our indirect-IO devices
can be assigned the logic PIO before the enumeration...
Lorenzo, Hanjun, what do you think about this patch?
Thanks,
Zhichang
>
> -dann
>
^ permalink raw reply
* Re: [PATCH v2 1/4] pinctrl: aspeed: Document pinconf in devicetree bindings
From: Joel Stanley @ 2017-04-21 2:20 UTC (permalink / raw)
To: Rob Herring
Cc: Andrew Jeffery, Linus Walleij, Benjamin Herrenschmidt, linux-gpio,
devicetree, Linux Kernel Mailing List, OpenBMC Maillist
In-Reply-To: <20170413194907.x5ij6cehgb5dh6nj@rob-hp-laptop>
On Fri, Apr 14, 2017 at 5:19 AM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Apr 07, 2017 at 10:27:10PM +0930, Andrew Jeffery wrote:
>> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>> ---
>> .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 40 +++++++++++++++++-----
>> 1 file changed, 31 insertions(+), 9 deletions(-)
>
> Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Joel Stanley <joel@jms.id.au>
^ permalink raw reply
* Re: [PATCH 2/5] mtd: nand: gpmi: add i.MX 7 SoC support
From: Marek Vasut @ 2017-04-21 2:03 UTC (permalink / raw)
To: Stefan Agner, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
richard-/L3Ra7n9ekc, cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170421010755.18025-3-stefan-XLVq0VzYD2Y@public.gmane.org>
On 04/21/2017 03:07 AM, Stefan Agner wrote:
> Add support for i.MX 7 SoC. The i.MX 7 has a slightly different
> clock architecture requiring only two clocks to be referenced.
> The IP is slightly different compared to i.MX 6SoloX, but currently
> none of this differences are in use so there is no detection needed
> and the driver can reuse IS_MX6SX.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index c8bbf5da2ab8..4a45d37ddc80 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -127,6 +127,18 @@ static const struct gpmi_devdata gpmi_devdata_imx6sx = {
> .clks_count = ARRAY_SIZE(gpmi_clks_for_mx6),
> };
>
> +static const char * const gpmi_clks_for_mx7d[] = {
> + "gpmi_io", "gpmi_bch_apb",
> +};
> +
> +static const struct gpmi_devdata gpmi_devdata_imx7d = {
> + .type = IS_MX6SX,
Would it make sense to use IS_MX7 here already to prevent future surprises ?
> + .bch_max_ecc_strength = 62,
> + .max_chain_delay = 12,
> + .clks = gpmi_clks_for_mx7d,
> + .clks_count = ARRAY_SIZE(gpmi_clks_for_mx7d),
> +};
> +
> static irqreturn_t bch_irq(int irq, void *cookie)
> {
> struct gpmi_nand_data *this = cookie;
> @@ -2071,6 +2083,9 @@ static const struct of_device_id gpmi_nand_id_table[] = {
> }, {
> .compatible = "fsl,imx6sx-gpmi-nand",
> .data = &gpmi_devdata_imx6sx,
> + }, {
> + .compatible = "fsl,imx7d-gpmi-nand",
> + .data = &gpmi_devdata_imx7d,
> }, {}
> };
> MODULE_DEVICE_TABLE(of, gpmi_nand_id_table);
>
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] mtd: nand: gpmi: unify clock handling
From: Marek Vasut @ 2017-04-21 2:02 UTC (permalink / raw)
To: Stefan Agner, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
richard-/L3Ra7n9ekc, cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
han.xu-3arQi8VN3Tc, fabio.estevam-KZfg59tc24xl57MIdRCFDg,
LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170421010755.18025-2-stefan-XLVq0VzYD2Y@public.gmane.org>
On 04/21/2017 03:07 AM, Stefan Agner wrote:
> Add device specific list of clocks required, and handle all clocks
> in a single for loop. This avoids further code duplication when
> adding i.MX 7 support.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
[...]
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> index 4e49a1f5fa27..2e584e18d980 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.h
> @@ -130,6 +130,8 @@ struct gpmi_devdata {
> enum gpmi_type type;
> int bch_max_ecc_strength;
> int max_chain_delay; /* See the async EDO mode */
> + const char * const *clks;
> + int clks_count;
const int ? :)
Reviewed-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle
From: Michael Ellerman @ 2017-04-21 1:57 UTC (permalink / raw)
To: Frank Rowand, Tyrel Datwyler, Tyrel Datwyler, robh+dt
Cc: linuxppc-dev, linux-kernel, devicetree, nfont, rostedt, mingo
In-Reply-To: <58F90D56.9070602@gmail.com>
Frank Rowand <frowand.list@gmail.com> writes:
> On 04/20/17 09:51, Tyrel Datwyler wrote:
>> On 04/19/2017 09:43 PM, Frank Rowand wrote:
...
>>> Which ends up being this code:
>>>
>>> of_platform_default_populate_init()
>>> of_platform_default_populate()
>>> of_platform_populate()
>>> [[ of_find_node_by_path("/") ]]
>>> [[ of_find_node_opts_by_path(path, NULL) ]]
>>> of_node_get(of_root)
>>>
>>> Note that some functions can be left out of the ARM call stack, with
>>> a return going back more than one level. The functions in the call
>>> list above that are enclosed in '[[' and ']]' were found by source
>>> inspection in those cases.
>>
>> The same thing is encountered in ppc64 stack traces. I assume it is
>> generally inlining of small functions, but I've never actually verified
>> that theory. Probably should take the time to investigate, or just ask
>> someone.
>
> Yes, inlining small functions is one reason for this.
>
> Another case I often find is that when function A calls function B calls
> function C. If the final statement of function B is 'return C()' then
> there is no need for function C to return through function B, it can
> instead return directly to function A.
It's called "Tail call optimisation", and that's more or less a good
description.
cheers
^ 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