* [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 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: 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 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
* [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] 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
* 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 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
* [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 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 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 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 2/3] ARM: imx: add cpu idle support for i.MX6SLL
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 cpu idle with ARM power gated,
it can reuse i.MX6SX's cpu idle driver to support
below 3 states of cpu idle:
state0: WFI;
state1: WAIT mode with ARM power on;
state2: WAIT mode with ARM power off.
L2_PGE in GPC_CNTR needs to be cleared to support
state2 cpu idle.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/mach-imx/cpuidle-imx6sx.c | 1 +
arch/arm/mach-imx/mach-imx6sl.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c b/arch/arm/mach-imx/cpuidle-imx6sx.c
index d0f14b7..243a108 100644
--- a/arch/arm/mach-imx/cpuidle-imx6sx.c
+++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
@@ -103,6 +103,7 @@ int __init imx6sx_cpuidle_init(void)
{
imx6_set_int_mem_clk_lpm(true);
imx6_enable_rbc(false);
+ imx_gpc_set_l2_mem_power_in_lpm(false);
/*
* set ARM power up/down timing to the fastest,
* sw2iso and sw can be set to one 32K cycle = 31us
diff --git a/arch/arm/mach-imx/mach-imx6sl.c b/arch/arm/mach-imx/mach-imx6sl.c
index c7a1ef1..183540e 100644
--- a/arch/arm/mach-imx/mach-imx6sl.c
+++ b/arch/arm/mach-imx/mach-imx6sl.c
@@ -42,7 +42,10 @@ static void __init imx6sl_init_late(void)
if (IS_ENABLED(CONFIG_ARM_IMX6Q_CPUFREQ))
platform_device_register_simple("imx6q-cpufreq", -1, NULL, 0);
- imx6sl_cpuidle_init();
+ if (cpu_is_imx6sl())
+ imx6sl_cpuidle_init();
+ else
+ imx6sx_cpuidle_init();
}
static void __init imx6sl_init_machine(void)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] ARM: imx: add L2 page power control for GPC
From: Anson Huang @ 2018-05-30 7:12 UTC (permalink / raw)
To: linux-arm-kernel
Some platforms like i.MX6UL/i.MX6SLL have L2
page power control in GPC, it needs to be
disabled if ARM is power gated and L2 is NOT
flushed, add GPC interface to control it.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
arch/arm/mach-imx/common.h | 1 +
arch/arm/mach-imx/gpc.c | 14 ++++++++++++++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index c8d68e9..a2716ec 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -58,6 +58,7 @@ struct device *imx_soc_device_init(void);
void imx6_enable_rbc(bool enable);
void imx_gpc_check_dt(void);
void imx_gpc_set_arm_power_in_lpm(bool power_off);
+void imx_gpc_set_l2_mem_power_in_lpm(bool power_off);
void imx_gpc_set_arm_power_up_timing(u32 sw2iso, u32 sw);
void imx_gpc_set_arm_power_down_timing(u32 sw2iso, u32 sw);
void imx25_pm_init(void);
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index de535cb..e11159d 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -20,6 +20,7 @@
#include "common.h"
#include "hardware.h"
+#define GPC_CNTR 0x0
#define GPC_IMR1 0x008
#define GPC_PGC_CPU_PDN 0x2a0
#define GPC_PGC_CPU_PUPSCR 0x2a4
@@ -27,6 +28,8 @@
#define GPC_PGC_SW2ISO_SHIFT 0x8
#define GPC_PGC_SW_SHIFT 0x0
+#define GPC_CNTR_L2_PGE_SHIFT 22
+
#define IMR_NUM 4
#define GPC_MAX_IRQS (IMR_NUM * 32)
@@ -51,6 +54,17 @@ void imx_gpc_set_arm_power_in_lpm(bool power_off)
writel_relaxed(power_off, gpc_base + GPC_PGC_CPU_PDN);
}
+void imx_gpc_set_l2_mem_power_in_lpm(bool power_off)
+{
+ u32 val;
+
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val &= ~(1 << GPC_CNTR_L2_PGE_SHIFT);
+ if (power_off)
+ val |= 1 << GPC_CNTR_L2_PGE_SHIFT;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+}
+
void imx_gpc_pre_suspend(bool arm_power_off)
{
void __iomem *reg_imr1 = gpc_base + GPC_IMR1;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/4] mmc: sdhci-msm: Add sdhci msm register write APIs which wait for pwr irq
From: Vijay Viswanath @ 2018-05-30 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74a4fe0e-7ae8-9f49-5614-1e01ae977475@linaro.org>
Hi Georgi,
Thanks for testing the patch on 8096 and pointing out this issue.
The issue is coming because, when card is removed, the HOST_CONTROL2
register is retaining the 1.8V Signalling enable bit till SDHCI reset
happens after a new card is inserted.
Adding the change you suggested can avoid this wait, but I feel a better
solution is to clear the 1.8V signalling bit when the card is removed.
When a new card is inserted, we shouldn't be keeping the 1.8V bit set
until we send cmd11 to the SD card. A new SD card should start with 3V.
One solution is to explicitly clear the HOST_CONTROL2 register when card
is removed.
Other way is to revert the commit:
9718f84b85396e090ca42fafa730410d286d61e3 "mmc: sdhci-msm: Do not reset
the controller if no card in the slot"
The sdhci-msm doesn't require "SDHCI_QUIRK_NO_CARD_NO_RESET". The issue
which above commit is trying to avoid is fixed by the pwr-irq patches.
Resetting the controller will clear the HOST_CONTROL2 register and avoid
this issue.
Can you please try this ? I tested reverting the QUIRK on two platforms:
db410c(8916) and sdm845. SD card insert/remove worked fine after that
and I didn't get any "Reset 0x1 never completed" error during card
insert/remove or shutdown.
Thanks,
Vijay
On 5/29/2018 5:49 PM, Georgi Djakov wrote:
> Hello Vijay,
>
> On 09/27/2017 08:34 AM, Vijay Viswanath wrote:
>> Register writes which change voltage of IO lines or turn the IO bus
>> on/off require controller to be ready before progressing further. When
>> the controller is ready, it will generate a power irq which needs to be
>> handled. The thread which initiated the register write should wait for
>> power irq to complete. This will be done through the new sdhc msm write
>> APIs which will check whether the particular write can trigger a power
>> irq and wait for it with a timeout if it is expected.
>> The SDHC core power control IRQ gets triggered when -
>> * There is a state change in power control bit (bit 0)
>> of SDHCI_POWER_CONTROL register.
>> * There is a state change in 1.8V enable bit (bit 3) of
>> SDHCI_HOST_CONTROL2 register.
>> * Bit 1 of SDHCI_SOFTWARE_RESET is set.
>>
>> Also add support APIs which are used by sdhc msm write APIs to check
>> if power irq is expected to be generated and wait for the power irq
>> to come and complete if the irq is expected.
>>
>> This patch requires CONFIG_MMC_SDHCI_IO_ACCESSORS to be enabled.
>>
>> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
>> Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org>
>> ---
>> drivers/mmc/host/sdhci-msm.c | 173 ++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 171 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
>
> [..]
>
>> +/*
>> + * sdhci_msm_check_power_status API should be called when registers writes
>> + * which can toggle sdhci IO bus ON/OFF or change IO lines HIGH/LOW happens.
>> + * To what state the register writes will change the IO lines should be passed
>> + * as the argument req_type. This API will check whether the IO line's state
>> + * is already the expected state and will wait for power irq only if
>> + * power irq is expected to be trigerred based on the current IO line state
>> + * and expected IO line state.
>> + */
>> +static void sdhci_msm_check_power_status(struct sdhci_host *host, u32 req_type)
>> +{
>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
>> + bool done = false;
>> +
>> + pr_debug("%s: %s: request %d curr_pwr_state %x curr_io_level %x\n",
>> + mmc_hostname(host->mmc), __func__, req_type,
>> + msm_host->curr_pwr_state, msm_host->curr_io_level);
>> +
>> + /*
>> + * The IRQ for request type IO High/LOW will be generated when -
>> + * there is a state change in 1.8V enable bit (bit 3) of
>> + * SDHCI_HOST_CONTROL2 register. The reset state of that bit is 0
>> + * which indicates 3.3V IO voltage. So, when MMC core layer tries
>> + * to set it to 3.3V before card detection happens, the
>> + * IRQ doesn't get triggered as there is no state change in this bit.
>> + * The driver already handles this case by changing the IO voltage
>> + * level to high as part of controller power up sequence. Hence, check
>> + * for host->pwr to handle a case where IO voltage high request is
>> + * issued even before controller power up.
>> + */
>> + if ((req_type & REQ_IO_HIGH) && !host->pwr) {
>> + pr_debug("%s: do not wait for power IRQ that never comes, req_type: %d\n",
>> + mmc_hostname(host->mmc), req_type);
>> + return;
>> + }
>> + if ((req_type & msm_host->curr_pwr_state) ||
>> + (req_type & msm_host->curr_io_level))
>> + done = true;
>> + /*
>> + * This is needed here to handle cases where register writes will
>> + * not change the current bus state or io level of the controller.
>> + * In this case, no power irq will be triggerred and we should
>> + * not wait.
>> + */
>> + if (!done) {
>> + if (!wait_event_timeout(msm_host->pwr_irq_wait,
>> + msm_host->pwr_irq_flag,
>> + msecs_to_jiffies(MSM_PWR_IRQ_TIMEOUT_MS)))
>> + __WARN_printf("%s: pwr_irq for req: (%d) timed out\n",
>> + mmc_hostname(host->mmc), req_type);
>
> I am seeing the above error message on a db820c device (apq8096). When i
> unplug the SD card and then plug it back in, there is a 5 sec card
> detection delay and a timeout. Here is a log:
>
> [ 50.253997] mmc0: card 59b4 removed
> [ 50.381874] mmc0: sdhci_msm_check_power_status: request 1
> curr_pwr_state 2 curr_io_level 4 sdhci_host_ctrl2 b
> [ 50.382656] mmc0: sdhci_msm_check_power_status: request 1 done
> [ 50.392493] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 1 curr_io_level 4 sdhci_host_ctrl2 b
> [ 50.398258] mmc0: sdhci_msm_check_power_status: request 4 done
> [ 50.408728] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 1 curr_io_level 4 sdhci_host_ctrl2 8
> [ 50.413865] mmc0: sdhci_msm_check_power_status: request 4 done
> [ 54.966316] mmc0: sdhci_msm_check_power_status: request 2
> curr_pwr_state 1 curr_io_level 4 sdhci_host_ctrl2 8 <-- card is plugged
> [ 54.967756] mmc0: sdhci_msm_check_power_status: request 2 done
> [ 54.976822] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 2 curr_io_level 8 sdhci_host_ctrl2 8
> [ 60.132253] sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for req: (4) timed out
> [ 60.132782] mmc0: sdhci_msm_check_power_status: request 4 done
> [ 60.139888] mmc0: sdhci_msm_check_power_status: request 4
> curr_pwr_state 2 curr_io_level 8 sdhci_host_ctrl2 8
> [ 65.252497] sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for req: (4) timed out
>
> The following patch seem to "fix" it.
>
> -- >8 --
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index b2d875afae5f..ca8ad4edcf80 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -1049,6 +1049,11 @@ static void sdhci_msm_check_power_status(struct
> sdhci_host *host, u32 req_type)
> return;
> }
>
> + if (req_type & REQ_IO_LOW &&
> + msm_host->curr_pwr_state & REQ_BUS_ON &&
> + msm_host->curr_io_level & REQ_IO_HIGH &&
> + !host->pwr)
> + done = true;
> /*
> * The IRQ for request type IO High/LOW will be generated when -
> * there is a state change in 1.8V enable bit (bit 3) of
> -- >8 --
>
> Reverting this patch series or applying the above patch makes the issue
> go away. According to the log, there is no change in the
> sdhci_host_ctrl2 register. What do you think?
>
> Thanks,
> Georgi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH v2 5/8] pinctrl: optionally stop deferring probe at end of initcalls
From: Linus Walleij @ 2018-05-30 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180524175024.19874-6-robh@kernel.org>
On Thu, May 24, 2018 at 7:50 PM, Rob Herring <robh@kernel.org> wrote:
> If the pinctrl node in DT indicates that pin setup is optional and the
> defaults can be used with the 'pinctrl-use-default', then only defer probe
> until initcalls are done. This gives platforms the option to work without
> their pinctrl driver being enabled.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
I trust that you know what you're doing so I guess
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3 4/5] clocksource: add driver for i.MX EPIT timer
From: Vladimir Zapolskiy @ 2018-05-30 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529170436.22711-5-peron.clem@gmail.com>
Hi Cl?ment,
please find some more review comments.
On 05/29/2018 08:04 PM, Cl?ment P?ron wrote:
> From: Colin Didier <colin.didier@devialet.com>
>
> Add driver for NXP's EPIT timer used in i.MX 6 family of SoC.
>
> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> Signed-off-by: Cl?ment Peron <clement.peron@devialet.com>
> ---
> drivers/clocksource/Kconfig | 12 ++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-imx-epit.c | 283 +++++++++++++++++++++++++++
> 3 files changed, 296 insertions(+)
> create mode 100644 drivers/clocksource/timer-imx-epit.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 8e8a09755d10..920a0874f3a4 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -576,6 +576,18 @@ config H8300_TPU
> This enables the clocksource for the H8300 platform with the
> H8S2678 cpu.
>
> +config CLKSRC_IMX_EPIT
> + bool "Clocksource using i.MX EPIT"
> + depends on ARM && CLKDEV_LOOKUP && OF && (ARCH_MXC || COMPILE_TEST)
Here 'depends on ARM' can be removed, because ARCH_MXC implies it.
Also ARCH_MXC implies ARCH_MULTIPLATFORM, which implies USE_OF in turn,
so I would say that the following line is correct, sorry about a previous
comment asking to add an explicit OF dependency:
depends on CLKDEV_LOOKUP && (ARCH_MXC || COMPILE_TEST)
However most of the clocksource drivers follow 'bool "..." if COMPILE_TEST'
pattern, and it might be preferable to maintainers.
> + select TIMER_OF
The driver does not have this dependency.
> + select CLKSRC_MMIO
> + help
> + This enables EPIT support available on some i.MX platforms.
> + Normally you don't have a reason to do so as the EPIT has
> + the same features and uses the same clocks as the GPT.
> + Anyway, on some systems the GPT may be in use for other
> + purposes.
> +
> config CLKSRC_IMX_GPT
> bool "Clocksource using i.MX GPT" if COMPILE_TEST
> depends on ARM && CLKDEV_LOOKUP
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 00caf37e52f9..d9426f69ec69 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_INTEGRATOR_AP_TIMER) += timer-integrator-ap.o
> obj-$(CONFIG_CLKSRC_VERSATILE) += versatile.o
> obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
> obj-$(CONFIG_CLKSRC_TANGO_XTAL) += tango_xtal.o
> +obj-$(CONFIG_CLKSRC_IMX_EPIT) += timer-imx-epit.o
> obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
> obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
> obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
> diff --git a/drivers/clocksource/timer-imx-epit.c b/drivers/clocksource/timer-imx-epit.c
> new file mode 100644
> index 000000000000..87025d5f3a97
> --- /dev/null
> +++ b/drivers/clocksource/timer-imx-epit.c
> @@ -0,0 +1,283 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX EPIT Timer
> + *
> + * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
> + * Copyright (C) 2018 Colin Didier <colin.didier@devialet.com>
> + * Copyright (C) 2018 Cl?ment P?ron <clement.peron@devialet.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clockchips.h>
> +#include <linux/err.h>
The include above can be dropped.
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
The include above can be dropped.
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of.h>
The include above can be dropped.
> +#include <linux/sched_clock.h>
> +#include <linux/slab.h>
> +
> +#define EPITCR 0x00
> +#define EPITSR 0x04
> +#define EPITLR 0x08
> +#define EPITCMPR 0x0c
> +#define EPITCNR 0x10
> +
> +#define EPITCR_EN BIT(0)
> +#define EPITCR_ENMOD BIT(1)
> +#define EPITCR_OCIEN BIT(2)
> +#define EPITCR_RLD BIT(3)
> +#define EPITCR_PRESC(x) (((x) & 0xfff) << 4)
> +#define EPITCR_SWR BIT(16)
> +#define EPITCR_IOVW BIT(17)
> +#define EPITCR_DBGEN BIT(18)
> +#define EPITCR_WAITEN BIT(19)
> +#define EPITCR_RES BIT(20)
> +#define EPITCR_STOPEN BIT(21)
> +#define EPITCR_OM_DISCON (0 << 22)
> +#define EPITCR_OM_TOGGLE (1 << 22)
> +#define EPITCR_OM_CLEAR (2 << 22)
> +#define EPITCR_OM_SET (3 << 22)
> +#define EPITCR_CLKSRC_OFF (0 << 24)
> +#define EPITCR_CLKSRC_PERIPHERAL (1 << 24)
> +#define EPITCR_CLKSRC_REF_HIGH (2 << 24)
> +#define EPITCR_CLKSRC_REF_LOW (3 << 24)
> +
> +#define EPITSR_OCIF BIT(0)
> +
> +struct epit_timer {
> + void __iomem *base;
> + int irq;
> + struct clk *clk_per;
> + struct clock_event_device ced;
> + struct irqaction act;
> +};
> +
> +static void __iomem *sched_clock_reg;
> +
> +static inline struct epit_timer *to_epit_timer(struct clock_event_device *ced)
> +{
> + return container_of(ced, struct epit_timer, ced);
> +}
> +
> +static inline void epit_irq_disable(struct epit_timer *epittm)
> +{
> + u32 val;
> +
> + val = readl_relaxed(epittm->base + EPITCR);
> + writel_relaxed(val & ~EPITCR_OCIEN, epittm->base + EPITCR);
> +}
> +
> +static inline void epit_irq_enable(struct epit_timer *epittm)
> +{
> + u32 val;
> +
> + val = readl_relaxed(epittm->base + EPITCR);
> + writel_relaxed(val | EPITCR_OCIEN, epittm->base + EPITCR);
> +}
> +
> +static void epit_irq_acknowledge(struct epit_timer *epittm)
> +{
> + writel_relaxed(EPITSR_OCIF, epittm->base + EPITSR);
> +}
> +
> +static u64 notrace epit_read_sched_clock(void)
> +{
> + return ~readl_relaxed(sched_clock_reg);
> +}
> +
> +static int __init epit_clocksource_init(struct epit_timer *epittm)
> +{
> + unsigned int c = clk_get_rate(epittm->clk_per);
> +
> + sched_clock_reg = epittm->base + EPITCNR;
> + sched_clock_register(epit_read_sched_clock, 32, c);
> +
> + return clocksource_mmio_init(epittm->base + EPITCNR, "epit", c, 200, 32,
> + clocksource_mmio_readl_down);
> +}
> +
I would suggest to place epit_clocksource_init() function right before
epit_timer_init().
> +static int epit_set_next_event(unsigned long cycles,
> + struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long tcmp;
> +
> + tcmp = readl_relaxed(epittm->base + EPITCNR) - cycles;
> + writel_relaxed(tcmp, epittm->base + EPITCMPR);
> +
> + return 0;
> +}
> +
> +/* Left event sources disabled, no more interrupts appear */
> +static int epit_shutdown(struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long flags;
> +
> + /*
> + * The timer interrupt generation is disabled at least
> + * for enough time to call epit_set_next_event()
> + */
> + local_irq_save(flags);
> +
> + /* Disable interrupt in EPIT module */
> + epit_irq_disable(epittm);
> +
> + /* Clear pending interrupt */
> + epit_irq_acknowledge(epittm);
> +
> + local_irq_restore(flags);
> +
> + return 0;
> +}
> +
> +static int epit_set_oneshot(struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long flags;
> +
> + /*
> + * The timer interrupt generation is disabled at least
> + * for enough time to call epit_set_next_event()
> + */
> + local_irq_save(flags);
> +
> + /* Disable interrupt in EPIT module */
> + epit_irq_disable(epittm);
> +
> + /* Clear pending interrupt, only while switching mode */
> + if (!clockevent_state_oneshot(ced))
> + epit_irq_acknowledge(epittm);
> +
> + /*
> + * Do not put overhead of interrupt enable/disable into
> + * epit_set_next_event(), the core has about 4 minutes
> + * to call epit_set_next_event() or shutdown clock after
> + * mode switching
> + */
> + epit_irq_enable(epittm);
> + local_irq_restore(flags);
> +
> + return 0;
> +}
> +
> +static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
> +{
> + struct clock_event_device *ced = dev_id;
> + struct epit_timer *epittm = to_epit_timer(ced);
> +
> + epit_irq_acknowledge(epittm);
> +
> + ced->event_handler(ced);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int __init epit_clockevent_init(struct epit_timer *epittm)
> +{
> + struct clock_event_device *ced = &epittm->ced;
> + struct irqaction *act = &epittm->act;
> +
> + ced->name = "epit";
> + ced->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_DYNIRQ;
> + ced->set_state_shutdown = epit_shutdown;
> + ced->tick_resume = epit_shutdown;
> + ced->set_state_oneshot = epit_set_oneshot;
> + ced->set_next_event = epit_set_next_event;
> + ced->rating = 200;
> + ced->cpumask = cpumask_of(0);
> + ced->irq = epittm->irq;
> + clockevents_config_and_register(ced, clk_get_rate(epittm->clk_per),
> + 0xff, 0xfffffffe);
Please indent the wrapped line.
> +
> + act->name = "i.MX EPIT Timer Tick",
> + act->flags = IRQF_TIMER | IRQF_IRQPOLL;
> + act->handler = epit_timer_interrupt;
> + act->dev_id = ced;
> +
> + /* Make irqs happen */
> + return setup_irq(epittm->irq, act);
> +}
> +
> +static int __init epit_timer_init(struct device_node *np)
> +{
> + struct epit_timer *epittm;
> + struct clk *clk_ipg;
> + int ret;
> +
> + epittm = kzalloc(sizeof(*epittm), GFP_KERNEL);
> + if (!epittm)
> + return -ENOMEM;
> +
> + epittm->base = of_iomap(np, 0);
> + if (!epittm->base) {
> + ret = -ENXIO;
> + goto out_kfree;
> + }
> +
> + epittm->irq = irq_of_parse_and_map(np, 0);
> + if (!epittm->irq) {
> + ret = -EINVAL;
> + goto out_iounmap;
> + }
> +
> + clk_ipg = of_clk_get_by_name(np, "ipg");
> + if (IS_ERR(clk_ipg)) {
> + pr_err("i.MX EPIT: unable to get clk_ipg\n");
> + ret = PTR_ERR(clk_ipg);
> + goto out_iounmap;
> + }
> +
> + ret = clk_prepare_enable(clk_ipg);
> + if (ret) {
> + pr_err("i.MX EPIT: unable to prepare+enable clk_ipg\n");
> + goto out_clk_ipg_disable;
> + }
> +
> + epittm->clk_per = of_clk_get_by_name(np, "per");
> + if (IS_ERR(epittm->clk_per)) {
> + pr_err("i.MX EPIT: unable to get clk_per\n");
> + ret = PTR_ERR(epittm->clk_per);
> + goto out_clk_ipg_disable;
> + }
> +
> + ret = clk_prepare_enable(epittm->clk_per);
> + if (ret) {
> + pr_err("i.MX EPIT: unable to prepare+enable clk_per\n");
> + goto out_clk_ipg_disable;
> + }
> +
> + /* Initialise to a known state (all timers off, and timing reset) */
> + writel_relaxed(0x0, epittm->base + EPITCR);
> + writel_relaxed(0xffffffff, epittm->base + EPITLR);
> + writel_relaxed(EPITCR_EN | EPITCR_CLKSRC_REF_HIGH | EPITCR_WAITEN,
> + epittm->base + EPITCR);
> +
> + ret = epit_clocksource_init(epittm);
> + if(ret) {
Add a space before left parenthesis.
> + pr_err("i.MX EPIT: failed to init clocksource\n");
> + goto out_clk_per_disable;
> + }
> +
> + ret = epit_clockevent_init(epittm);
> + if(ret) {
Add a space before left parenthesis.
> + pr_err("i.MX EPIT: failed to init clockevent\n");
> + goto out_clk_per_disable;
> + }
> +
> + return 0;
> +
> +out_clk_per_disable:
> + clk_disable_unprepare(epittm->clk_per);
> +out_clk_ipg_disable:
> + clk_disable_unprepare(clk_ipg);
> +out_iounmap:
> + iounmap(epittm->base);
> +out_kfree:
> + kfree(epittm);
> +
> + return ret;
> +}
> +TIMER_OF_DECLARE(mx6q_timer, "fsl,imx6q-epit", epit_timer_init);
>
Here "fsl,imx31-epit" would be way better than "fsl,imx6q-epit", please
fix it in the documentation as well.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Nixiaoming @ 2018-05-30 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-FvWoDbMV2veh8BzW7ihbvaw-cd+rK5x_TLq0UC99FNg@mail.gmail.com>
On 30 May 2018 at 2:07PM Ard Biesheuvel [mailto:ard.biesheuvel at linaro.org] wrote:
>On 30 May 2018 at 07:58, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * nixiaoming <nixiaoming@huawei.com> 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
>....
>>
>> NAK, this is very ugly and the changelog doesn't appear to be true: the build
>> warning does not trigger in the default build, correct?
>>
>
>I don't see how the build warning could trigger at all, given that
>mark_rodata_ro() has external linkage.
>
Unable to set CONFIG_STRICT_KERNEL_RWX=n by make menuconfig ARCH=x86_64
the build warning does not trigger in the default build,
but it should be more appropriate to add CONFIG control to the code.
^ permalink raw reply
* [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Marcel Holtmann @ 2018-05-30 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1527175805.4607.103.camel@mtkswgap22>
Hi Sean,
>>>>>>
>>>>>> [ ... ]
>
> [ ... ]
>
>>> I post it as plain text as below
>>>
>>>
>>> Bluetooth monitor ver 5.37
>>> = Note: Linux version 4.16.0-rc1+ (aarch64) 0.641494
>>> = Note: Bluetooth subsystem version 2.22 0.641502
>>> = New Index: 00:00:46:76:22:01 (BR/EDR,UART,hci0) [hci0] 0.641505
>>> * Unknown packet (code 14 len 30) 0.641509
>>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
>>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
>>> * Unknown packet (code 14 len 30) 0.641592
>>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
>>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
>>> * Unknown packet (code 16 len 7) [hci0] 6.536771
>>> 01 00 00 00 05 00 01 .......
>>> = Open Index: 00:00:46:76:22:01 [hci0] 6.717019
>>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
>>
>> can you try with the latest BlueZ 5.49 or git version. Seems it actually stumbles over the extra packet here. Fun fact is that I can not get a backtrace to pin-point the issue in btmon and why it crashes.
>>
>
> I had less experience updating user land BlueZ, but I can try it as possible and see whether Unknown packets still are present at newest version BlueZ. Hopefully I don't misunderstand your point here.
please use the latest btmon and check if it can read your trace.
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.744105
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.745109
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.746104
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.747097
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.748090
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.749078
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.750070
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.751061
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.752054
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.753046
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.754038
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.755031
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.756025
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.757013
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758006
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758999
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.759991
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.760983
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.761975
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.762963
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.763956
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.764948
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.765941
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.766933
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.767926
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.768919
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.769914
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.770909
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.771908
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.772904
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.773898
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.774892
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.775890
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.776882
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.777877
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.778871
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.779869
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.780864
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.781858
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.782852
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.783850
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.784845
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.785839
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.786833
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.787831
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.788826
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.789820
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.790814
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.791813
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.792809
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.793803
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.794798
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.795797
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.796791
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.797786
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.798779
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.799778
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.800774
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.801769
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.802763
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.803761
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.804755
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.805749
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.806743
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.807741
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.808737
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.809731
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.810725
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.811725
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.812719
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.813714
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
>>> 02 01 01 00 00 .....
>>
>> Why do I see only HCI events here? Is this event conveying any useful information. It is kinda complicated that this is 0xe4 event code which is actually reserved for future use by the Bluetooth SIG. Are there any accompanying HCI commands for this and they just not make it into btmon?
>>
>
> I have made all vendor HCI commands go through BlueZ core in v2 patch.
>
> And for these HCI events, they are all corresponding to vendor ACL data, applied only to firmware setup packets, but they're not being sent via BlueZ core, so they are not being logged in btmon.
>
> As for its event, where heading 0xe4 refers to a vendor event and is used on notification of that either vendor ACL data or vendor HCI command have been done.
I would prefer if everything goes via the Bluetooth core since then we have it all properly scheduled. Sending things down the ACL data path however if kinda funky. Does your hardware accept sending command both via ACL data and as HCI command? If so, then I would prefer sending them as HCI commands since the speed improvement you think you are getting is neglectable on Linux (I have been down that path). This seems to be a pure optimization when Windows is driving the device.
And the vendor event 0xe4 is really only received during firmware download? It is not ever received during normal operation?
>
>>
>>
>>> < HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
>>> 01 07 01 00 04 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
>>> 02 07 01 00 00 .....
>>> < HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 8.845071
>>> 01 06 02 00 00 01 ......
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 8.923456
>>> 02 06 01 00 00 .....
>>
>> Here it looks like you have 0x006f opcode with first octet 0x01 for command and then vendor event 0xe4 with first octet 0x02 for event. I assume the second octet is then the vendor command code for these.
>>
>
> Yes, you're right.
>
>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 10.861118
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.865763
>>> Reset (0x03|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: Read Local Supported Fe.. (0x04|0x0003) plen 0 [hci0] 10.865805
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.865965
>>> Read Local Supported Features (0x04|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x7b 0x87
>>> 3 slot packets
>>> 5 slot packets
>>> Encryption
>>> Slot offset
>>> Timing accuracy
>>> Role switch
>>> Sniff mode
>>> Power control requests
>>> Channel quality driven data rate (CQDDR)
>>> SCO link
>>> HV2 packets
>>> HV3 packets
>>> CVSD synchronous data
>>> Power control
>>> Transparent synchronous data
>>> Broadcast Encryption
>>> Enhanced Data Rate ACL 2 Mbps mode
>>> Enhanced Data Rate ACL 3 Mbps mode
>>> Enhanced inquiry scan
>>> Interlaced inquiry scan
>>> Interlaced page scan
>>> RSSI with inquiry results
>>> Extended SCO link (EV3 packets)
>>> EV4 packets
>>> EV5 packets
>>> AFH capable slave
>>> AFH classification slave
>>> LE Supported (Controller)
>>> 3-slot Enhanced Data Rate ACL packets
>>> 5-slot Enhanced Data Rate ACL packets
>>> Sniff subrating
>>> Pause encryption
>>> AFH capable master
>>> AFH classification master
>>> Enhanced Data Rate eSCO 2 Mbps mode
>>> Enhanced Data Rate eSCO 3 Mbps mode
>>> 3-slot Enhanced Data Rate eSCO packets
>>> Extended Inquiry Response
>>> Simultaneous LE and BR/EDR (Controller)
>>> Secure Simple Pairing
>>> Encapsulated PDU
>>> Erroneous Data Reporting
>>> Non-flushable Packet Boundary Flag
>>> Link Supervision Timeout Changed Event
>>> Inquiry TX Power Level
>>> Enhanced Power Control
>>> Extended features
>>> < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
>>>> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
>>> 29 19 09 17 20 48 07 11 00 )... H?
>>
>> Is this meant to happen here?
>>
>
> If event received is not expected as the specification defines, I think it's probably incorrect.
>
> But it requires more discussion with firmware people to make it clearer.
Please check and let them decode what this event means.
>
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
>>> Read Local Version Information (0x04|0x0001) ncmd 1
>>> Status: Success (0x00)
>>> HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
>>> LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
>>> Manufacturer: MediaTek, Inc. (70)
>>> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
>>>> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
>>> Read BD ADDR (0x04|0x0009) ncmd 1
>>> Status: Success (0x00)
>>> Address: 00:00:46:76:22:01 (OLIVETTI NORTH AMERICA)
>>> < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 [hci0] 10.866609
>>>> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.866754
>>> Read Buffer Size (0x04|0x0005) ncmd 1
>>> Status: Success (0x00)
>>> ACL MTU: 1021 ACL max packet: 8
>>> SCO MTU: 184 SCO max packet: 1
>>> < HCI Command: Read Class of Device (0x03|0x0023) plen 0 [hci0] 10.866775
>>>> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.866920
>>> Read Class of Device (0x03|0x0023) ncmd 1
>>> Status: Success (0x00)
>>> Class: 0x001f00
>>> Major class: Uncategorized, specific device code not specified
>>> Minor class: 0x00
>>> < HCI Command: Read Local Name (0x03|0x0014) plen 0 [hci0] 10.866939
>>>> HCI Event: Command Complete (0x0e) plen 252 [hci0] 10.867256
>>> Read Local Name (0x03|0x0014) ncmd 1
>>> Status: Success (0x00)
>>> Name: MTK MT7622 #1
>>> < HCI Command: Read Voice Setting (0x03|0x0025) plen 0 [hci0] 10.867308
>>>> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.867447
>>> Read Voice Setting (0x03|0x0025) ncmd 1
>>> Status: Success (0x00)
>>> Setting: 0x0060
>>> Input Coding: Linear
>>> Input Data Format: 2's complement
>>> Input Sample Size: 16-bit
>>> # of bits padding at MSB: 0
>>> Air Coding Format: CVSD
>>> < HCI Command: Read Number of Supporte.. (0x03|0x0038) plen 0 [hci0] 10.867474
>>>> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.867611
>>> Read Number of Supported IAC (0x03|0x0038) ncmd 1
>>> Status: Success (0x00)
>>> Number of IAC: 4
>>> < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 [hci0] 10.867678
>>>> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.867865
>>> Read Current IAC LAP (0x03|0x0039) ncmd 1
>>> Status: Success (0x00)
>>> Number of IAC: 1
>>> Access code: 0x9e8b33 (General Inquiry)
>>> < HCI Command: Set Event Filter (0x03|0x0005) plen 1 [hci0] 10.867890
>>> Type: Clear All Filters (0x00)
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868033
>>> Set Event Filter (0x03|0x0005) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: Write Connection Accept.. (0x03|0x0016) plen 2 [hci0] 10.868054
>>> Timeout: 20000.000 msec (0x7d00)
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868235
>>> Write Connection Accept Timeout (0x03|0x0016) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: LE Read Buffer Size (0x08|0x0002) plen 0 [hci0] 10.868262
>>>> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.868392
>>> LE Read Buffer Size (0x08|0x0002) ncmd 1
>>> Status: Success (0x00)
>>> Data packet length: 251
>>> Num data packets: 8
>>> < HCI Command: LE Read Local Supported.. (0x08|0x0003) plen 0 [hci0] 10.868413
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868587
>>> LE Read Local Supported Features (0x08|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> Features: 0xfd 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>>> LE Encryption
>>> Extended Reject Indication
>>> Slave-initiated Features Exchange
>>> LE Ping
>>> LE Data Packet Length Extension
>>> LL Privacy
>>> Extended Scanner Filter Policies
>>> < HCI Command: LE Read Supported States (0x08|0x001c) plen 0 [hci0] 10.868646
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868787
>>> LE Read Supported States (0x08|0x001c) ncmd 1
>>> Status: Success (0x00)
>>> States: 0x000000001fffffff
>>> Non-connectable Advertising State
>>> Scannable Advertising State
>>> Connectable Advertising State
>>> High Duty Cycle Directed Advertising State
>>> Passive Scanning State
>>> Active Scanning State
>>> Initiating State
>>> and Connection State (Master Role)
>>> Connection State (Slave Role)
>>> Non-connectable Advertising State
>>> and Passive Scanning State
>>> Scannable Advertising State
>>> and Passive Scanning State
>>> Connectable Advertising State
>>> and Passive Scanning State
>>> High Duty Cycle Directed Advertising State
>>> and Passive Scanning State
>>> Non-connectable Advertising State
>>> and Active Scanning State
>>> Scannable Advertising State
>>> and Active Scanning State
>>> Connectable Advertising State
>>> and Active Scanning State
>>> High Duty Cycle Directed Advertising State
>>> and Active Scanning State
>>> Non-connectable Advertising State
>>> and Initiating State
>>> Scannable Advertising State
>>> and Initiating State
>>> Non-connectable Advertising State
>>> and Connection State (Master Role)
>>> Scannable Advertising State
>>> and Connection State (Master Role)
>>> Non-connectable Advertising State
>>> and Connection State (Slave Role)
>>> Scannable Advertising State
>>> and Connection State (Slave Role)
>>> Passive Scanning State
>>> and Initiating State
>>> Active Scanning State
>>> and Initiating State
>>> Passive Scanning State
>>> and Connection State (Master Role)
>>> Active Scanning State
>>> and Connection State (Master Role)
>>> Passive Scanning State
>>> and Connection State (Slave Role)
>>> Active Scanning State
>>> and Connection State (Slave Role)
>>> Initiating State
>>> and Connection State (Master Role)
>>> and Master Role & Master Role
>>> < HCI Command: Read Local Supported Co.. (0x04|0x0002) plen 0 [hci0] 10.868807
>>>> HCI Event: Command Complete (0x0e) plen 68 [hci0] 10.868985
>>> Read Local Supported Commands (0x04|0x0002) ncmd 1
>>> Status: Success (0x00)
>>> Commands: 176 entries
>>> Inquiry (Octet 0 - Bit 0)
>>> Inquiry Cancel (Octet 0 - Bit 1)
>>> Periodic Inquiry Mode (Octet 0 - Bit 2)
>>> Exit Periodic Inquiry Mode (Octet 0 - Bit 3)
>>> Create Connection (Octet 0 - Bit 4)
>>> Disconnect (Octet 0 - Bit 5)
>>> Add SCO Connection (Octet 0 - Bit 6)
>>> Create Connection Cancel (Octet 0 - Bit 7)
>>> Accept Connection Request (Octet 1 - Bit 0)
>>> Reject Connection Request (Octet 1 - Bit 1)
>>> Link Key Request Reply (Octet 1 - Bit 2)
>>> Link Key Request Negative Reply (Octet 1 - Bit 3)
>>> PIN Code Request Reply (Octet 1 - Bit 4)
>>> PIN Code Request Negative Reply (Octet 1 - Bit 5)
>>> Change Connection Packet Type (Octet 1 - Bit 6)
>>> Authentication Requested (Octet 1 - Bit 7)
>>> Set Connection Encryption (Octet 2 - Bit 0)
>>> Change Connection Link Key (Octet 2 - Bit 1)
>>> Master Link Key (Octet 2 - Bit 2)
>>> Remote Name Request (Octet 2 - Bit 3)
>>> Remote Name Request Cancel (Octet 2 - Bit 4)
>>> Read Remote Supported Features (Octet 2 - Bit 5)
>>> Read Remote Extended Features (Octet 2 - Bit 6)
>>> Read Remote Version Information (Octet 2 - Bit 7)
>>> Read Clock Offset (Octet 3 - Bit 0)
>>> Read LMP Handle (Octet 3 - Bit 1)
>>> Sniff Mode (Octet 4 - Bit 2)
>>> Exit Sniff Mode (Octet 4 - Bit 3)
>>> QoS Setup (Octet 4 - Bit 6)
>>> Role Discovery (Octet 4 - Bit 7)
>>> Switch Role (Octet 5 - Bit 0)
>>> Read Link Policy Settings (Octet 5 - Bit 1)
>>> Write Link Policy Settings (Octet 5 - Bit 2)
>>> Read Default Link Policy Settings (Octet 5 - Bit 3)
>>> Write Default Link Policy Settings (Octet 5 - Bit 4)
>>> Flow Specification (Octet 5 - Bit 5)
>>> Set Event Mask (Octet 5 - Bit 6)
>>> Reset (Octet 5 - Bit 7)
>>> Set Event Filter (Octet 6 - Bit 0)
>>> Flush (Octet 6 - Bit 1)
>>> Read PIN Type (Octet 6 - Bit 2)
>>> Write PIN Type (Octet 6 - Bit 3)
>>> Create New Unit Key (Octet 6 - Bit 4)
>>> Read Stored Link Key (Octet 6 - Bit 5)
>>> Write Stored Link Key (Octet 6 - Bit 6)
>>> Delete Stored Link Key (Octet 6 - Bit 7)
>>> Write Local Name (Octet 7 - Bit 0)
>>> Read Local Name (Octet 7 - Bit 1)
>>> Read Connection Accept Timeout (Octet 7 - Bit 2)
>>> Write Connection Accept Timeout (Octet 7 - Bit 3)
>>> Read Page Timeout (Octet 7 - Bit 4)
>>> Write Page Timeout (Octet 7 - Bit 5)
>>> Read Scan Enable (Octet 7 - Bit 6)
>>> Write Scan Enable (Octet 7 - Bit 7)
>>> Read Page Scan Activity (Octet 8 - Bit 0)
>>> Write Page Scan Activity (Octet 8 - Bit 1)
>>> Read Inquiry Scan Activity (Octet 8 - Bit 2)
>>> Write Inquiry Scan Activity (Octet 8 - Bit 3)
>>> Read Authentication Enable (Octet 8 - Bit 4)
>>> Write Authentication Enable (Octet 8 - Bit 5)
>>> Read Encryption Mode (Octet 8 - Bit 6)
>>> Write Encryption Mode (Octet 8 - Bit 7)
>>> Read Class of Device (Octet 9 - Bit 0)
>>> Write Class of Device (Octet 9 - Bit 1)
>>> Read Voice Setting (Octet 9 - Bit 2)
>>> Write Voice Setting (Octet 9 - Bit 3)
>>> Read Automatic Flush Timeout (Octet 9 - Bit 4)
>>> Write Automatic Flush Timeout (Octet 9 - Bit 5)
>>> Read Num Broadcast Retransmissions (Octet 9 - Bit 6)
>>> Write Num Broadcast Retransmissions (Octet 9 - Bit 7)
>>> Read Transmit Power Level (Octet 10 - Bit 2)
>>> Read Sync Flow Control Enable (Octet 10 - Bit 3)
>>> Write Sync Flow Control Enable (Octet 10 - Bit 4)
>>> Set Controller To Host Flow Control (Octet 10 - Bit 5)
>>> Host Buffer Size (Octet 10 - Bit 6)
>>> Host Number of Completed Packets (Octet 10 - Bit 7)
>>> Read Link Supervision Timeout (Octet 11 - Bit 0)
>>> Write Link Supervision Timeout (Octet 11 - Bit 1)
>>> Read Number of Supported IAC (Octet 11 - Bit 2)
>>> Read Current IAC LAP (Octet 11 - Bit 3)
>>> Write Current IAC LAP (Octet 11 - Bit 4)
>>> Read Page Scan Mode (Octet 11 - Bit 7)
>>> Write Page Scan Mode (Octet 12 - Bit 0)
>>> Set AFH Host Channel Classification (Octet 12 - Bit 1)
>>> Read Inquiry Scan Type (Octet 12 - Bit 4)
>>> Write Inquiry Scan Type (Octet 12 - Bit 5)
>>> Read Inquiry Mode (Octet 12 - Bit 6)
>>> Write Inquiry Mode (Octet 12 - Bit 7)
>>> Read Page Scan Type (Octet 13 - Bit 0)
>>> Write Page Scan Type (Octet 13 - Bit 1)
>>> Read AFH Channel Assessment Mode (Octet 13 - Bit 2)
>>> Write AFH Channel Assessment Mode (Octet 13 - Bit 3)
>>> Read Local Version Information (Octet 14 - Bit 3)
>>> Read Local Supported Features (Octet 14 - Bit 5)
>>> Read Local Extended Features (Octet 14 - Bit 6)
>>> Read Buffer Size (Octet 14 - Bit 7)
>>> Read Country Code (Octet 15 - Bit 0)
>>> Read BD ADDR (Octet 15 - Bit 1)
>>> Read Failed Contact Counter (Octet 15 - Bit 2)
>>> Reset Failed Contact Counter (Octet 15 - Bit 3)
>>> Read Link Quality (Octet 15 - Bit 4)
>>> Read RSSI (Octet 15 - Bit 5)
>>> Read AFH Channel Map (Octet 15 - Bit 6)
>>> Read Clock (Octet 15 - Bit 7)
>>> Read Loopback Mode (Octet 16 - Bit 0)
>>> Write Loopback Mode (Octet 16 - Bit 1)
>>> Enable Device Under Test Mode (Octet 16 - Bit 2)
>>> Setup Synchronous Connection (Octet 16 - Bit 3)
>>> Accept Synchronous Connection Request (Octet 16 - Bit 4)
>>> Reject Synchronous Connection Request (Octet 16 - Bit 5)
>>> Read Extended Inquiry Response (Octet 17 - Bit 0)
>>> Write Extended Inquiry Response (Octet 17 - Bit 1)
>>> Refresh Encryption Key (Octet 17 - Bit 2)
>>> Sniff Subrating (Octet 17 - Bit 4)
>>> Read Simple Pairing Mode (Octet 17 - Bit 5)
>>> Write Simple Pairing Mode (Octet 17 - Bit 6)
>>> Read Local OOB Data (Octet 17 - Bit 7)
>>> Read Inquiry Response TX Power Level (Octet 18 - Bit 0)
>>> Write Inquiry Transmit Power Level (Octet 18 - Bit 1)
>>> Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
>>> Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
>>> IO Capability Request Reply (Octet 18 - Bit 7)
>>> User Confirmation Request Reply (Octet 19 - Bit 0)
>>> User Confirmation Request Neg Reply (Octet 19 - Bit 1)
>>> User Passkey Request Reply (Octet 19 - Bit 2)
>>> User Passkey Request Negative Reply (Octet 19 - Bit 3)
>>> Remote OOB Data Request Reply (Octet 19 - Bit 4)
>>> Write Simple Pairing Debug Mode (Octet 19 - Bit 5)
>>> Enhanced Flush (Octet 19 - Bit 6)
>>> Remote OOB Data Request Neg Reply (Octet 19 - Bit 7)
>>> Send Keypress Notification (Octet 20 - Bit 2)
>>> IO Capability Request Negative Reply (Octet 20 - Bit 3)
>>> Read Encryption Key Size (Octet 20 - Bit 4)
>>> Set Event Mask Page 2 (Octet 22 - Bit 2)
>>> Read Enhanced Transmit Power Level (Octet 24 - Bit 0)
>>> Enhanced Setup Synchronous Connection (Octet 29 - Bit 3)
>>> Enhanced Accept Synchronous Connection Request (Octet 29 - Bit 4)
>>> Read Local Supported Codecs (Octet 29 - Bit 5)
>>> Set Triggered Clock Capture (Octet 30 - Bit 5)
>>> Truncated Page (Octet 30 - Bit 6)
>>> Truncated Page Cancel (Octet 30 - Bit 7)
>>> Set Connectionless Slave Broadcast (Octet 31 - Bit 0)
>>> Start Synchronization Train (Octet 31 - Bit 2)
>>> Set Reserved LT_ADDR (Octet 31 - Bit 4)
>>> Delete Reserved LT_ADDR (Octet 31 - Bit 5)
>>> Set Connectionless Slave Broadcast Data (Octet 31 - Bit 6)
>>> Read Synchronization Train Parameters (Octet 31 - Bit 7)
>>> Write Synchronization Train Parameters (Octet 32 - Bit 0)
>>> Remote OOB Extended Data Request Reply (Octet 32 - Bit 1)
>>> Read Authenticated Payload Timeout (Octet 32 - Bit 4)
>>> Write Authenticated Payload Timeout (Octet 32 - Bit 5)
>>> Read Local OOB Extended Data (Octet 32 - Bit 6)
>>> Write Secure Connections Test Mode (Octet 32 - Bit 7)
>>> Read Extended Page Timeout (Octet 33 - Bit 0)
>>> Write Extended Page Timeout (Octet 33 - Bit 1)
>>> Read Extended Inquiry Length (Octet 33 - Bit 2)
>>> Write Extended Inquiry Length (Octet 33 - Bit 3)
>>> LE Set Data Length (Octet 33 - Bit 6)
>>> LE Read Suggested Default Data Length (Octet 33 - Bit 7)
>>> LE Write Suggested Default Data Length (Octet 34 - Bit 0)
>>> LE Read Local P-256 Public Key (Octet 34 - Bit 1)
>>> LE Generate DHKey (Octet 34 - Bit 2)
>>> LE Add Device To Resolving List (Octet 34 - Bit 3)
>>> LE Remove Device From Resolving List (Octet 34 - Bit 4)
>>> LE Clear Resolving List (Octet 34 - Bit 5)
>>> LE Read Resolving List Size (Octet 34 - Bit 6)
>>> LE Read Peer Resolvable Address (Octet 34 - Bit 7)
>>> LE Read Local Resolvable Address (Octet 35 - Bit 0)
>>> LE Set Address Resolution Enable (Octet 35 - Bit 1)
>>> LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
>>> LE Read Maximum Data Length (Octet 35 - Bit 3)
>>> Octet 35 - Bit 4
>>> Octet 35 - Bit 5
>>> Octet 35 - Bit 6
>>> Octet 35 - Bit 7
>>> Octet 36 - Bit 0
>>
>> So you support the PHY commands, but do not indicate support LE 2M or LE Coded? Also these are Bluetooth 5.0 commands.
>>
>
> To be honest. When I ported the device into Bluez core, a unexpected event for LE read local feature would cause a fail at Bluez core, so I made a hack on Bluez core
>
> to allow that I can keeping bring up the device without be blocked by the issue most probably from firmware.
>
> Below code snippet is the only thing I added to avoid a fail at Bluez core to bring up the device.
>
> @@ -927,6 +927,8 @@ static void hci_cc_le_read_local_features(struct hci_dev *hdev,
> return;
>
> memcpy(hdev->le_features, rp->features, 8);
> + hdev->le_features[0] = 0;
> + hdev->le_features[1] = 0;
> }
Send me the trace where you didn?t clear the feature bits and I check what is going on. I doubt that we have a bug, but maybe some of the commands are optional and we should add an appropriate check. Or you guys need to fix your firmware. A new btmon should decode all bits properly.
Regards
Marcel
^ permalink raw reply
* [PATCH 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver
From: Vishal Sagar @ 2018-05-30 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5bf470c0-8737-273e-c138-58a05d7d9a30@infradead.org>
Hi Randy,
Thanks for reviewing.
> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap at infradead.org]
> Sent: Wednesday, May 30, 2018 1:29 AM
> To: Vishal Sagar <vishal.sagar@xilinx.com>; Hyun Kwon <hyunk@xilinx.com>;
> laurent.pinchart at ideasonboard.com; michal.simek at xilinx.com; linux-
> media at vger.kernel.org; devicetree at vger.kernel.org
> Cc: sakari.ailus at linux.intel.com; hans.verkuil at cisco.com;
> mchehab at kernel.org; robh+dt at kernel.org; mark.rutland at arm.com; Dinesh
> Kumar <dineshk@xilinx.com>; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
> driver
>
> On 05/29/2018 11:54 AM, Vishal Sagar wrote:
> >
> > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > ---
> > drivers/media/platform/xilinx/Kconfig | 12 +
> > drivers/media/platform/xilinx/Makefile | 1 +
> > drivers/media/platform/xilinx/xilinx-csi2rxss.c | 1751
> +++++++++++++++++++++++
> > include/uapi/linux/xilinx-csi2rxss.h | 25 +
> > include/uapi/linux/xilinx-v4l2-controls.h | 14 +
> > 5 files changed, 1803 insertions(+)
> > create mode 100644 drivers/media/platform/xilinx/xilinx-csi2rxss.c
> > create mode 100644 include/uapi/linux/xilinx-csi2rxss.h
> >
> > diff --git a/drivers/media/platform/xilinx/Kconfig
> b/drivers/media/platform/xilinx/Kconfig
> > index a5d21b7..06d5944 100644
> > --- a/drivers/media/platform/xilinx/Kconfig
> > +++ b/drivers/media/platform/xilinx/Kconfig
> > @@ -8,6 +8,18 @@ config VIDEO_XILINX
> >
> > if VIDEO_XILINX
> >
> > +config VIDEO_XILINX_CSI2RXSS
> > + tristate "Xilinx CSI2 Rx Subsystem"
> > + depends on VIDEO_XILINX
> > + help
> > + Driver for Xilinx MIPI CSI2 Rx Subsystem. This is a V4L sub-device
> > + based driver that takes input from CSI2 Tx source and converts
> > + it into an AXI4-Stream. It has a DPHY (whose register interface
> > + can be enabled, an optional I2C controller and an optional Video
>
> can be enabled),
>
Noted. I will update in next revision of patch.
> > + Format Bridge which converts the AXI4-Stream data to Xilinx Video
> > + Bus formats based on UG934. The driver is used to set the number
> > + of active lanes and get short packet data.
> > +
> > config VIDEO_XILINX_TPG
> > tristate "Xilinx Video Test Pattern Generator"
> > depends on VIDEO_XILINX
>
>
>
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any attachments.
> Delete this email message and any attachments immediately.
>
> :(
>
Sorry about that.
I will work with IT on getting this removed before sending v2 for the patches.
-- Vishal
> --
> ~Randy
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: Fix hwrng register address
From: Joel Stanley @ 2018-05-30 6:17 UTC (permalink / raw)
To: linux-arm-kernel
The register address should be the full address of the rng, not the
offset from the start of the SCU.
Fixes: 5daa8212c08e ("ARM: dts: aspeed: Describe random number device")
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
Hi ARM maintainers, this was found when testing next-20180529 after the
merge of the aspeed 4.18 pull request. Can you please apply this one to
your -next tree?
I'll also send a PR with some defconfig updates so the rng driver is
enabled by default.
---
arch/arm/boot/dts/aspeed-g4.dtsi | 4 ++--
arch/arm/boot/dts/aspeed-g5.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 5e947ed496c2..75df1573380e 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -145,9 +145,9 @@
};
- rng: hwrng at 78 {
+ rng: hwrng at 1e6e2078 {
compatible = "timeriomem_rng";
- reg = <0x78 0x4>;
+ reg = <0x1e6e2078 0x4>;
period = <1>;
quality = <100>;
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 24eec00c4a95..17f2714d18a7 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -189,9 +189,9 @@
};
};
- rng: hwrng at 78 {
+ rng: hwrng at 1e6e2078 {
compatible = "timeriomem_rng";
- reg = <0x78 0x4>;
+ reg = <0x1e6e2078 0x4>;
period = <1>;
quality = <100>;
};
--
2.17.0
^ permalink raw reply related
* [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Ard Biesheuvel @ 2018-05-30 6:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530055815.GB6463@gmail.com>
On 30 May 2018 at 07:58, Ingo Molnar <mingo@kernel.org> wrote:
>
> * nixiaoming <nixiaoming@huawei.com> 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
>>
>> Signed-off-by: nixiaoming <nixiaoming@huawei.com>
>> ---
>> arch/x86/mm/init_32.c | 2 ++
>> arch/x86/mm/init_64.c | 2 ++
>> 2 files changed, 4 insertions(+)
>>
>> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
>> index c893c6a..121c567 100644
>> --- a/arch/x86/mm/init_32.c
>> +++ b/arch/x86/mm/init_32.c
>> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
>> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
>> }
>>
>> +#ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void)
>> {
>> unsigned long start = PFN_ALIGN(_text);
>> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
>> if (__supported_pte_mask & _PAGE_NX)
>> debug_checkwx();
>> }
>> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
>> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
>> index 0a40060..1b7a1a7 100644
>> --- a/arch/x86/mm/init_64.c
>> +++ b/arch/x86/mm/init_64.c
>> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
>> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
>> }
>>
>> +#ifdef CONFIG_STRICT_KERNEL_RWX
>> void mark_rodata_ro(void)
>> {
>> unsigned long start = PFN_ALIGN(_text);
>> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
>> */
>> pti_clone_kernel_text();
>> }
>> +#endif
>
> NAK, this is very ugly and the changelog doesn't appear to be true: the build
> warning does not trigger in the default build, correct?
>
I don't see how the build warning could trigger at all, given that
mark_rodata_ro() has external linkage.
^ permalink raw reply
* [PATCH 2/3] x86:add missing CONFIG_STRICT_KERNEL_RWX for mark_rodata_ro
From: Ingo Molnar @ 2018-05-30 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180529133622.26982-1-nixiaoming@huawei.com>
* nixiaoming <nixiaoming@huawei.com> 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
>
> Signed-off-by: nixiaoming <nixiaoming@huawei.com>
> ---
> arch/x86/mm/init_32.c | 2 ++
> arch/x86/mm/init_64.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
> index c893c6a..121c567 100644
> --- a/arch/x86/mm/init_32.c
> +++ b/arch/x86/mm/init_32.c
> @@ -920,6 +920,7 @@ static void mark_nxdata_nx(void)
> set_pages_nx(virt_to_page(start), size >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -957,3 +958,4 @@ void mark_rodata_ro(void)
> if (__supported_pte_mask & _PAGE_NX)
> debug_checkwx();
> }
> +#endif /*end of CONFIG_STRICT_KERNEL_RWX*/
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 0a40060..1b7a1a7 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1245,6 +1245,7 @@ void set_kernel_text_ro(void)
> set_memory_ro(start, (end - start) >> PAGE_SHIFT);
> }
>
> +#ifdef CONFIG_STRICT_KERNEL_RWX
> void mark_rodata_ro(void)
> {
> unsigned long start = PFN_ALIGN(_text);
> @@ -1298,6 +1299,7 @@ void mark_rodata_ro(void)
> */
> pti_clone_kernel_text();
> }
> +#endif
NAK, this is very ugly and the changelog doesn't appear to be true: the build
warning does not trigger in the default build, correct?
Thanks,
Ingo
^ permalink raw reply
* [reset-control] How to initialize hardware state with the shared reset line?
From: Masahiro Yamada @ 2018-05-30 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCBAoRebScz+DTSKSgiU5DjeSHS1F3=2vt8KM-yCv+2A8g@mail.gmail.com>
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
<martin.blumenstingl@googlemail.com>:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> <yamada.masahiro@socionext.com> wrote:
>>> > Hi.
>>> >
>>> >
>>> > 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl
>>> > <martin.blumenstingl@googlemail.com>:
>>> > > Hi,
>>> > >
>>> > > On Thu, May 10, 2018 at 11:16 AM, Masahiro Yamada
>>> > > <yamada.masahiro@socionext.com> wrote:
>>> > > [snip]
>>> > > > I may be missing something, but
>>> > > > one solution might be reset hogging on the
>>> > > > reset provider side. This allows us to describe
>>> > > > the initial state of reset lines in the reset controller.
>>> > > >
>>> > > > The idea for "reset-hog" is similar to:
>>> > > > - "gpio-hog" defined in
>>> > > > Documentation/devicetree/bindings/gpio/gpio.txt
>>> > > > - "assigned-clocks" defined in
>>> > > > Documetation/devicetree/bindings/clock/clock-bindings.txt
>>> > > >
>>> > > >
>>> > > >
>>> > > > For example,
>>> > > >
>>> > > > reset-controller {
>>> > > > ....
>>> > > >
>>> > > > line_a {
>>> > > > reset-hog;
>>> > > > resets = <1>;
>>> > > > reset-assert;
>>> > > > };
>>> > > > }
>>> > > >
>>> > > >
>>> > > > When the reset controller is registered,
>>> > > > the reset ID '1' is asserted.
>>> > > >
>>> > > >
>>> > > > So, all reset consumers that share the reset line '1'
>>> > > > will start from the asserted state
>>> > > > (i.e. defined state machine state).
>>> > >
>>> > > I wonder if a "reset hog" can be board specific:
>>> > > - GPIO hogs are definitely board specific (meson-gxbb-odroidc2.dts for
>>> > > example uses it to take the USB hub out of reset)
>>> > > - assigned-clock-parents (and the like) can also be board specific (I
>>> > > made up a use-case since I don't know of any actual examples: board A
>>> > > uses an external XTAL while board B uses some other internal
>>> > > clock-source because it doesn't have an external XTAL)
>>> > >
>>> > > however, can reset lines be board specific? or in other words: do we
>>> > > need to describe them in device-tree?
>>> >
>>> > Indeed.
>>> >
>>> > I did not come up with board-specific cases.
>>> >
>>> > The problem we are discussing is SoC-specific,
>>> > and reset-controller drivers are definitely SoC-specific.
>>> >
>>> > So, I think the initial state can be coded in drivers instead of DT.
>>>
>>> OK, let's also hear Philipp's (reset framework maintainer) opinion on this
>>
>> I'd like to know if there are other SoC families besides Amlogic Meson
>> that potentially could have this problem and about how many of the
>> resets that are documented in include/dt-bindings/reset/amlogic,meson*
>> we are actually talking. Are all of those initially deasserted and none
>> of the connected peripherals have power-on reset mechanisms?
> I cannot speak for other SoC families besides Amlogic
> Meson8/Meson8b/Meson8m2 and GX (disclaimer: I am a community
> contributor, I don't have access to Amlogic's internal datasheets - my
> knowledge is based on their public datasheets, their GPL kernel/u-boot
> sources and trial and error)
>
> it seems that at least "some" (but I don't know the exact number)
> resets are de-asserted by the bootloader
> Amlogic's u-boot for example also enables all gate clocks by default
>
> I CC'ed the Amlogic mailing list because I'm not sure if everyone
> working on that SoC family is watching the linux-arm-kernel mailing
> list
>
>>> > > we could extend struct reset_controller_dev (= reset controller
>>> > > driver) if they are not board specific:
>>> > > - either assert all reset lines by default except if they are listed
>>> > > in a new field (may break backwards compatibility, requires testing of
>>> > > all reset controller drivers)
>>> >
>>> > This is quite simple, but I am afraid there are some cases where the forcible
>>> > reset-assert is not preferred.
>>> >
>>> > For example, the earlycon. When we use earlycon, we would expect it has been
>>> > initialized by a boot-loader, or something.
>>> > If it is reset-asserted on the while, the console output
>>> > will not be good.
>>>
>>> indeed, so let's skip this idea
>>
>> Maybe we should at first add initial reset assertion to the Meson driver
>> on a case by case bases?
> this seems simple enough to test it - we can still generalize this
> later on (either by adding support to the reset framework, DT bindings
> or something else)
>
>> We can't add required reset hog DT bindings to the Meson reset
>> controller anyway without breaking DT backwards compatibility.
>>
>>> > > - specify a list of reset lines and their desired state (or to keep it
>>> > > easy: specify a list of reset lines that should be asserted)
>>> > > (I must admit that this is basically your idea but the definition is
>>> > > moved from device-tree to the reset controller driver)
>>> >
>>> > Yes, I think the list of "reset line ID" and "init state" pairs
>>> > would be nicer.
>>>
>>> $ grep -R "of_reset_n_cells = [^1]" drivers/reset/
>>> drivers/reset/reset-berlin.c: priv->rcdev.of_reset_n_cells = 2;
>>> drivers/reset/hisilicon/reset-hi3660.c: rc->rst.of_reset_n_cells = 2;
>>> drivers/reset/reset-ti-sci.c: data->rcdev.of_reset_n_cells = 2;
>>> drivers/reset/reset-lantiq.c: priv->rcdev.of_reset_n_cells = 2;
>>>
>>> everything else uses only one reset cell
>>> from the lantiq reset dt-binding documentation: "The first cell takes
>>> the reset set bit and the second cell takes the status bit."
>>>
>>> I'm not sure what to do with drivers that specify != 1 reset-cell
>>> though if we use a simple "init state pair"
>>> maybe Philipp can share his opinion on this one as well
>>
>> See above, so far I am not convinced (either way) whether this should be
>> described in the DT at all.
>>
>>> > > any "chip" specific differences could be expressed by using a
>>> > > different of_device_id
>>> > >
>>> > > one the other hand: your "reset hog" solution looks fine to me if
>>> > > reset lines can be board specific
>>> > >
>>> > > > From the discussion with Martin Blumenstingl
>>> > > > (https://lkml.org/lkml/2018/4/28/115),
>>> > > > the problem for Amlogic is that
>>> > > > the reset line is "de-asserted" by default.
>>> > > > If so, the 'reset-hog' would fix the problem,
>>> > > > and DWC3 driver would be able to use
>>> > > > shared, level reset, I think.
>>> > >
>>> > > I think you are right: if we could control the initial state then we
>>> > > should be able to use level resets
>>> >
>>> >
>>> > Even further, can we drop the shared reset_control_reset() support, maybe?
>>> > (in other words, revert commit 7da33a37b48f11)
>>>
>>> I believe we need to keep this if there's hardware out there:
>>> - where the reset controller only supports reset pulses
>>> - at least one reset line is shared between multiple devices
>>>
>>> I didn't have a closer look at the Amlogic Meson6 SoC yet, but I think
>>> it matches above criteria. as far as I know:
>>> - the USB situation there is similar to Meson8b (USB controllers and
>>> PHYs share a reset line)
>>> - it uses an older reset controller IP block which does not support
>>> level resets (only reset pulses)
>>
>> See my answer to Masahiro's first mail. I think somebody suggested in
>> the past to add a fallback from the deassert to the reset op. I think
>> this is something that should work in this case.
> this is an interesting idea - it should work for Meson6 (in case
> mainline ever gains support for this old SoC)
>
>
One more thing.
I want to remove reset_control_reset() entirely.
[1] Some reset consumers (e.g. drivers/ata/sata_gemini.c)
use reset_control_reset() to reset the HW.
[2] Some reset consumers (e.g. drivers/input/keyboard/tegra-kbc.c)
use the combination of reset_control_assert() and reset_control_deassert()
to reset the HW.
[1] is the only way if the reset controller only supports the pulse reset.
[2] is the only way if the reset controller only supports the level reset.
So, this is another strangeness because
the implementation of reset controller
affects reset consumers.
We do not need [1].
[2] is more flexible than [1] because hardware usually specifies
how long the reset line should be kept asserted.
For all reset consumers,
replace
reset_control_reset();
with
reset_control_assert();
reset_control_deassert();
and deprecate reset_control_reset().
I think this is the right thing to do.
The reset controller side should be implemented like this:
If your reset controller only supports the pulse reset,
.deassert hook should be no-op.
.assert hook should pulse the reset
Then .reset hook should be removed.
Or, we can keep the reset drivers as they are.
drivers/reset/core.c can take care of the proper fallback logic.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
From: Doug Anderson @ 2018-05-30 5:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7489cd65fedb8a31488cf8188885759bcd4820ce.1527040878.git.collinsd@codeaurora.org>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
> + * @ever_enabled: Boolean indicating that the regulator has been
> + * explicitly enabled at least once. Voltage
> + * requests should be cached when this flag is not
> + * set.
Do you really need this extra boolean? Can't you just check if
"enabled" is still "-EINVAL"? If it is then you don't pass the
voltage along.
...this would mean that you'd also need to send the voltage vote when
the regulator core tries to disable unused regulators at the end of
bootup, but that should be OK right? If we never touched a regulator
anywhere at probe time and we're about to vote to disable it, we know
there's nobody requiring it to still be on. We can vote for the
voltage now without fear of messing up a vote that the BIOS left in
place.
In theory this should also allow you to assert your vote about the
voltage of a regulator that has never been enabled, which (if I
understand correctly) you consider to be a feature.
---
Other than that comment, everything else here looks good to go if Mark
is good with it. As per the previous threads there are some things
that I don't like a ton, but I feel it is between you and Mark to
decide if you're good with it. A summary of those issues are:
1. I still believe that when we disable a regulator in Linux we should
tell RPMh that we vote for the lowest voltage. ...but if Mark is
happy with the way the driver works now I won't push it.
2. As per my comments in the bindings patch, I still believe that
"qcom,drms-mode-max-microamps" belongs in the core. Again, up to
Mark.
3. As per my comments in the bindings patch, I still believe that
we're just adding lots of noise to the DT most of the time by
specifying both "qcom,regulator-drms-modes" and
"regulator-allowed-modes". Again, up to Mark.
-Doug
^ 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