* [PATCH 3/3] ARM: imx: remove i.MX6SLL support in i.MX6SL cpu idle driver
From: Anson Huang @ 2018-05-30 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527664358-17844-1-git-send-email-Anson.Huang@nxp.com>
i.MX6SLL supports ARM power off in cpu idle, better to reuse
i.MX6SX cpu idle driver instead of i.MX6SL which does NOT
support ARM power off.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/mach-imx/cpuidle-imx6sl.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c b/arch/arm/mach-imx/cpuidle-imx6sl.c
index fa8ead1..8d866fb 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sl.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
@@ -12,7 +12,6 @@
#include "common.h"
#include "cpuidle.h"
-#include "hardware.h"
static int imx6sl_enter_wait(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
@@ -22,11 +21,9 @@ static int imx6sl_enter_wait(struct cpuidle_device *dev,
* Software workaround for ERR005311, see function
* description for details.
*/
- if (cpu_is_imx6sl())
- imx6sl_set_wait_clk(true);
+ imx6sl_set_wait_clk(true);
cpu_do_idle();
- if (cpu_is_imx6sl())
- imx6sl_set_wait_clk(false);
+ imx6sl_set_wait_clk(false);
imx6_set_lpm(WAIT_CLOCKED);
return index;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/2] Add control for VP9 profile
From: Keiichi Watanabe @ 2018-05-30 7:16 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE
for VP9 profile.
This control can be used to select a desired profile for VP9 encoder.
In addition, it is also used to query for supported profiles by an
encoder or a decoder.
Patch 1 adds this control.
By patch 2, this control is added to MediaTek decoder's driver, which
supports VP9 profile 0.
Version 2 changes:
- Support this control in MediaTek decoder's driver
Keiichi Watanabe (2):
media: v4l2-ctrl: Add control for VP9 profile
media: mtk-vcodec: Support VP9 profile in decoder
.../media/uapi/v4l/extended-controls.rst | 26 +++++++++++++++++++
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 6 +++++
drivers/media/v4l2-core/v4l2-ctrls.c | 12 +++++++++
include/uapi/linux/v4l2-controls.h | 8 ++++++
4 files changed, 52 insertions(+)
--
2.17.0.921.gf22659ad46-goog
^ permalink raw reply
* [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-05-30 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530071613.125768-1-keiichiw@chromium.org>
Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
profile for VP9 encoder and querying for supported profiles by VP9 encoder
or decoder.
An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
used for querying since it is not a menu control but an integer
control, which cannot return an arbitrary set of supported profiles.
The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
with controls for other codec profiles. (e.g. H264)
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
.../media/uapi/v4l/extended-controls.rst | 26 +++++++++++++++++++
drivers/media/v4l2-core/v4l2-ctrls.c | 12 +++++++++
include/uapi/linux/v4l2-controls.h | 8 ++++++
3 files changed, 46 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 03931f9b1285..4f7f128a4998 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1959,6 +1959,32 @@ enum v4l2_vp8_golden_frame_sel -
Select the desired profile for VPx encoder. Acceptable values are 0,
1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
+.. _v4l2-mpeg-video-vp9-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
+ (enum)
+
+enum v4l2_mpeg_video_vp9_profile -
+ This control allows to select the profile for VP9 encoder.
+ This is also used to enumerate supported profiles by VP9 encoder or decoder.
+ Possible values are:
+
+
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
+ - Profile 0
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
+ - Profile 1
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
+ - Profile 2
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
+ - Profile 3
+
+
High Efficiency Video Coding (HEVC/H.265) Control Reference
-----------------------------------------------------------
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index d29e45516eb7..401ce21c2e63 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Use Previous Specific Frame",
NULL,
};
+ static const char * const vp9_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
return vpx_golden_frame_sel;
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
+ return vp9_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -841,6 +850,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile";
+
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC P-Frame QP Value";
@@ -1180,6 +1191,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_DEINTERLACING_MODE:
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 8d473c979b61..56203b7b715c 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -589,6 +589,14 @@ enum v4l2_vp8_golden_frame_sel {
#define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
+#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512)
+enum v4l2_mpeg_video_vp9_profile {
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
+};
+
/* CIDs for HEVC encoding. */
#define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (V4L2_CID_MPEG_BASE + 600)
--
2.17.0.921.gf22659ad46-goog
^ permalink raw reply related
* [PATCH v2 2/2] media: mtk-vcodec: Support VP9 profile in decoder
From: Keiichi Watanabe @ 2018-05-30 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530071613.125768-1-keiichiw@chromium.org>
Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE control in MediaTek decoder's
driver.
MediaTek decoder only supports profile 0 for now.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 86f0a7134365..f9393504356d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1400,6 +1400,12 @@ int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_ctx *ctx)
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE,
0, 32, 1, 1);
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
+ v4l2_ctrl_new_std_menu(&ctx->ctrl_hdl,
+ &mtk_vcodec_dec_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP9_PROFILE,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_3,
+ ~(1U << V4L2_MPEG_VIDEO_VP9_PROFILE_0),
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0);
if (ctx->ctrl_hdl.error) {
mtk_v4l2_err("Adding control failed %d",
--
2.17.0.921.gf22659ad46-goog
^ permalink raw reply related
* [PATCH v3 3/5] Documentation: DT: add i.MX EPIT timer binding
From: Vladimir Zapolskiy @ 2018-05-30 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529170436.22711-4-peron.clem@gmail.com>
Hi Cl?ment,
On 05/29/2018 08:04 PM, Cl?ment P?ron wrote:
> From: Cl?ment Peron <clement.peron@devialet.com>
>
> Add devicetree binding document for NXP's i.MX SoC specific
> EPIT timer driver.
>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
> .../devicetree/bindings/clock/imx6q,epit.txt | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/imx6q,epit.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/imx6q,epit.txt b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
> new file mode 100644
> index 000000000000..a84a60c6ae35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
The file should be renamed to a more generic name like 'imx,epit.txt'
or 'imx31,epit.txt'.
Also note that the folder is incorrectly selected, it must be
Documentation/devicetree/bindings/timer/
> @@ -0,0 +1,24 @@
> +Binding for the i.MX6 EPIT timer
Let's change it to 'Binding for the i.MX EPIT timer'.
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible: should be "fsl,imx6q-epit"
Compatible should be "fsl,imx31-epit", i.MX31 SoC seems to be the first
one in the series, which has the timer module.
There should be added more compatibles specific to later SoC versions.
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: Should contain EPIT controller interrupt
> +- clocks: list of clock specifiers, must contain an entry for each required
> + entry in clock-names
> +- clock-names : should include entries "ipg", "per"
> +
> +Example:
> + epit1: epit at 20d0000 {
> + compatible = "fsl,imx6q-epit";
For i.MX6Q example a list of compatibles should be updated like
compatible = "fsl,imx6q-epit", "fsl,imx31-epit";
> + reg = <0x020d0000 0x4000>;
> + interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_EPIT1>,
> + <&clks IMX6QDL_CLK_IPG_PER>;
> + clock-names = "ipg", "per";
It looks like "ipg" and "per" clocks are swapped, please double check it.
> + };
>
--
With best wishes,
Vladimir
^ permalink raw reply
* linux-next: manual merge of the regulator tree with the arm-soc tree
From: Linus Walleij @ 2018-05-30 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530150711.2c7c1fe9@canb.auug.org.au>
On Wed, May 30, 2018 at 7:07 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Today's linux-next merge of the regulator tree got a conflict in:
>
> arch/arm/mach-omap1/board-ams-delta.c
>
> between commit:
>
> 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables")
>
> from the arm-soc tree and commit:
>
> 6059577cb28d ("regulator: fixed: Convert to use GPIO descriptor only")
>
> from the regulator tree.
>
> I fixed it up (see below - it may be better done) and can carry the fix
> as necessary.
OMG that patch on a patch makes my head spin.
I think I just have to look at the eventual result in linux-next and see if
it makes proper sense, and rely on Janusz to test the result and help
to fix it up.
I was unaware of this concurrent gpiod conversion inside OMAP1 but
I'm happy to see that it happens. We might have some fallout, but I'm
sure Janusz is on top of things.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: Christoph Hellwig @ 2018-05-30 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6c317ed8-cca3-8862-5f3b-12cf14e4d53b@codeaurora.org>
On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
> Bjorn and I discussed the need for such a "safe" mode feature when you
> want to bring up PCI for a platform. You want to turn off everything as
> a starter and just stick to bare minimum.
Can we please make it a config option the instead of adding code
to every kernel? Also maybe the bringup should be in the name
to make this more clear?
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 308/940] drivers/usb/dwc3/core.h:1225: multiple definition of `dwc3_simple_wakeup_capable'
From: kbuild test robot @ 2018-05-30 7:37 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 7a6053b3d256fa5bc23f28a9d9a23d7a2004c5b7
commit: c46d066e5633e178b138742850c37ed262a9af6d [308/940] dwc3: Add support for clock disabling during suspend
config: i386-randconfig-s0-201821 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout c46d066e5633e178b138742850c37ed262a9af6d
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/usb/dwc3/trace.o: In function `dwc3_simple_wakeup_capable':
>> drivers/usb/dwc3/core.h:1225: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1225: first defined here
drivers/usb/dwc3/host.o: In function `dwc3_simple_wakeup_capable':
include/linux/device.h:984: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1225: first defined here
drivers/usb/dwc3/ulpi.o: In function `dwc3_simple_wakeup_capable':
>> drivers/usb/dwc3/core.h:1225: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1225: first defined here
drivers/usb/dwc3/debugfs.o: In function `dwc3_simple_wakeup_capable':
>> drivers/usb/dwc3/core.h:1225: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1225: first defined here
vim +1225 drivers/usb/dwc3/core.h
1214
1215 #if IS_ENABLED(CONFIG_USB_DWC3_OF_SIMPLE)
1216 int dwc3_enable_hw_coherency(struct device *dev);
1217 void dwc3_set_phydata(struct device *dev, struct phy *phy);
1218 void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup);
1219 #else
1220 static inline int dwc3_enable_hw_coherency(struct device *dev)
1221 { return 1; }
1222 static inline void dwc3_set_phydata(struct device *dev, struct phy *phy)
1223 { ; }
1224 void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
> 1225 { ; }
1226 #endif
1227
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/58a25a5f/attachment-0001.gz>
^ permalink raw reply
* [PATCH v3 3/5] Documentation: DT: add i.MX EPIT timer binding
From: Vladimir Zapolskiy @ 2018-05-30 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7f2f8b6b-b7f6-99c1-fc5f-a7628a751fdc@mentor.com>
On 05/30/2018 10:27 AM, Vladimir Zapolskiy wrote:
> Hi Cl?ment,
>
> On 05/29/2018 08:04 PM, Cl?ment P?ron wrote:
>> From: Cl?ment Peron <clement.peron@devialet.com>
>>
>> Add devicetree binding document for NXP's i.MX SoC specific
>> EPIT timer driver.
>>
>> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
>> ---
>> .../devicetree/bindings/clock/imx6q,epit.txt | 24 +++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/imx6q,epit.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/imx6q,epit.txt b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
>> new file mode 100644
>> index 000000000000..a84a60c6ae35
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
>
> The file should be renamed to a more generic name like 'imx,epit.txt'
> or 'imx31,epit.txt'.
>
> Also note that the folder is incorrectly selected, it must be
> Documentation/devicetree/bindings/timer/
>
And linux-clk mailing list for publishing seems to be improper one,
instead please add Daniel Lezcano <daniel.lezcano@linaro.org> and
Thomas Gleixner <tglx@linutronix.de> to the list of addressees,
and the proper mailing list address is linux-kernel at vger.kernel.org
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: okaya at codeaurora.org @ 2018-05-30 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530073735.GA28793@infradead.org>
On 2018-05-30 00:37, Christoph Hellwig wrote:
> On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
>> Bjorn and I discussed the need for such a "safe" mode feature when you
>> want to bring up PCI for a platform. You want to turn off everything
>> as
>> a starter and just stick to bare minimum.
>
> Can we please make it a config option the instead of adding code
> to every kernel? Also maybe the bringup should be in the name
> to make this more clear?
One other requirement was to have a runtime option rather than compile
time option.
When someone reported a problem, we wanted to be able to say "use this
option and see if system boots" without doing any bisects or
recompilation.
This would be the first step in troubleshooting a system to see if
fundamental features are working.
I don't mind changing the name
Bjorn mentioned safe option. I made it safemode. I am looking at Bjorn
for suggestions at this moment.
^ permalink raw reply
* [PATCH 08/12] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: kbuild test robot @ 2018-05-30 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527500833-16005-9-git-send-email-m.purski@samsung.com>
Hi Maciej,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20180517]
[cannot apply to drm-exynos/exynos-drm/for-next robh/for-next drm/drm-next v4.17-rc6 v4.17-rc5 v4.17-rc4 v4.17-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Maciej-Purski/Add-TOSHIBA-TC358764-DSI-LVDS-bridge-driver/20180530-011258
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/bridge/tc358764.c:193:14: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [addressable] [usertype] addr @@ got ed] [addressable] [usertype] addr @@
drivers/gpu/drm/bridge/tc358764.c:193:14: expected unsigned short [unsigned] [addressable] [usertype] addr
drivers/gpu/drm/bridge/tc358764.c:193:14: got restricted __le16 [usertype] <noident>
>> drivers/gpu/drm/bridge/tc358764.c:197:24: sparse: cast to restricted __le32
>> drivers/gpu/drm/bridge/tc358764.c:175:5: sparse: symbol 'tc358764_read' was not declared. Should it be static?
>> drivers/gpu/drm/bridge/tc358764.c:204:5: sparse: symbol 'tc358764_write' was not declared. Should it be static?
vim +193 drivers/gpu/drm/bridge/tc358764.c
174
> 175 int tc358764_read(struct tc358764 *ctx, u16 addr, u32 *val)
176 {
177 struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
178 const struct mipi_dsi_host_ops *ops = dsi->host->ops;
179 struct mipi_dsi_msg msg = {
180 .type = MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM,
181 .channel = dsi->channel,
182 .flags = MIPI_DSI_MSG_USE_LPM,
183 .tx_buf = &addr,
184 .tx_len = 2,
185 .rx_buf = val,
186 .rx_len = 4
187 };
188 ssize_t ret;
189
190 if (!ops || !ops->transfer)
191 return -EINVAL;
192
> 193 addr = cpu_to_le16(addr);
194
195 ret = ops->transfer(dsi->host, &msg);
196 if (ret >= 0)
> 197 *val = le32_to_cpu(*val);
198
199 dev_dbg(ctx->dev, "read: %d, addr: %d\n", addr, *val);
200
201 return ret;
202 }
203
> 204 int tc358764_write(struct tc358764 *ctx, u16 addr, u32 val)
205 {
206 struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
207 const struct mipi_dsi_host_ops *ops = dsi->host->ops;
208 u8 data[6];
209 int ret;
210 struct mipi_dsi_msg msg = {
211 .type = MIPI_DSI_GENERIC_LONG_WRITE,
212 .channel = dsi->channel,
213 .flags = MIPI_DSI_MSG_USE_LPM | MIPI_DSI_MSG_REQ_ACK,
214 .tx_buf = data,
215 .tx_len = 6
216 };
217
218 if (!ops || !ops->transfer)
219 return -EINVAL;
220
221 data[0] = addr;
222 data[1] = addr >> 8;
223 data[2] = val;
224 data[3] = val >> 8;
225 data[4] = val >> 16;
226 data[5] = val >> 24;
227
228 ret = ops->transfer(dsi->host, &msg);
229
230 return ret;
231 }
232
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: Greg Kroah-Hartman @ 2018-05-30 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6dfe2db8f974d94c9867f30ec83d9333@codeaurora.org>
On Wed, May 30, 2018 at 12:44:29AM -0700, okaya at codeaurora.org wrote:
> On 2018-05-30 00:37, Christoph Hellwig wrote:
> > On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
> > > Bjorn and I discussed the need for such a "safe" mode feature when you
> > > want to bring up PCI for a platform. You want to turn off everything
> > > as
> > > a starter and just stick to bare minimum.
> >
> > Can we please make it a config option the instead of adding code
> > to every kernel? Also maybe the bringup should be in the name
> > to make this more clear?
>
> One other requirement was to have a runtime option rather than compile time
> option.
>
> When someone reported a problem, we wanted to be able to say "use this
> option and see if system boots" without doing any bisects or recompilation.
>
> This would be the first step in troubleshooting a system to see if
> fundamental features are working.
That makes sense, people can not rebuild their kernels for the most
part. Putting it behind a config option would not make sense as it
would always have to be enabled.
> I don't mind changing the name Bjorn mentioned safe option. I made it
> safemode. I am looking at Bjorn for suggestions at this moment.
"minimal"? "basic"? "crippled"?
"my_hardware_is_so_borked_it_needs_this_option"? :)
Naming is hard...
greg k-h
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: okaya at codeaurora.org @ 2018-05-30 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530074822.GB30177@kroah.com>
On 2018-05-30 00:48, Greg Kroah-Hartman wrote:
> On Wed, May 30, 2018 at 12:44:29AM -0700, okaya at codeaurora.org wrote:
>> On 2018-05-30 00:37, Christoph Hellwig wrote:
>> > On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
>> > > Bjorn and I discussed the need for such a "safe" mode feature when you
>> > > want to bring up PCI for a platform. You want to turn off everything
>> > > as
>> > > a starter and just stick to bare minimum.
>> >
>> > Can we please make it a config option the instead of adding code
>> > to every kernel? Also maybe the bringup should be in the name
>> > to make this more clear?
>>
>> One other requirement was to have a runtime option rather than compile
>> time
>> option.
>>
>> When someone reported a problem, we wanted to be able to say "use this
>> option and see if system boots" without doing any bisects or
>> recompilation.
>>
>> This would be the first step in troubleshooting a system to see if
>> fundamental features are working.
>
> That makes sense, people can not rebuild their kernels for the most
> part. Putting it behind a config option would not make sense as it
> would always have to be enabled.
>
Here is where the discussion took place. Last 5-10 messages should
help.
https://bugzilla.kernel.org/show_bug.cgi?id=196197
>> I don't mind changing the name Bjorn mentioned safe option. I made it
>> safemode. I am looking at Bjorn for suggestions at this moment.
>
> "minimal"? "basic"? "crippled"?
> "my_hardware_is_so_borked_it_needs_this_option"? :)
>
> Naming is hard...
>
> greg k-h
^ permalink raw reply
* [PATCH v3 0/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding @ 2018-05-30 8:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Thierry Reding <treding@nvidia.com>
An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code
and Tegra SMMU driver changes to support IOMMU groups introduced a boot-
time regression on Tegra124. This was caught very late because none of
the standard configurations that are tested on Tegra enable the ARM DMA/
IOMMU mapping code since it is not needed.
The reason for the failure is that the GPU found on Tegra uses a special
bit in physical addresses to determine whether or not a buffer is mapped
through the SMMU. In order to achieve this, the Nouveau driver needs to
explicitly understand which buffers are mapped through the SMMU and
which aren't. Hiding usage of the SMMU behind the DMA API is bound to
fail because the knowledge doesn't exist. Furthermore, the GPU has its
own IOMMU and in most cases doesn't need buffers to be physically or
virtually contiguous. One notable exception is for compressible buffers
which need to be mapped with large pages, which in turn require all the
small pages in a large page to be contiguous. This can be achieved with
an SMMU mapping, though it isn't currently supported in Nouveau. Since
Translating through the SMMU is unnecessary and can have a negative
impact on performance for the common case, so we want to avoid it when
possible.
This series of patches adds a 32-bit ARM specific API that allows a
driver to detach the device from the DMA/IOMMU mapping so that it can
provide its own implementation for dealing with the SMMU. The second
patch makes use of that new API in the Nouveau driver to fix the
regression.
Thierry
Thierry Reding (2):
ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
arch/arm/include/asm/dma-mapping.h | 3 +++
arch/arm/mm/dma-mapping-nommu.c | 4 ++++
arch/arm/mm/dma-mapping.c | 16 ++++++++++++++++
.../gpu/drm/nouveau/nvkm/engine/device/tegra.c | 5 +++++
4 files changed, 28 insertions(+)
--
2.17.0
^ permalink raw reply
* [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()
From: Thierry Reding @ 2018-05-30 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530080345.2353-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
Implement this function to enable drivers from detaching from any IOMMU
domains that architecture code might have attached them to so that they
can take exclusive control of the IOMMU via the IOMMU API.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v3:
- make API 32-bit ARM specific
- avoid extra local variable
Changes in v2:
- fix compilation
arch/arm/include/asm/dma-mapping.h | 3 +++
arch/arm/mm/dma-mapping-nommu.c | 4 ++++
arch/arm/mm/dma-mapping.c | 16 ++++++++++++++++
3 files changed, 23 insertions(+)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index 8436f6ade57d..5960e9f3a9d0 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -103,6 +103,9 @@ extern void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
#define arch_teardown_dma_ops arch_teardown_dma_ops
extern void arch_teardown_dma_ops(struct device *dev);
+#define arm_dma_iommu_detach_device arm_dma_iommu_detach_device
+extern void arm_dma_iommu_detach_device(struct device *dev);
+
/* do not use this function in a driver */
static inline bool is_device_dma_coherent(struct device *dev)
{
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index f448a0663b10..eb781369377b 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -241,3 +241,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
void arch_teardown_dma_ops(struct device *dev)
{
}
+
+void arm_dma_iommu_detach_device(struct device *dev)
+{
+}
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index af27f1c22d93..6d8af08b3e7d 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2400,3 +2400,19 @@ void arch_teardown_dma_ops(struct device *dev)
arm_teardown_iommu_dma_ops(dev);
}
+
+void arm_dma_iommu_detach_device(struct device *dev)
+{
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
+ struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+
+ if (!mapping)
+ return;
+
+ arm_iommu_release_mapping(mapping);
+ arm_iommu_detach_device(dev);
+
+ set_dma_ops(dev, arm_get_dma_map_ops(dev->archdata.dma_coherent));
+#endif
+}
+EXPORT_SYMBOL(arm_dma_iommu_detach_device);
--
2.17.0
^ permalink raw reply related
* [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping
From: Thierry Reding @ 2018-05-30 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530080345.2353-1-thierry.reding@gmail.com>
From: Thierry Reding <treding@nvidia.com>
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to a DMA/IOMMU mapping that transparently uses
the IOMMU to back the DMA API. Tegra requires special handling for IOMMU
backed buffers (a special bit in the GPU's MMU page tables indicates the
memory path to take: via the SMMU or directly to the memory controller).
Transparently backing DMA memory with an IOMMU prevents Nouveau from
properly handling such memory accesses and causes memory access faults.
As a side-note: buffers other than those allocated in instance memory
don't need to be physically contiguous from the GPU's perspective since
the GPU can map them into contiguous buffers using its own MMU. Mapping
these buffers through the IOMMU is unnecessary and will even lead to
performance degradation because of the additional translation. One
exception to this are compressible buffers which need large pages. In
order to enable these large pages, multiple small pages will have to be
combined into one large (I/O virtually contiguous) mapping via the
IOMMU. However, that is a topic outside the scope of this fix and isn't
currently supported. An implementation will want to explicitly create
these large pages in the Nouveau driver, so detaching from a DMA/IOMMU
mapping would still be required.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
Changes in v3:
- clarify the use of IOMMU mapping for compressible buffers
- squash multiple patches into this
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 78597da6313a..d0538af1b967 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -105,6 +105,11 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra *tdev)
unsigned long pgsize_bitmap;
int ret;
+#if IS_ENABLED(CONFIG_ARM)
+ /* make sure we can use the IOMMU exclusively */
+ arm_dma_iommu_detach_device(dev);
+#endif
+
if (!tdev->func->iommu_bit)
return;
--
2.17.0
^ permalink raw reply related
* [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Mark Rutland @ 2018-05-30 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E490CD805F7529488761C40FD9D26EF12A672E03@dggemm507-mbx.china.huawei.com>
On Wed, May 30, 2018 at 03:31:38AM +0000, Nixiaoming wrote:
> Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=arm64
Indeed. Making this mandatory was a deliberate decision, in part because this
allows simplification of code (e.g. removal of #ifdef guards).
> When reading the code, I feel it is more appropriate to add macro control
> here.
I must disagree. I do not think it makes sense to add an #ifdef for a
configuration option that is mandatory.
There are other places in the kernel that should behave differently if
CONFIG_STRICT_KERNEL_RWX were disabled, so this wouldn't be sufficient even if
we were to make CONFIG_STRICT_KERNEL_RWX optional. i.e. the #ifdef would give
the misleading impression that STRICT_KERNEL_RWX *could* be made optional, even
though this might not function correctly.
Having an #ifdef here makes the code more complicated and confusing, for the
benefit of a case which cannot occur.
Thanks,
Mark.
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Tuesday, May 29, 2018 11:45 PM
> To: Nixiaoming <nixiaoming@huawei.com>
> Cc: catalin.marinas at arm.com; ard.biesheuvel at linaro.org; marc.zyngier at arm.com; james.morse at arm.com; kristina.martsenko at arm.com; steve.capper at arm.com; tglx at linutronix.de; mingo at redhat.com; hpa at zytor.com; akpm at linux-foundation.org; vbabka at suse.cz; mhocko at suse.com; dave.hansen at linux.intel.com; dan.j.williams at intel.com; kirill.shutemov at linux.intel.com; zhang.jia at linux.alibaba.com; schwidefsky at de.ibm.com; heiko.carstens at de.ibm.com; gregkh at linuxfoundation.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; x86 at kernel.org; linux-s390 at vger.kernel.org
> Subject: Re: [PATCH 1/3] arm64:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
>
> On Tue, May 29, 2018 at 09:36:15PM +0800, nixiaoming wrote:
> > mark_rodata_ro is only called by the function mark_readonly when
> > CONFIG_STRICT_KERNEL_RWX=y,
> > if CONFIG_STRICT_KERNEL_RWX is not set
> > a compile warning may be triggered: unused function
>
> How are you achieving this configuration? In our Kconfig we select this
> unconditionally.
>
> Will
^ permalink raw reply
* [PATCH v3 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Michel Pollet @ 2018-05-30 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWv2ZRbX=k5+H_WfAeoQ4QsyQLU9iQ9TJ9OQ0fmwg0GOQ@mail.gmail.com>
On 25 May 2018 10:49, Geert wrote:
> Subject: Re: [PATCH v3 2/3] arm: shmobile: Add the R9A06G032 SMP enabler
> driver
>
> Hi Michel,
Hi Geert,
>
> On Thu, May 24, 2018 at 12:30 PM, Michel Pollet
> <michel.pollet@bp.renesas.com> wrote:
> > The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
> > it requires a special enable method to get it started.
> >
> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>
> Thanks for your patch!
>
> > arch/arm/mach-shmobile/smp-r9a06g032.c | 85
> > ++++++++++++++++++++++++++++++++++
>
> I think you can safely call this driver smp-rzn1d.c, or smp-rzn1.c.
> Source files are not covered by the stable DT ABI, and can be reordered later
> at will.
>
> I expect you will just add more CPU_METHOD_OF_DECLARE() lines later
> (perhaps with a little bit of extra code to handle deviations).
Now I am completely confused -- you had me remove the mention of rzn1
from everywhere it mattered to handle 'family' cases, and now you are
telling me that in *this* case where there is not a single chance of that file
covering another part and there's a clear cut case for it to be part specific
.... I should call it rzn1?!?
I even already renamed the symbols on my tree to match the
rest for v4...
I'd like consistency -- I *thought* I had a consistent naming scheme before,
now I've moved to your part specific one (under duress), I'd rather stick to
something that is consistent and keep everything as r9a06g032 now.
>
> > --- /dev/null
> > +++ b/arch/arm/mach-shmobile/smp-r9a06g032.c
> > @@ -0,0 +1,85 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * RZ/N1D Second CA7 enabler.
> > + *
> > + * Copyright (C) 2018 Renesas Electronics Europe Limited
> > + *
> > + * Michel Pollet <michel.pollet@bp.renesas.com>,
> <buserror@gmail.com>
> > + * Derived from action,s500-smp
> > + */
> > +
> > +#include <linux/delay.h>
>
> Do you need this?
Fixed all the other remarks, thanks for that!
Michel
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
^ permalink raw reply
* [PATCH] PCI: Add pci=safemode option
From: okaya at codeaurora.org @ 2018-05-30 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <577f01ada5e7f08c79a28d41020fb019@codeaurora.org>
On 2018-05-30 00:56, okaya at codeaurora.org wrote:
> On 2018-05-30 00:48, Greg Kroah-Hartman wrote:
>> On Wed, May 30, 2018 at 12:44:29AM -0700, okaya at codeaurora.org wrote:
>>> On 2018-05-30 00:37, Christoph Hellwig wrote:
>>> > On Tue, May 29, 2018 at 09:41:33PM -0700, Sinan Kaya wrote:
>>> > > Bjorn and I discussed the need for such a "safe" mode feature when you
>>> > > want to bring up PCI for a platform. You want to turn off everything
>>> > > as
>>> > > a starter and just stick to bare minimum.
>>> >
>>> > Can we please make it a config option the instead of adding code
>>> > to every kernel? Also maybe the bringup should be in the name
>>> > to make this more clear?
>>>
>>> One other requirement was to have a runtime option rather than
>>> compile time
>>> option.
>>>
>>> When someone reported a problem, we wanted to be able to say "use
>>> this
>>> option and see if system boots" without doing any bisects or
>>> recompilation.
>>>
>>> This would be the first step in troubleshooting a system to see if
>>> fundamental features are working.
>>
>> That makes sense, people can not rebuild their kernels for the most
>> part. Putting it behind a config option would not make sense as it
>> would always have to be enabled.
>>
>
> Here is where the discussion took place. Last 5-10 messages should
> help.
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=196197
>
Some more paper trail for general awareness.
https://lkml.org/lkml/2018/5/3/509
>
>>> I don't mind changing the name Bjorn mentioned safe option. I made it
>>> safemode. I am looking at Bjorn for suggestions at this moment.
>>
>> "minimal"? "basic"? "crippled"?
>> "my_hardware_is_so_borked_it_needs_this_option"? :)
>>
>> Naming is hard...
>>
>> greg k-h
^ permalink raw reply
* [xlnx:xlnx_rebase_v4.14 309/940] drivers/usb/dwc3/core.h:1228: multiple definition of `dwc3_set_simple_data'
From: kbuild test robot @ 2018-05-30 8:24 UTC (permalink / raw)
To: linux-arm-kernel
tree: https://github.com/Xilinx/linux-xlnx xlnx_rebase_v4.14
head: 7a6053b3d256fa5bc23f28a9d9a23d7a2004c5b7
commit: 6b1601e752dd266a096860421d488efc8cffdc1f [309/940] dwc3: Add support for removing vbus when suspended
config: i386-randconfig-s0-201821 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 6b1601e752dd266a096860421d488efc8cffdc1f
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/usb/dwc3/trace.o: In function `dwc3_simple_wakeup_capable':
drivers/usb/dwc3/core.h:1226: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1226: first defined here
drivers/usb/dwc3/trace.o: In function `dwc3_set_simple_data':
>> drivers/usb/dwc3/core.h:1228: multiple definition of `dwc3_set_simple_data'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1228: first defined here
drivers/usb/dwc3/host.o: In function `dwc3_simple_wakeup_capable':
include/linux/device.h:984: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1226: first defined here
drivers/usb/dwc3/host.o: In function `dwc3_set_simple_data':
>> drivers/usb/dwc3/core.h:1228: multiple definition of `dwc3_set_simple_data'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1228: first defined here
drivers/usb/dwc3/ulpi.o: In function `dwc3_simple_wakeup_capable':
drivers/usb/dwc3/core.h:1226: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1226: first defined here
drivers/usb/dwc3/ulpi.o: In function `dwc3_set_simple_data':
>> drivers/usb/dwc3/core.h:1228: multiple definition of `dwc3_set_simple_data'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1228: first defined here
drivers/usb/dwc3/debugfs.o: In function `dwc3_simple_wakeup_capable':
drivers/usb/dwc3/core.h:1226: multiple definition of `dwc3_simple_wakeup_capable'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1226: first defined here
drivers/usb/dwc3/debugfs.o: In function `dwc3_set_simple_data':
>> drivers/usb/dwc3/core.h:1228: multiple definition of `dwc3_set_simple_data'
drivers/usb/dwc3/core.o:drivers/usb/dwc3/core.h:1228: first defined here
vim +1228 drivers/usb/dwc3/core.h
1214
1215 #if IS_ENABLED(CONFIG_USB_DWC3_OF_SIMPLE)
1216 int dwc3_enable_hw_coherency(struct device *dev);
1217 void dwc3_set_phydata(struct device *dev, struct phy *phy);
1218 void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup);
1219 void dwc3_set_simple_data(struct dwc3 *dwc);
1220 #else
1221 static inline int dwc3_enable_hw_coherency(struct device *dev)
1222 { return 1; }
1223 static inline void dwc3_set_phydata(struct device *dev, struct phy *phy)
1224 { ; }
1225 void dwc3_simple_wakeup_capable(struct device *dev, bool wakeup)
> 1226 { ; }
1227 void dwc3_set_simple_data(struct dwc3 *dwc)
> 1228 { ; }
1229 #endif
1230
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 29088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180530/4de03207/attachment-0001.gz>
^ permalink raw reply
* [PATCH 08/12] drm/bridge: tc358764: Add DSI to LVDS bridge driver
From: Andrzej Hajda @ 2018-05-30 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201805301553.AcTypuC4%fengguang.wu@intel.com>
Hi Maciej,
On 30.05.2018 09:45, kbuild test robot wrote:
> Hi Maciej,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on next-20180517]
> [cannot apply to drm-exynos/exynos-drm/for-next robh/for-next drm/drm-next v4.17-rc6 v4.17-rc5 v4.17-rc4 v4.17-rc7]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/Maciej-Purski/Add-TOSHIBA-TC358764-DSI-LVDS-bridge-driver/20180530-011258
> reproduce:
> # apt-get install sparse
> make ARCH=x86_64 allmodconfig
> make C=1 CF=-D__CHECK_ENDIAN__
>
>
> sparse warnings: (new ones prefixed by >>)
>
>>> drivers/gpu/drm/bridge/tc358764.c:193:14: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [unsigned] [addressable] [usertype] addr @@ got ed] [addressable] [usertype] addr @@
> drivers/gpu/drm/bridge/tc358764.c:193:14: expected unsigned short [unsigned] [addressable] [usertype] addr
> drivers/gpu/drm/bridge/tc358764.c:193:14: got restricted __le16 [usertype] <noident>
>>> drivers/gpu/drm/bridge/tc358764.c:197:24: sparse: cast to restricted __le32
>>> drivers/gpu/drm/bridge/tc358764.c:175:5: sparse: symbol 'tc358764_read' was not declared. Should it be static?
>>> drivers/gpu/drm/bridge/tc358764.c:204:5: sparse: symbol 'tc358764_write' was not declared. Should it be static?
> vim +193 drivers/gpu/drm/bridge/tc358764.c
>
> 174
> > 175 int tc358764_read(struct tc358764 *ctx, u16 addr, u32 *val)
add static
> 176 {
> 177 struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> 178 const struct mipi_dsi_host_ops *ops = dsi->host->ops;
> 179 struct mipi_dsi_msg msg = {
> 180 .type = MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM,
> 181 .channel = dsi->channel,
> 182 .flags = MIPI_DSI_MSG_USE_LPM,
> 183 .tx_buf = &addr,
> 184 .tx_len = 2,
> 185 .rx_buf = val,
> 186 .rx_len = 4
> 187 };
> 188 ssize_t ret;
> 189
> 190 if (!ops || !ops->transfer)
> 191 return -EINVAL;
> 192
> > 193 addr = cpu_to_le16(addr);
It should be changed to:
cpu_to_le16s(&addr);
> 194
> 195 ret = ops->transfer(dsi->host, &msg);
> 196 if (ret >= 0)
> > 197 *val = le32_to_cpu(*val);
le32_to_cpus(val);
> 198
> 199 dev_dbg(ctx->dev, "read: %d, addr: %d\n", addr, *val);
> 200
> 201 return ret;
> 202 }
> 203
> > 204 int tc358764_write(struct tc358764 *ctx, u16 addr, u32 val)
add static
Regards
Andrzej
> 205 {
> 206 struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> 207 const struct mipi_dsi_host_ops *ops = dsi->host->ops;
> 208 u8 data[6];
> 209 int ret;
> 210 struct mipi_dsi_msg msg = {
> 211 .type = MIPI_DSI_GENERIC_LONG_WRITE,
> 212 .channel = dsi->channel,
> 213 .flags = MIPI_DSI_MSG_USE_LPM | MIPI_DSI_MSG_REQ_ACK,
> 214 .tx_buf = data,
> 215 .tx_len = 6
> 216 };
> 217
> 218 if (!ops || !ops->transfer)
> 219 return -EINVAL;
> 220
> 221 data[0] = addr;
> 222 data[1] = addr >> 8;
> 223 data[2] = val;
> 224 data[3] = val >> 8;
> 225 data[4] = val >> 16;
> 226 data[5] = val >> 24;
> 227
> 228 ret = ops->transfer(dsi->host, &msg);
> 229
> 230 return ret;
> 231 }
> 232
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
>
>
^ permalink raw reply
* [PATCH v3 2/3] arm: shmobile: Add the R9A06G032 SMP enabler driver
From: Geert Uytterhoeven @ 2018-05-30 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <OSBPR01MB20546AE06422C9AD896F8F60D26C0@OSBPR01MB2054.jpnprd01.prod.outlook.com>
Hi Michel,
On Wed, May 30, 2018 at 10:19 AM, Michel Pollet
<michel.pollet@bp.renesas.com> wrote:
> On 25 May 2018 10:49, Geert wrote:
>> On Thu, May 24, 2018 at 12:30 PM, Michel Pollet
>> <michel.pollet@bp.renesas.com> wrote:
>> > The Renesas R9A06G032 second CA7 is parked in a ROM pen at boot time,
>> > it requires a special enable method to get it started.
>> >
>> > Signed-off-by: Michel Pollet <michel.pollet@bp.renesas.com>
>>
>> Thanks for your patch!
>>
>> > arch/arm/mach-shmobile/smp-r9a06g032.c | 85
>> > ++++++++++++++++++++++++++++++++++
>>
>> I think you can safely call this driver smp-rzn1d.c, or smp-rzn1.c.
>> Source files are not covered by the stable DT ABI, and can be reordered later
>> at will.
>>
>> I expect you will just add more CPU_METHOD_OF_DECLARE() lines later
>> (perhaps with a little bit of extra code to handle deviations).
>
> Now I am completely confused -- you had me remove the mention of rzn1
> from everywhere it mattered to handle 'family' cases, and now you are
> telling me that in *this* case where there is not a single chance of that file
> covering another part and there's a clear cut case for it to be part specific
> .... I should call it rzn1?!?
Sorry for confusing you.
There's a difference between stable DT ABI and (non-existing) kernel stable ABI.
A driver that handles multiple SoCs can be named after the SoC family.
I agree this one is a bit special, as only RZ/N1D has the dual Cortex A7
(RZ/N1S has a single A7, RZ/N1L has no A7), so for now[*] there's no need
to use it on anything but r9a06g032 aka RZ/N1D.
> I'd like consistency -- I *thought* I had a consistent naming scheme before,
> now I've moved to your part specific one (under duress), I'd rather stick to
> something that is consistent and keep everything as r9a06g032 now.
OK for me. Driver names can be changed any time.
[*] Until e.g. a quad A7 arrives :-)
Perhaps this can also be used to enable the A7s on both RZ/N1D and
RZ/N1S when running Linux on the Cortex M3?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v9 00/12] Support PPTT for ARM64
From: Morten Rasmussen @ 2018-05-30 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdWgsRTqrgwi5Z_xyNXmzS1h4gxLaawdFAL_DGF+Yt8s-A@mail.gmail.com>
On Tue, May 29, 2018 at 05:50:47PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> >>>> <catalin.marinas@arm.com> wrote:
> >>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> >>>>>> Jeremy Linton (12):
> >>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
> >>>>>
> >>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> >>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> >>>>> can add it separately).
> >>>>
> >>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> >>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
> >>>> system suspend on big.LITTLE systems to hang after shutting down the first
> >>>> CPU:
> >>>>
> >>>> $ echo mem > /sys/power/state
> >>>> PM: suspend entry (deep)
> >>>> PM: Syncing filesystems ... done.
> >>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
> >>>> OOM killer disabled.
> >>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> >>>> Disabling non-boot CPUs ...
> >>>> CPU1: shutdown
> >>>> psci: CPU1 killed.
> >>>
> >>> Is it OK to assume the suspend failed just after shutting down one CPU
> >>> or it's failing during resume ? It depends on whether you had console
> >>> disabled or not.
> >>
> >> I have no-console-suspend enabled.
> >> It's failing during suspend, the next lines should be:
> >>
> >> CPU2: shutdown
> >> psci: CPU2 killed.
> >> ...
> >
> > OK, I was hoping to be something during resume as this patch has nothing
> > executed during suspend. Do you see any change in topology before and
> > after this patch applied. I am interested in the output of:
> >
> > $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
> /sys/devices/system/cpu/cpu0/topology/core_id:0
> /sys/devices/system/cpu/cpu0/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu0/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu0/topology/thread_siblings:01
> /sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
> /sys/devices/system/cpu/cpu1/topology/core_id:1
> /sys/devices/system/cpu/cpu1/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu1/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu1/topology/thread_siblings:02
> /sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
> /sys/devices/system/cpu/cpu2/topology/core_id:2
> /sys/devices/system/cpu/cpu2/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu2/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu2/topology/thread_siblings:04
> /sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
> /sys/devices/system/cpu/cpu3/topology/core_id:3
> /sys/devices/system/cpu/cpu3/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu3/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu3/topology/thread_siblings:08
> /sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
> /sys/devices/system/cpu/cpu4/topology/core_id:0
> /sys/devices/system/cpu/cpu4/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu4/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu4/topology/thread_siblings:10
> /sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
> /sys/devices/system/cpu/cpu5/topology/core_id:1
> /sys/devices/system/cpu/cpu5/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu5/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu5/topology/thread_siblings:20
> /sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
> /sys/devices/system/cpu/cpu6/topology/core_id:2
> /sys/devices/system/cpu/cpu6/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu6/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu6/topology/thread_siblings:40
> /sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
> /sys/devices/system/cpu/cpu7/topology/core_id:3
> /sys/devices/system/cpu/cpu7/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu7/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu7/topology/thread_siblings:80
> /sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
>
> No change before/after (both match my view of the hardware).
There shouldn't be any change in the reported topology with this patch
as that the topology_* functions are not touched by the patch.
The patch should only affect the topology used by the scheduler which
isn't necessarily the same as the user-space visible one.
Morten
^ permalink raw reply
* [PATCH 1/4] arm64: capabilities: add nopti command line argument
From: Suzuki K Poulose @ 2018-05-30 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524190932.32118-2-mlangsdo@redhat.com>
Hi Mark,
On 24/05/18 20:09, Mark Langsdorf wrote:
> The x86 kernel and the documentation use 'nopti' as the kernel command
> line argument to disable kernel page table isolation, so add nopti to
> the arm64 kernel for compatibility.
>
> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 +++---
> arch/arm64/kernel/cpufeature.c | 11 ++++++++++-
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index f2040d4..a987725 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -3342,8 +3342,8 @@
> pt. [PARIDE]
> See Documentation/blockdev/paride.txt.
>
> - pti= [X86_64] Control Page Table Isolation of user and
> - kernel address spaces. Disabling this feature
> + pti= [X86_64, ARM64] Control Page Table Isolation of user
> + and kernel address spaces. Disabling this feature
> removes hardening, but improves performance of
> system calls and interrupts.
...
>
> @@ -3354,7 +3354,7 @@
>
> Not specifying this option is equivalent to pti=auto.
>
> - nopti [X86_64]
> + nopti [X86_64, ARM64]
> Equivalent to pti=off
>
> pty.legacy_count=
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9d1b06d..7c5d8712 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -934,10 +934,19 @@ static int __init parse_kpti(char *str)
> if (ret)
> return ret;
>
> - __kpti_forced = enabled ? 1 : -1;
> + if (!__kpti_forced)
> + __kpti_forced = enabled ? 1 : -1;
> return 0;
> }
> __setup("kpti=", parse_kpti);
The arm64 kernel parameter is named "kpti", while the Documentation update above
says "pti". We may want to keep both in sync here.
> +
> +/* for compatibility with documentation and x86 nopti command line arg */
> +static int __init force_nokpti(char *arg)
> +{
> + __kpti_forced = -1;
> + return 0;
> +}
> +early_param("nopti", force_nokpti);
> #endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
>
> #ifdef CONFIG_ARM64_HW_AFDBM
>
Suzuki
^ permalink raw reply
* [PATCH] arm64: alternative:flush cache with unpatched code
From: Will Deacon @ 2018-05-30 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527617488-5693-1-git-send-email-rokhanna@nvidia.com>
Hi Rohit,
Please keep me on cc for future versions of this patch. Comments inline.
On Tue, May 29, 2018 at 11:11:28AM -0700, Rohit Khanna wrote:
> In the current implementation, __apply_alternatives patches
> flush_icache_range and then executes it without invalidating the icache.
> Thus, icache can contain some of the old instructions for
> flush_icache_range. This can cause unpredictable behavior as during
> execution we can get a mix of old and new instructions for
> flush_icache_range.
>
> This patch :
> 1. Adds a new function flush_cache_kernel_range for flushing kernel
> memory range. This function uses non hot-patched code and can be
> safely used to flush cache during code patching.
>
> 2. Modifies __apply_alternatives so that it uses
> flush_cache_kernel_range to flush the cache range after patching code.
>
> Signed-off-by: Rohit Khanna <rokhanna@nvidia.com>
> ---
> arch/arm64/kernel/alternative.c | 31 +++++++++++++++++++++++++++++--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c
> index 5c4bce4ac381..e93cfd26a314 100644
> --- a/arch/arm64/kernel/alternative.c
> +++ b/arch/arm64/kernel/alternative.c
> @@ -122,6 +122,33 @@ static void patch_alternative(struct alt_instr *alt,
> }
> }
>
> +/* This is used for flushing kernel memory range after
> + * __apply_alternatives has patched kernel code
> + */
> +static void flush_cache_kernel_range(void *start, void *end)
> +{
How about something like clean_dcache_range_nopatch instead?
> + u64 d_start, i_start, d_size, i_size;
> +
> + /* use sanitized value of ctr_el0 rather than raw value from CPU */
> + d_size = 4 << ((arm64_ftr_reg_ctrel0.sys_val >> 0x10) & 0xF); /* bytes */
> + i_size = 4 << (arm64_ftr_reg_ctrel0.sys_val & 0xF); /* bytes */
You should be able to use read_sanitised_ftr_reg() and
cpuid_feature_extract_unsigned_field() here.
> + d_start = (u64)start & ~(d_size - 1);
> + while (d_start <= (u64)end) {
Please add a comment about the A53 erratum this is handling by using
clean+inv.
> + asm volatile("dc civac, %0" : : "r" (d_start));
> + d_start += d_size;
> + }
> + dsb(ish);
> +
> + i_start = (u64)start & ~(i_size - 1);
> + while (i_start <= (u64)end) {
> + asm volatile("ic ivau, %0" : : "r" (i_start));
> + i_start += i_size;
> + }
> + dsb(ish);
> + isb();
As I mentioned before, I think it would be simpler just to avoid doing the
I-cache invalidation by range and instead call __flush_icache_all once we've
exiting the loop in __apply_alternatives.
Will
^ 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