* [PATCH 0/2] ARM: imx31/of: clk: init clock controller with CLK_OF_DECLARE
From: Uwe Kleine-König @ 2016-09-19 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474252939-12579-1-git-send-email-vz@mleia.com>
Hello,
On Mon, Sep 19, 2016 at 05:42:17AM +0300, Vladimir Zapolskiy wrote:
> The change is based on v4.8.0-rc1 and plus it depends on this fixup:
>
> ARM: dts: imx31: fix clock control module interrupts description
>
> The change is tested on qemu kzm target and mx31lite board, while both
> targets don't have DTS in upstream, I had to write simple DTS files for
> them, because the proposed change is for i.MX31 targets with OF support.
>
> The second change in the series compilation time dependent on the first
> one, while the first change apparently should break runtime execution
> of i.MX31 boards with OF support, if both changes are applied everything
> should be fine, regression testing on the same legacy targets does not
that means this should be done in a single patch.
> show any problems. Moreover i.MX31/OF/clock initialization seems to be
> broken currently, if the change is not applied I can not get a working
> clock source during early boot stage, jiffies are not incremented, but
> because I didn't check the problem thoroughly (can it be caused by
> missing CLK_OF_DECLARE? Or caused by something fixed by the change
> http://www.spinics.net/lists/linux-clk/msg12235.html ?) and because
> the change was tested against code which is not found in upstream,
> I won't call this change as a fix, however its application is apparently
> wanted to get better OF support for i.MX31 targets.
Very appreciated!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v6 0/6] Add MT8173 MDP Driver
From: Minghsiu Tsai @ 2016-09-19 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <703024ec-f6d4-60e8-ed09-6a2e935857d7@xs4all.nl>
On Wed, 2016-09-14 at 14:43 +0200, Hans Verkuil wrote:
> Hi Minghsiu,
>
> v6 looks good, but I get these warnings when compiling it for i686:
>
> linux-git-i686: WARNINGS
>
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_handle_init_ack':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:28:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_ipi_handler':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:40:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_send_ap_ipi':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:111:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_init':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:129:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
>
> This is not blocking, but if you can post a follow-up patch for this, then that
> would be helpful.
>
Hi Hans,
I have duplicated this warning message in arch x86.
I also got the report from kbuild robot. There are build errors in
mtk_mdp_pm_suspend().
Besides, in arch x86, I also have build warning messages in kzalloc()
and kfree() used in mtk_mdp_m2m.c. It can be fixed by including
linux/slab.h
I will upload the patches today.
Thanks
Ming Hsiu
> Regards,
>
> Hans
>
>
> On 09/08/2016 03:09 PM, Minghsiu Tsai wrote:
> > Changes in v6:
> > - s_selection() can't set the _DEFAULT and _BOUNDS targets
> > - Add Maintainers entry
> >
> > Changes in v5:
> > - Add ack in the comment of dts patch
> > - Fix s/g_selection()
> > - Separate format V4L2_PIX_FMT_MT21C into new patch
> >
> > Changes in v4:
> > - Add "depends on HAS_DMA" in Kconfig.
> > - Fix s/g_selection()
> > - Replace struct v4l2_crop with u32 and struct v4l2_rect
> > - Remove VB2_USERPTR
> > - Move mutex lock after ctx allocation in mtk_mdp_m2m_open()
> > - Add new format V4L2_PIX_FMT_YVU420 to support software on Android platform.
> > - Only width/height of image in format V4L2_PIX_FMT_MT21 is aligned to 16/16,
> > other ones are aligned to 2/2 by default
> >
> > Changes in v3:
> > - Modify device ndoe as structured one.
> > - Fix conflict in dts on Linux 4.8-rc1
> >
> > Changes in v2:
> > - Add section to describe blocks function in dts-bindings
> > - Remove the assignment of device_caps in querycap()
> > - Remove format's name assignment
> > - Copy colorspace-related parameters from OUTPUT to CAPTURE
> > - Use m2m helper functions
> > - Fix DMA allocation failure
> > - Initialize lazily vpu instance in streamon()
> >
> > ==============
> > Introduction
> > ==============
> >
> > The purpose of this series is to add the driver for Media Data Path HW embedded in the Mediatek's MT8173 SoC.
> > MDP is used for scaling and color space conversion.
> >
> > It could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or V4L2_PIX_FMT_YUV420M.
> >
> > NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M
> >
> > This patch series rely on MTK VPU driver in patch series "Add MT8173 Video Encoder Driver and VPU Driver"[1] and "Add MT8173 Video Decoder Driver"[2].
> > MDP driver rely on VPU driver to load, communicate with VPU.
> >
> > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both have been merged in v4.6-rc1.
> >
> > [1]https://patchwork.kernel.org/patch/9002171/
> > [2]https://patchwork.kernel.org/patch/9141245/
> >
> > ==================
> > Device interface
> > ==================
> >
> > In principle the driver bases on v4l2 memory-to-memory framework:
> > it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers) and CAPTURE (for destination buffers).
> > OUTPUT and CAPTURE buffer could be MMAP or DMABUF memory type.
> >
> > v4l2-compliance test output:
> > v4l2-compliance SHA : abc1453dfe89f244dccd3460d8e1a2e3091cbadb
> >
> > Driver Info:
> > Driver name : mtk-mdp
> > Card type : soc:mdp
> > Bus info : platform:mt8173
> > Driver version: 4.8.0
> > Capabilities : 0x84204000
> > Video Memory-to-Memory Multiplanar
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04204000
> > Video Memory-to-Memory Multiplanar
> > Streaming
> > Extended Pix Format
> >
> > Compliance test for device /dev/image-proc0 (not using libv4l2):
> >
> > Required ioctls:
> > test VIDIOC_QUERYCAP: OK
> >
> > Allow for multiple opens:
> > test second video open: OK
> > test VIDIOC_QUERYCAP: OK
> > test VIDIOC_G/S_PRIORITY: OK
> > test for unlimited opens: OK
> >
> > Debug ioctls:
> > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> > test VIDIOC_LOG_STATUS: OK (Not Supported)
> >
> > Input ioctls:
> > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> > test VIDIOC_ENUMAUDIO: OK (Not Supported)
> > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 0 Audio Inputs: 0 Tuners: 0
> >
> > Output ioctls:
> > test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> > Outputs: 0 Audio Outputs: 0 Modulators: 0
> >
> > Input/Output configuration ioctls:
> > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> > test VIDIOC_G/S_EDID: OK (Not Supported)
> >
> > Control ioctls:
> > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> > test VIDIOC_QUERYCTRL: OK
> > test VIDIOC_G/S_CTRL: OK
> > test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > Standard Controls: 5 Private Controls: 0
> >
> > Format ioctls:
> > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> > test VIDIOC_G/S_PARM: OK (Not Supported)
> > test VIDIOC_G_FBUF: OK (Not Supported)
> > test VIDIOC_G_FMT: OK
> > test VIDIOC_TRY_FMT: OK
> > test VIDIOC_S_FMT: OK
> > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> > test Cropping: OK
> > test Composing: OK
> > test Scaling: OK
> >
> > Codec ioctls:
> > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> > test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >
> > Buffer ioctls:
> > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> > test VIDIOC_EXPBUF: OK
> >
> > Test input 0:
> >
> >
> > Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
> >
> > Minghsiu Tsai (6):
> > VPU: mediatek: Add mdp support
> > dt-bindings: Add a binding for Mediatek MDP
> > media: Add Mediatek MDP Driver
> > arm64: dts: mediatek: Add MDP for MT8173
> > media: mtk-mdp: support pixelformat V4L2_PIX_FMT_MT21C
> > media: mtk-mdp: add Maintainers entry for Mediatek MDP driver
> >
> > .../devicetree/bindings/media/mediatek-mdp.txt | 109 ++
> > MAINTAINERS | 9 +
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 84 ++
> > drivers/media/platform/Kconfig | 17 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/mtk-mdp/Makefile | 9 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 159 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 72 ++
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 294 +++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 260 ++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h | 126 ++
> > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1278 ++++++++++++++++++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h | 22 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_regs.c | 156 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_regs.h | 31 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 145 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h | 41 +
> > drivers/media/platform/mtk-vpu/mtk_vpu.h | 5 +
> > 18 files changed, 2819 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > create mode 100644 drivers/media/platform/mtk-mdp/Makefile
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h
> >
^ permalink raw reply
* [PATCH] clk: imx31: fix potential stack corruption on clock initialization
From: Uwe Kleine-König @ 2016-09-19 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474249708-11088-1-git-send-email-vz@mleia.com>
On Mon, Sep 19, 2016 at 04:48:28AM +0300, Vladimir Zapolskiy wrote:
> Function mx31_clocks_init() is called during clock intialization on
> legacy boards with reference clock frequency passed as its input
> argument, this can be verified by examination of the function
> declaration found in arch/arm/mach-imx/common.h and actual function
> users which include that header file.
I don't think this can corrupt the stack. The caller puts a value in r0
that is unused by mx31_clocks_init. And given that all callers pass
26000000 there should happen nothing bad apart from a compiler warning.
So: the change is fine, IMHO the commit log shouldn't mention stack
corruption.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2263d508999ada9476268138b2922702eb50131f.1474260360.git.maitysanchayan@gmail.com>
Use enable-gpios property of PWM backlight driver for backlight
control.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Fix commit message
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 8c67dd8..9100bde 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -49,7 +49,10 @@
backlight: backlight {
compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_bl_on>;
pwms = <&pwm4 0 5000000>;
+ enable-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
@@ -614,6 +617,12 @@
>;
};
+ pinctrl_gpio_bl_on: gpioblon {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
+ >;
+ };
+
pinctrl_gpio_keys: gpio1io04grp {
fsl,pins = <
/* Power button */
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: imx6q-apalis-ixora: Remove use of pwm-leds
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2263d508999ada9476268138b2922702eb50131f.1474260360.git.maitysanchayan@gmail.com>
Remove use of pwm-leds and use the standard /sys/class/pwm
interface from PWM subsystem.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index 82b81e0..383192c 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -146,28 +146,6 @@
gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
};
};
-
- pwmleds {
- compatible = "pwm-leds";
-
- ledpwm1 {
- label = "PWM1";
- pwms = <&pwm1 0 50000>;
- max-brightness = <255>;
- };
-
- ledpwm2 {
- label = "PWM2";
- pwms = <&pwm2 0 50000>;
- max-brightness = <255>;
- };
-
- ledpwm3 {
- label = "PWM3";
- pwms = <&pwm3 0 50000>;
- max-brightness = <255>;
- };
- };
};
&backlight {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
Remove the use of DDC I2C bus bitbang to support reading of EDID
and rely on support from internal HDMI I2C master controller instead.
As a result remove the device tree property ddc-i2c-bus.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Change the ranking in i2c aliases
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++---------
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 25 +++++++++----------------
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index 207b85b..82b81e0 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -55,10 +55,9 @@
"fsl,imx6q";
aliases {
- i2c0 = &i2cddc;
- i2c1 = &i2c1;
- i2c2 = &i2c2;
- i2c3 = &i2c3;
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ i2c2 = &i2c3;
};
aliases {
@@ -186,11 +185,6 @@
};
&hdmi {
- ddc-i2c-bus = <&i2cddc>;
- status = "okay";
-};
-
-&i2cddc {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 99e323b..8c67dd8 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -53,18 +53,6 @@
status = "disabled";
};
- /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
- i2cddc: i2c at 0 {
- compatible = "i2c-gpio";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c_ddc>;
- gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
- &gpio2 30 GPIO_ACTIVE_HIGH /* scl */
- >;
- i2c-gpio,delay-us = <2>; /* ~100 kHz */
- status = "disabled";
- };
-
reg_1p8v: regulator-1p8v {
compatible = "regulator-fixed";
regulator-name = "1P8V";
@@ -209,6 +197,12 @@
};
};
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi_ddc>;
+ status = "disabled";
+};
+
/*
* GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
* board)
@@ -633,11 +627,10 @@
>;
};
- pinctrl_i2c_ddc: gpioi2cddcgrp {
+ pinctrl_hdmi_ddc: hdmiddcgrp {
fsl,pins = <
- /* DDC bitbang */
- MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
- MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
>;
};
--
2.9.3
^ permalink raw reply related
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kishon Vijay Abraham I @ 2016-09-19 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCC5fhbtkNdc6MJs7veD+xVGC6Qb-jgX_pwvraP1x2JrhQ@mail.gmail.com>
Hi,
On Monday 19 September 2016 01:26 AM, Martin Blumenstingl wrote:
> Hi Kishon,
>
> On Fri, Sep 16, 2016 at 10:19 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> Hi,
>>
>> On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
>>> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>>>> However, the problem with all of the solutions proposed (runtime PM ones
>>>> included) is that we're forcing a board-specific design issue (2 devices
>>>> sharing a reset line) into a driver that should not have any
>>>> board-specific assumptions in it.
>>>>
>>>> For example, if this driver is used on another platform where different
>>>> PHYs have different reset lines, then one of them (the unlucky one who
>>>> is not probed first) will never get reset. So any form of per-device
>>>> ref-counting is not a portable solution.
>>> maybe we should also consider Ben's solution: he played with the USB
>>> PHY on his Meson8b board. His approach was to have only one USB PHY
>>> driver instance which exposes two PHYs.
>>> The downside of this: the driver would have to know the offset of the
>>> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
>>> the reset using runtime PM without any hacks.
>>
>> I think the offset information can come from the devicetree too. The phy can be
>> modeled something like below.
>>
>> usb-phys at c0000000 {
>> compatible = "amlogic,meson-gxbb-usb2-phy";
>> reg = <0x0 0xc0000000 0x0 0x40>;
>> #address-cells = <2>;
>> #size-cells = <2>;
>> ranges = <0x0 0x0 0x0 0xc0000000 0x0 0x40>;
>> resets = <&reset 34>;
>>
>> usb0_phy: usb_phy at 0 {
>> #phy-cells = <0>;
>> reg = <0x0 0x0 0x0 0x20>;
>> clocks = <&clkc CLKID_USB &clkc CLKID_USB0>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>>
>> usb1_phy: usb_phy at 20 {
>> #phy-cells = <0>;
>> reg = <0x0 0x20 0x0 0x20>;
>> clocks = <&clkc CLKID_USB &clkc CLKID_USB1>;
>> clock-names = "usb_general", "usb";
>> status = "disabled";
>> };
>> };
>>
>> This way the driver will be probed only once (the reset can be done during
>> probe). The phy driver should scan the dt node and for every sub-node it
>> invokes phy_create?
> I'll recap what we have discussed so far (so you don't have to re-read
> the whole thread):
> The reference driver treats both USB PHYs as separate devices (the
> datasheet has no information about the PHYs though). The only
> "special" thing is the shared reset line -> together with Philipp
> Zabel (the reset framework maintainer) we decided to make
> reset_control_reset work for shared reset lines.
>
> That means we can keep the two PHYs as separate devices inside the
> .dts, while keeping everything else separate (just like the reference
> driver)
> Is this fine for you and Arnd?
yeah.. I'm fine with that.
Thanks
Kishon
>
>
> Regards,
> Martin
>
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 4:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912113615.GA20804@leverpostej>
On Mon, 2016-09-12 at 12:36 +0100, Mark Rutland wrote:
> On Fri, Sep 09, 2016 at 08:03:31PM -0500, Scott Wood wrote:
> > +static __always_inline void arch_timer_cval_write_cp15(int access, u64
> > val)
> > +{
> > + if (access == ARCH_TIMER_PHYS_ACCESS)
> > + asm volatile("msr cntp_cval_el0, %0" : : "r" (val));
> > + else if (access == ARCH_TIMER_VIRT_ACCESS)
> > + asm volatile("msr cntv_cval_el0, %0" : : "r" (val));
> > +
> > + isb();
> > +}
> Please add ARCH_TIMER_REG_CVAL to enum arch_timer_reg, and move these
> accesses into arch_timer_reg_write_cp15().
Adding ARCH_TIMER_REG_CVAL to the enum means we get warnings from bunch of
switch statements that don't actually need a CVAL implementation -- or else we
have to add untested CVAL accessors for arm32 and mmio. ?The arm32 part would
add another dependency on getting an ack from RMK, that can't be postponed as
easily as the archdata/vdso patch.
Since this is specific to an erratum rather than general cval support, I can
move the accesses into fsl_a008585_set_next_event (and convert to
write_sysreg).
> >
> > +
> > + do {
> > + isb();
> What's the ISB for?
>
> The core should order accesses to the same counter, and any ISB required
> for ordering against other counters should already be present. So I
> don't follow what this is trying to achieve.
>
> If this is necessary, please add a comment explaining what it is
> intended to ensure.
I think it may have been a leftover from early patch versions when this
function was entirely replacing arch_counter_get_cntvct(). ?I'm not sure why I
put it in the loop, though.
> > @@ -271,6 +346,19 @@ static int
> > arch_timer_set_next_event_phys_mem(unsigned long evt,
> > ? return 0;
> > ?}
> > ?
> > +static void fsl_a008585_set_sne(struct clock_event_device *clk)
> > +{
> > +#ifdef CONFIG_FSL_ERRATUM_A008585
> > + if (!static_branch_unlikely(&arch_timer_read_ool_enabled))
> > + return;
> > +
> > + if (arch_timer_uses_ppi == VIRT_PPI)
> > + clk->set_next_event = fsl_a008585_set_next_event_virt;
> > + else
> > + clk->set_next_event = fsl_a008585_set_next_event_phys;
> > +#endif
> > +}
> > +
> I'm not keen on the magic hook to reset the function pointers, and the
> additional phys/virt stubs seem pointless. Instead, can we fold this
> into the existing set_next_event? e.g. have that do:
>
> if (needs_fsl_a008585_workaround() {
> fsl_a008585_set_next_event(access, evt, clk);
> return;
> }
OK. ?I had been trying to avoid messing with the standard set_next_event, but
it doesn't matter as much now that static branches are being used. ?In that
case we can avoid duplicating the ctrl code, and only replace the tval write.
-Scott
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D6A88D.7000002@arm.com>
On Mon, 2016-09-12 at 14:07 +0100, Marc Zyngier wrote:
> On 12/09/16 13:59, Mark Rutland wrote:
> >
> > On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
> > >
> > > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > > >
> > > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > > >
> > > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > > some cleanup [1,2] that just landed in the arm64 for-next/core
> > > > > branch.
> > > > >
> > > > > Could you please rebase atop of that?
> > > > Well, we should figure out what tree this is going through first.
> > > > There
> > > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > > of it is carrying the appropriate acks for me to queue it.
> > > Given that mix, I had assumed that this would all go through the arm64
> > > tree -- I see that Rob has already acked the binding, and I'm happy to
> > > give my ack for the driver once that's in shape.
> > Now I see that I'd missed the arch/arm changes in patch 4, which lack a
> > relevant ack.
> >
> > Given that, I don't know what to suggest.
> I wouldn't mind delaying patch 4 until it gets acked by RMK, as it
> doesn't impact the functionality.
Mark asked me to move that patch before the workaround patch, to avoid ever
having to add more code that messes with the name. ?Should I keep the order as
is then?
-Scott
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Scott Wood @ 2016-09-19 4:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912123027.GA13741@leverpostej>
On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> >
> > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > >
> > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > >
> > > Could you please rebase atop of that?
> > Well, we should figure out what tree this is going through first. There
> > are a mixture of arm, arm64, driver and dts changes here and not all
> > of it is carrying the appropriate acks for me to queue it.
> Given that mix, I had assumed that this would all go through the arm64
> tree -- I see that Rob has already acked the binding, and I'm happy to
> give my ack for the driver once that's in shape.
>
> The dts change could go through arm-soc in parallel, I guess. It doesn't
> look like arm-soc have been Cc'd for that, though.
The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
did. ?There doesn't appear to be a separate arm-soc mailing list, nor is there
a request to CC Olof/Arnd. ?I did CC Shawn Guo who has been handling the
device tree patches for these chips.
-Scott
^ permalink raw reply
* We could not deliver your parcel, #000246043
From: FedEx Standard Overnight @ 2016-09-19 3:58 UTC (permalink / raw)
To: linux-arm-kernel
Dear Customer,
Courier was unable to deliver the parcel to you.
Please, download Delivery Label attached to this email.
Thanks and best regards,
Tony Goodman,
Support Manager.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Delivery_Notification_000246043.zip
Type: application/zip
Size: 6671 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/c6f03669/attachment-0001.zip>
^ permalink raw reply
* [PATCH V2 1/7] dt-bindings: Update QorIQ TMU thermal bindings
From: Zhang Rui @ 2016-09-19 2:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADRPPNQ+hikr1qNK1wPbLnhudUrU1bN_2iuYyRQnqCN4Zwh83Q@mail.gmail.com>
On ?, 2016-09-14 at 11:40 -0500, Leo Li wrote:
> On Wed, Jun 8, 2016 at 2:52 PM, Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Jun 07, 2016 at 11:27:34AM +0800, Jia Hongtao wrote:
> > >
> > > For different types of SoC the sensor id and endianness may vary.
> > > "#thermal-sensor-cells" is used to provide sensor id information.
> > > "little-endian" property is to tell the endianness of TMU.
> > >
> > > Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
> > > ---
> > > Changes for V2:
> > > * Remove formatting chnages.
> > >
> > > ?Documentation/devicetree/bindings/thermal/qoriq-thermal.txt | 7
> > > +++++++
> > > ?1 file changed, 7 insertions(+)
> > Acked-by: Rob Herring <robh@kernel.org>
> Hi Zhang Rui,
>
> Since you have applied the driver patch, can you also apply the
> binding patch???The binding is supposed to go with the driver.
>
Do you mean I should take both patch 1/7 and 7/7? I can not see the
other patches in this patch set.
thanks,
rui
^ permalink raw reply
* [PATCH 2/2] clk: imx31: properly init clocks for machines with DT
From: Vladimir Zapolskiy @ 2016-09-19 2:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474252939-12579-1-git-send-email-vz@mleia.com>
The change converts exported mx31_clocks_init_dt() into a static
initialization function registered by CLK_OF_DECLARE().
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/clk/imx/clk-imx31.c | 50 +++++++++++++++++++++++----------------------
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 6a49ba2..cbce308 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -21,6 +21,7 @@
#include <linux/io.h>
#include <linux/err.h>
#include <linux/of.h>
+#include <linux/of_address.h>
#include <soc/imx/revision.h>
#include <soc/imx/timer.h>
#include <asm/irq.h>
@@ -72,14 +73,8 @@ static struct clk ** const uart_clks[] __initconst = {
NULL
};
-static void __init _mx31_clocks_init(unsigned long fref)
+static void __init _mx31_clocks_init(void __iomem *base, unsigned long fref)
{
- void __iomem *base;
- struct device_node *np;
-
- base = ioremap(MX31_CCM_BASE_ADDR, SZ_4K);
- BUG_ON(!base);
-
clk[dummy] = imx_clk_fixed("dummy", 0);
clk[ckih] = imx_clk_fixed("ckih", fref);
clk[ckil] = imx_clk_fixed("ckil", 32768);
@@ -147,19 +142,17 @@ static void __init _mx31_clocks_init(unsigned long fref)
clk_prepare_enable(clk[iim_gate]);
mx31_revision();
clk_disable_unprepare(clk[iim_gate]);
-
- np = of_find_compatible_node(NULL, NULL, "fsl,imx31-ccm");
-
- if (np) {
- clk_data.clks = clk;
- clk_data.clk_num = ARRAY_SIZE(clk);
- of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
- }
}
int __init mx31_clocks_init(unsigned long fref)
{
- _mx31_clocks_init(fref);
+ void __iomem *base;
+
+ base = ioremap(MX31_CCM_BASE_ADDR, SZ_4K);
+ if (!base)
+ panic("%s: failed to map registers\n", __func__);
+
+ _mx31_clocks_init(base, fref);
clk_register_clkdev(clk[gpt_gate], "per", "imx-gpt.0");
clk_register_clkdev(clk[ipg], "ipg", "imx-gpt.0");
@@ -222,22 +215,31 @@ int __init mx31_clocks_init(unsigned long fref)
return 0;
}
-int __init mx31_clocks_init_dt(void)
+static void __init mx31_clocks_init_dt(struct device_node *np)
{
- struct device_node *np;
+ struct device_node *osc_np;
u32 fref = 26000000; /* default */
+ void __iomem *ccm;
- for_each_compatible_node(np, NULL, "fixed-clock") {
- if (!of_device_is_compatible(np, "fsl,imx-osc26m"))
+ for_each_compatible_node(osc_np, NULL, "fixed-clock") {
+ if (!of_device_is_compatible(osc_np, "fsl,imx-osc26m"))
continue;
- if (!of_property_read_u32(np, "clock-frequency", &fref)) {
- of_node_put(np);
+ if (!of_property_read_u32(osc_np, "clock-frequency", &fref)) {
+ of_node_put(osc_np);
break;
}
}
- _mx31_clocks_init(fref);
+ ccm = of_iomap(np, 0);
+ if (!ccm)
+ panic("%s: failed to map registers\n", __func__);
- return 0;
+ _mx31_clocks_init(ccm, fref);
+
+ clk_data.clks = clk;
+ clk_data.clk_num = ARRAY_SIZE(clk);
+ of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
}
+
+CLK_OF_DECLARE(imx31_ccm, "fsl,imx31-ccm", mx31_clocks_init_dt);
--
2.8.1
^ permalink raw reply related
* [PATCH 1/2] ARM: imx31: remove mx31_clocks_init_dt() function calls
From: Vladimir Zapolskiy @ 2016-09-19 2:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474252939-12579-1-git-send-email-vz@mleia.com>
Clock initialization for i.MX31 powered machines with DT support
should be done by a call of an init function registered with
CLK_OF_DECLARE() in common clock framework.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/imx31-dt.c | 6 ------
2 files changed, 7 deletions(-)
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index a8f4693..e97d8cb 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -48,7 +48,6 @@ int mx21_clocks_init(unsigned long lref, unsigned long fref);
int mx27_clocks_init(unsigned long fref);
int mx31_clocks_init(unsigned long fref);
int mx35_clocks_init(void);
-int mx31_clocks_init_dt(void);
struct platform_device *mxc_register_gpio(char *name, int id,
resource_size_t iobase, resource_size_t iosize, int irq, int irq_high);
void mxc_set_cpu_type(unsigned int type);
diff --git a/arch/arm/mach-imx/imx31-dt.c b/arch/arm/mach-imx/imx31-dt.c
index 62e6b4f..668d74b 100644
--- a/arch/arm/mach-imx/imx31-dt.c
+++ b/arch/arm/mach-imx/imx31-dt.c
@@ -23,11 +23,6 @@ static const char * const imx31_dt_board_compat[] __initconst = {
NULL
};
-static void __init imx31_dt_timer_init(void)
-{
- mx31_clocks_init_dt();
-}
-
/* FIXME: replace with DT binding */
static const struct resource imx31_rnga_res[] __initconst = {
DEFINE_RES_MEM(MX31_RNGA_BASE_ADDR, SZ_16K),
@@ -43,7 +38,6 @@ DT_MACHINE_START(IMX31_DT, "Freescale i.MX31 (Device Tree Support)")
.map_io = mx31_map_io,
.init_early = imx31_init_early,
.init_irq = mx31_init_irq,
- .init_time = imx31_dt_timer_init,
.init_machine = imx31_dt_mach_init,
.dt_compat = imx31_dt_board_compat,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 0/2] ARM: imx31/of: clk: init clock controller with CLK_OF_DECLARE
From: Vladimir Zapolskiy @ 2016-09-19 2:42 UTC (permalink / raw)
To: linux-arm-kernel
The change is based on v4.8.0-rc1 and plus it depends on this fixup:
ARM: dts: imx31: fix clock control module interrupts description
The change is tested on qemu kzm target and mx31lite board, while both
targets don't have DTS in upstream, I had to write simple DTS files for
them, because the proposed change is for i.MX31 targets with OF support.
The second change in the series compilation time dependent on the first
one, while the first change apparently should break runtime execution
of i.MX31 boards with OF support, if both changes are applied everything
should be fine, regression testing on the same legacy targets does not
show any problems. Moreover i.MX31/OF/clock initialization seems to be
broken currently, if the change is not applied I can not get a working
clock source during early boot stage, jiffies are not incremented, but
because I didn't check the problem thoroughly (can it be caused by
missing CLK_OF_DECLARE? Or caused by something fixed by the change
http://www.spinics.net/lists/linux-clk/msg12235.html ?) and because
the change was tested against code which is not found in upstream,
I won't call this change as a fix, however its application is apparently
wanted to get better OF support for i.MX31 targets.
Vladimir Zapolskiy (2):
ARM: imx31: remove mx31_clocks_init_dt() function calls
clk: imx31: properly init clocks for machines with DT
arch/arm/mach-imx/common.h | 1 -
arch/arm/mach-imx/imx31-dt.c | 6 ------
drivers/clk/imx/clk-imx31.c | 49 ++++++++++++++++++++++----------------------
3 files changed, 25 insertions(+), 31 deletions(-)
--
2.8.1
^ permalink raw reply
* [PATCH] ARM: dts: imx31: fix clock control module interrupts description
From: Vladimir Zapolskiy @ 2016-09-19 1:54 UTC (permalink / raw)
To: linux-arm-kernel
The type of AVIC interrupt controller found on i.MX31 is one-cell,
namely 31 for CCM DVFS and 53 for CCM, however for clock control
module its interrupts are specified as 3-cells, fix it.
Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
Documentation/devicetree/bindings/clock/imx31-clock.txt | 2 +-
arch/arm/boot/dts/imx31.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.txt b/Documentation/devicetree/bindings/clock/imx31-clock.txt
index 19df842..8163d56 100644
--- a/Documentation/devicetree/bindings/clock/imx31-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx31-clock.txt
@@ -77,7 +77,7 @@ Examples:
clks: ccm at 53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
- interrupts = <0 31 0x04 0 53 0x04>;
+ interrupts = <31>, <53>;
#clock-cells = <1>;
};
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 1ce7ae9..3e0893e 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -122,7 +122,7 @@
clks: ccm at 53f80000{
compatible = "fsl,imx31-ccm";
reg = <0x53f80000 0x4000>;
- interrupts = <0 31 0x04 0 53 0x04>;
+ interrupts = <31>, <53>;
#clock-cells = <1>;
};
};
--
2.8.1
^ permalink raw reply related
* [PATCH] clk: imx31: fix potential stack corruption on clock initialization
From: Vladimir Zapolskiy @ 2016-09-19 1:48 UTC (permalink / raw)
To: linux-arm-kernel
Function mx31_clocks_init() is called during clock intialization on
legacy boards with reference clock frequency passed as its input
argument, this can be verified by examination of the function
declaration found in arch/arm/mach-imx/common.h and actual function
users which include that header file.
Fixes: d9388c843237 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT")
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
drivers/clk/imx/clk-imx31.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/clk/imx/clk-imx31.c b/drivers/clk/imx/clk-imx31.c
index 6a96414..6a49ba2 100644
--- a/drivers/clk/imx/clk-imx31.c
+++ b/drivers/clk/imx/clk-imx31.c
@@ -157,10 +157,8 @@ static void __init _mx31_clocks_init(unsigned long fref)
}
}
-int __init mx31_clocks_init(void)
+int __init mx31_clocks_init(unsigned long fref)
{
- u32 fref = 26000000; /* default */
-
_mx31_clocks_init(fref);
clk_register_clkdev(clk[gpt_gate], "per", "imx-gpt.0");
--
2.8.1
^ permalink raw reply related
* [PATCH] ASoC: samsung: make audio interface/controller explicitly
From: kbuild test robot @ 2016-09-19 1:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474207751-9804-2-git-send-email-ayaka@soulik.info>
Hi Randy,
[auto build test ERROR on asoc/for-next]
[also build test ERROR on v4.8-rc7 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Randy-Li/ASoC-samsung-make-audio-interface-controller-explicitly/20160918-222618
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
sound/built-in.o: In function `s3c_ac97_probe':
>> ac97.c:(.text+0x336f9d): undefined reference to `samsung_asoc_dma_platform_register'
sound/built-in.o: In function `spdif_probe':
>> spdif.c:(.text+0x3378de): undefined reference to `samsung_asoc_dma_platform_register'
sound/built-in.o: In function `s3c_pcm_dev_probe':
>> pcm.c:(.text+0x3380e7): undefined reference to `samsung_asoc_dma_platform_register'
sound/built-in.o: In function `samsung_i2s_probe':
>> i2s.c:(.text+0x338c01): undefined reference to `samsung_asoc_dma_platform_register'
i2s.c:(.text+0x338ef6): undefined reference to `samsung_asoc_dma_platform_register'
---
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/octet-stream
Size: 55181 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160919/580007ea/attachment-0001.obj>
^ permalink raw reply
* [PATCH 19/19] ARM: imx legacy: pca100: move peripheral initialization to .init_late
From: Vladimir Zapolskiy @ 2016-09-19 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
The change moves some of peripheral registrations and initializations
(all peripherals dependent on GPIOs) from .init_machine to .init_late
level, this allows to safely shift the shared GPIO controller driver
initialization level after init level of i.MX IOMUXC driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/mach-pca100.c | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-imx/mach-pca100.c b/arch/arm/mach-imx/mach-pca100.c
index 2d1c50b..ed67586 100644
--- a/arch/arm/mach-imx/mach-pca100.c
+++ b/arch/arm/mach-imx/mach-pca100.c
@@ -362,12 +362,8 @@ static void __init pca100_init(void)
if (ret)
printk(KERN_ERR "pca100: Failed to setup pins (%d)\n", ret);
- imx27_add_imx_ssi(0, &pca100_ssi_pdata);
-
imx27_add_imx_uart0(&uart_pdata);
- imx27_add_mxc_mmc(1, &sdhc_pdata);
-
imx27_add_mxc_nand(&pca100_nand_board_info);
/* only the i2c master 1 is used on this CPU card */
@@ -382,6 +378,19 @@ static void __init pca100_init(void)
ARRAY_SIZE(pca100_spi_board_info));
imx27_add_spi_imx0(&pca100_spi0_data);
+ imx27_add_imx_fb(&pca100_fb_data);
+
+ imx27_add_fec(NULL);
+ imx27_add_imx2_wdt();
+ imx27_add_mxc_w1();
+}
+
+static void __init pca100_late_init(void)
+{
+ imx27_add_imx_ssi(0, &pca100_ssi_pdata);
+
+ imx27_add_mxc_mmc(1, &sdhc_pdata);
+
gpio_request(OTG_PHY_CS_GPIO, "usb-otg-cs");
gpio_direction_output(OTG_PHY_CS_GPIO, 1);
gpio_request(USBH2_PHY_CS_GPIO, "usb-host2-cs");
@@ -403,12 +412,6 @@ static void __init pca100_init(void)
if (usbh2_pdata.otg)
imx27_add_mxc_ehci_hs(2, &usbh2_pdata);
-
- imx27_add_imx_fb(&pca100_fb_data);
-
- imx27_add_fec(NULL);
- imx27_add_imx2_wdt();
- imx27_add_mxc_w1();
}
static void __init pca100_timer_init(void)
@@ -421,7 +424,8 @@ MACHINE_START(PCA100, "phyCARD-i.MX27")
.map_io = mx27_map_io,
.init_early = imx27_init_early,
.init_irq = mx27_init_irq,
- .init_machine = pca100_init,
+ .init_machine = pca100_init,
+ .init_late = pca100_late_init,
.init_time = pca100_timer_init,
.restart = mxc_restart,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 18/19] ARM: imx legacy: mx27ads: move peripheral initialization to .init_late
From: Vladimir Zapolskiy @ 2016-09-19 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
The change moves some of peripheral registrations and initializations
(all peripherals dependent on GPIOs) from .init_machine to .init_late
level, this allows to safely shift the shared GPIO controller driver
initialization level after init level of i.MX IOMUXC driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/mach-mx27ads.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx27ads.c b/arch/arm/mach-imx/mach-mx27ads.c
index a4c389e..a04bb09 100644
--- a/arch/arm/mach-imx/mach-mx27ads.c
+++ b/arch/arm/mach-imx/mach-mx27ads.c
@@ -352,14 +352,20 @@ static void __init mx27ads_board_init(void)
i2c_register_board_info(1, mx27ads_i2c_devices,
ARRAY_SIZE(mx27ads_i2c_devices));
imx27_add_imx_i2c(1, &mx27ads_i2c1_data);
- mx27ads_regulator_init();
imx27_add_imx_fb(&mx27ads_fb_data);
+
+ imx27_add_fec(NULL);
+ imx27_add_mxc_w1();
+}
+
+static void __init mx27ads_late_init(void)
+{
+ mx27ads_regulator_init();
+
imx27_add_mxc_mmc(0, &sdhc1_pdata);
imx27_add_mxc_mmc(1, &sdhc2_pdata);
- imx27_add_fec(NULL);
platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
- imx27_add_mxc_w1();
}
static void __init mx27ads_timer_init(void)
@@ -395,5 +401,6 @@ MACHINE_START(MX27ADS, "Freescale i.MX27ADS")
.init_irq = mx27_init_irq,
.init_time = mx27ads_timer_init,
.init_machine = mx27ads_board_init,
+ .init_late = mx27ads_late_init,
.restart = mxc_restart,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 17/19] ARM: imx legacy: mx21ads: move peripheral initialization to .init_late
From: Vladimir Zapolskiy @ 2016-09-19 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
The change moves some of peripheral registrations and initializations
(all peripherals dependent on GPIOs) from .init_machine to .init_late
level, this allows to safely shift the shared GPIO controller driver
initialization level after init level of i.MX IOMUXC driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/mach-mx21ads.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx21ads.c b/arch/arm/mach-imx/mach-mx21ads.c
index 9986f9a..5e36682 100644
--- a/arch/arm/mach-imx/mach-mx21ads.c
+++ b/arch/arm/mach-imx/mach-mx21ads.c
@@ -302,12 +302,16 @@ static void __init mx21ads_board_init(void)
imx21_add_imx_uart0(&uart_pdata_rts);
imx21_add_imx_uart2(&uart_pdata_norts);
imx21_add_imx_uart3(&uart_pdata_rts);
- imx21_add_mxc_mmc(0, &mx21ads_sdhc_pdata);
imx21_add_mxc_nand(&mx21ads_nand_board_info);
- platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
-
imx21_add_imx_fb(&mx21ads_fb_data);
+}
+
+static void __init mx21ads_late_init(void)
+{
+ imx21_add_mxc_mmc(0, &mx21ads_sdhc_pdata);
+
+ platform_add_devices(platform_devices, ARRAY_SIZE(platform_devices));
mx21ads_cs8900_resources[1].start =
gpio_to_irq(MX21ADS_CS8900A_IRQ_GPIO);
@@ -328,6 +332,7 @@ MACHINE_START(MX21ADS, "Freescale i.MX21ADS")
.init_early = imx21_init_early,
.init_irq = mx21_init_irq,
.init_time = mx21ads_timer_init,
- .init_machine = mx21ads_board_init,
+ .init_machine = mx21ads_board_init,
+ .init_late = mx21ads_late_init,
.restart = mxc_restart,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 16/19] ARM: imx legacy: pcm043: move peripheral initialization to .init_late
From: Vladimir Zapolskiy @ 2016-09-19 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
The change moves some of peripheral registrations and initializations
(all peripherals dependent on GPIOs) from .init_machine to .init_late
level, this allows to safely shift the shared GPIO controller driver
initialization level after init level of i.MX IOMUXC driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/mach-pcm043.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/mach-pcm043.c b/arch/arm/mach-imx/mach-pcm043.c
index e447e59..78e2bf8 100644
--- a/arch/arm/mach-imx/mach-pcm043.c
+++ b/arch/arm/mach-imx/mach-pcm043.c
@@ -363,7 +363,6 @@ static void __init pcm043_init(void)
imx35_add_imx_uart0(&uart_pdata);
imx35_add_mxc_nand(&pcm037_nand_board_info);
- imx35_add_imx_ssi(0, &pcm043_ssi_pdata);
imx35_add_imx_uart1(&uart_pdata);
@@ -387,6 +386,12 @@ static void __init pcm043_init(void)
imx35_add_fsl_usb2_udc(&otg_device_pdata);
imx35_add_flexcan1();
+}
+
+static void __init pcm043_late_init(void)
+{
+ imx35_add_imx_ssi(0, &pcm043_ssi_pdata);
+
imx35_add_sdhci_esdhc_imx(0, &sd1_pdata);
}
@@ -402,6 +407,7 @@ MACHINE_START(PCM043, "Phytec Phycore pcm043")
.init_early = imx35_init_early,
.init_irq = mx35_init_irq,
.init_time = pcm043_timer_init,
- .init_machine = pcm043_init,
+ .init_machine = pcm043_init,
+ .init_late = pcm043_late_init,
.restart = mxc_restart,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 15/19] ARM: imx legacy: scb9328: move peripheral initialization to .init_late
From: Vladimir Zapolskiy @ 2016-09-19 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
The change moves some of peripheral registrations and initializations
(all peripherals dependent on GPIOs) from .init_machine to .init_late
level, this allows to safely shift the shared GPIO controller driver
initialization level after init level of i.MX IOMUXC driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/mach-scb9328.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-scb9328.c b/arch/arm/mach-imx/mach-scb9328.c
index 1f6bc3f..8023769 100644
--- a/arch/arm/mach-imx/mach-scb9328.c
+++ b/arch/arm/mach-imx/mach-scb9328.c
@@ -119,8 +119,12 @@ static void __init scb9328_init(void)
ARRAY_SIZE(mxc_uart1_pins), "UART1");
imx1_add_imx_uart0(&uart_pdata);
+}
+static void __init scb9328_late_init(void)
+{
printk(KERN_INFO"Scb9328: Adding devices\n");
+
dm9000x_resources[2].start = gpio_to_irq(IMX_GPIO_NR(3, 3));
dm9000x_resources[2].end = gpio_to_irq(IMX_GPIO_NR(3, 3));
platform_add_devices(devices, ARRAY_SIZE(devices));
@@ -138,6 +142,7 @@ MACHINE_START(SCB9328, "Synertronixx scb9328")
.init_early = imx1_init_early,
.init_irq = mx1_init_irq,
.init_time = scb9328_timer_init,
- .init_machine = scb9328_init,
+ .init_machine = scb9328_init,
+ .init_late = scb9328_late_init,
.restart = mxc_restart,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 14/19] ARM: imx legacy: apf9328: move peripheral initialization to .init_late
From: Vladimir Zapolskiy @ 2016-09-19 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
The change moves some of peripheral registrations and initializations
(all peripherals dependent on GPIOs) from .init_machine to .init_late
level, this allows to safely shift the shared GPIO controller driver
initialization level after init level of i.MX IOMUXC driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/mach-apf9328.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-apf9328.c b/arch/arm/mach-imx/mach-apf9328.c
index ebbb5ab..3f3ab7f 100644
--- a/arch/arm/mach-imx/mach-apf9328.c
+++ b/arch/arm/mach-imx/mach-apf9328.c
@@ -126,7 +126,10 @@ static void __init apf9328_init(void)
imx1_add_imx_uart1(&uart1_pdata);
imx1_add_imx_i2c(&apf9328_i2c_data);
+}
+static void __init apf9328_late_init(void)
+{
dm9000_resources[2].start = gpio_to_irq(IMX_GPIO_NR(2, 14));
dm9000_resources[2].end = gpio_to_irq(IMX_GPIO_NR(2, 14));
platform_add_devices(devices, ARRAY_SIZE(devices));
@@ -143,6 +146,7 @@ MACHINE_START(APF9328, "Armadeus APF9328")
.init_early = imx1_init_early,
.init_irq = mx1_init_irq,
.init_time = apf9328_timer_init,
- .init_machine = apf9328_init,
+ .init_machine = apf9328_init,
+ .init_late = apf9328_late_init,
.restart = mxc_restart,
MACHINE_END
--
2.8.1
^ permalink raw reply related
* [PATCH 13/19] ARM: imx legacy: mx35-3ds: move peripheral initialization to .init_late
From: Vladimir Zapolskiy @ 2016-09-19 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474248988-10626-1-git-send-email-vz@mleia.com>
The change moves some of peripheral registrations and initializations
(all peripherals dependent on GPIOs) from .init_machine to .init_late
level, this allows to safely shift the shared GPIO controller driver
initialization level after init level of i.MX IOMUXC driver.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/mach-imx/mach-mx35_3ds.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-imx/mach-mx35_3ds.c b/arch/arm/mach-imx/mach-mx35_3ds.c
index 7e315f0..c8c2e09 100644
--- a/arch/arm/mach-imx/mach-mx35_3ds.c
+++ b/arch/arm/mach-imx/mach-mx35_3ds.c
@@ -555,8 +555,6 @@ static const struct imxi2c_platform_data mx35_3ds_i2c0_data __initconst = {
*/
static void __init mx35_3ds_init(void)
{
- struct platform_device *imx35_fb_pdev;
-
imx35_soc_init();
mxc_iomux_v3_setup_multiple_pads(mx35pdk_pads, ARRAY_SIZE(mx35pdk_pads));
@@ -579,9 +577,6 @@ static void __init mx35_3ds_init(void)
imx35_add_mxc_nand(&mx35pdk_nand_board_info);
imx35_add_sdhci_esdhc_imx(0, NULL);
- if (mxc_expio_init(MX35_CS5_BASE_ADDR, IMX_GPIO_NR(1, 1)))
- pr_warn("Init of the debugboard failed, all "
- "devices on the debugboard are unusable.\n");
imx35_add_imx_i2c0(&mx35_3ds_i2c0_data);
i2c_register_board_info(
@@ -590,6 +585,15 @@ static void __init mx35_3ds_init(void)
imx35_add_ipu_core();
platform_device_register(&mx35_3ds_ov2640);
imx35_3ds_init_camera();
+}
+
+static void __init mx35_3ds_late_init(void)
+{
+ struct platform_device *imx35_fb_pdev;
+
+ if (mxc_expio_init(MX35_CS5_BASE_ADDR, IMX_GPIO_NR(1, 1)))
+ pr_warn("Init of the debugboard failed, all "
+ "devices on the debugboard are unusable.\n");
imx35_fb_pdev = imx35_add_mx3_sdc_fb(&mx3fb_pdata);
mx35_3ds_lcd.dev.parent = &imx35_fb_pdev->dev;
@@ -618,6 +622,7 @@ MACHINE_START(MX35_3DS, "Freescale MX35PDK")
.init_irq = mx35_init_irq,
.init_time = mx35pdk_timer_init,
.init_machine = mx35_3ds_init,
+ .init_late = mx35_3ds_late_init,
.reserve = mx35_3ds_reserve,
.restart = mxc_restart,
MACHINE_END
--
2.8.1
^ permalink raw reply related
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