* [PATCH 2/2] clk: sunxi-ng: sun50i: a64: Add 2x fixed post-divider to MMC module clocks
From: Maxime Ripard @ 2017-12-06 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67=2BbOGWpRyujaR-pn6ZEfb1rSRtmzP-kUzXRn_y+iNg@mail.gmail.com>
Hi,
On Wed, Dec 06, 2017 at 10:30:26AM +0800, Chen-Yu Tsai wrote:
> On Wed, Dec 6, 2017 at 3:59 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Mon, Dec 04, 2017 at 01:19:12PM +0800, Chen-Yu Tsai wrote:
> >> On the A64, the MMC module clocks are fixed in the new timing mode,
> >> i.e. they do not have a bit to select the mode. These clocks have
> >> a 2x divider somewhere between the clock and the MMC module.
> >>
> >> To be consistent with other SoCs supporting the new timing mode,
> >> we model the 2x divider as a fixed post-divider on the MMC module
> >> clocks.
> >>
> >> This patch adds the post-dividers to the MMC clocks.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >
> > I had a doubt applying that one... sorry.
> >
> >> ---
> >> drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 57 +++++++++++++++++++++++------------
> >> 1 file changed, 37 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> index 2bb4cabf802f..ee9c12cf3f08 100644
> >> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
> >> @@ -400,28 +400,45 @@ static SUNXI_CCU_MP_WITH_MUX_GATE(nand_clk, "nand", mod0_default_parents, 0x080,
> >> BIT(31), /* gate */
> >> 0);
> >>
> >> +/*
> >> + * MMC clocks are the new timing mode (see A83T & H3) variety, but without
> >> + * the mode switch. This means they have a 2x post divider between the clock
> >> + * and the MMC module. This is not documented in the manual, but is taken
> >> + * into consideration when setting the mmc module clocks in the BSP kernel.
> >> + * Without it, MMC performance is degraded.
> >> + *
> >> + * We model it here to be consistent with other SoCs supporting this mode.
> >> + * The alternative would be to add the 2x multiplier when setting the MMC
> >> + * module clock in the MMC driver, just for the A64.
> >> + */
> >> static const char * const mmc_default_parents[] = { "osc24M", "pll-periph0-2x",
> >> "pll-periph1-2x" };
> >> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc0_clk, "mmc0", mmc_default_parents, 0x088,
> >> - 0, 4, /* M */
> >> - 16, 2, /* P */
> >> - 24, 2, /* mux */
> >> - BIT(31), /* gate */
> >> - 0);
> >> -
> >> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc1_clk, "mmc1", mmc_default_parents, 0x08c,
> >> - 0, 4, /* M */
> >> - 16, 2, /* P */
> >> - 24, 2, /* mux */
> >> - BIT(31), /* gate */
> >> - 0);
> >> -
> >> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mmc_default_parents, 0x090,
> >> - 0, 4, /* M */
> >> - 16, 2, /* P */
> >> - 24, 2, /* mux */
> >> - BIT(31), /* gate */
> >> - 0);
> >> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc0_clk, "mmc0",
> >> + mmc_default_parents, 0x088,
> >> + 0, 4, /* M */
> >> + 16, 2, /* P */
> >> + 24, 2, /* mux */
> >> + BIT(31), /* gate */
> >> + 2, /* post-div */
> >> + 0);
> >> +
> >> +static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1",
> >> + mmc_default_parents, 0x08c,
> >> + 0, 4, /* M */
> >> + 16, 2, /* P */
> >> + 24, 2, /* mux */
> >> + BIT(31), /* gate */
> >> + 2, /* post-div */
> >> + 0);
> >> +
> >
> > Are you sure that the divider there for the non-eMMC clocks? Usually,
> > the new mode is only here for the eMMC, so we would divide the rate by
> > two in the non-eMMC case.
>
> The new mode is there for all MMC controllers. The other two MMC
> controllers even have the old/new timing mode switch. In case you
> forgot we have ".need_new_timings" set for the A64 compatible.
But then, shouldn't we model them as such, using the work you did on
the A83t clocks?
> But to eliminate any doubts or concerns, I've rerun tests for the
> micro SD card, instead of the eMMC. And yes the results are the same,
> 2x improvement (12 MB/s vs 23.7 MB/s).
Ok, good.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/7ab8a939/attachment.sig>
^ permalink raw reply
* [PATCH] perf: qcom_l2_pmu: don't allow guest access
From: Neil Leeder @ 2017-12-06 15:55 UTC (permalink / raw)
To: linux-arm-kernel
Guests cannot access IMPDEF system registers, which are used
by this driver. Disable the driver if it's running in a guest VM.
Signed-off-by: Neil Leeder <nleeder@codeaurora.org>
---
drivers/perf/qcom_l2_pmu.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/perf/qcom_l2_pmu.c b/drivers/perf/qcom_l2_pmu.c
index 4fdc848..49dc954 100644
--- a/drivers/perf/qcom_l2_pmu.c
+++ b/drivers/perf/qcom_l2_pmu.c
@@ -1057,6 +1057,10 @@ static int __init register_l2_cache_pmu_driver(void)
{
int err;
+ /* Don't enable driver if running as guest */
+ if (!is_hyp_mode_available())
+ return 0;
+
err = cpuhp_setup_state_multi(CPUHP_AP_PERF_ARM_QCOM_L2_ONLINE,
"AP_PERF_ARM_QCOM_L2_ONLINE",
l2cache_pmu_online_cpu,
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 4/9] ASoC: sun8i-codec: Add support for A64 SoC
From: Mark Brown @ 2017-12-06 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153205.k3l5sofdco3t75mi@flea.lan>
On Wed, Dec 06, 2017 at 04:32:05PM +0100, Maxime Ripard wrote:
> BCLK is sample rate * sample size * channels, and LRCK is running at
> the sample rate. So the ratio is the sample size * channels.
> Anything deviating from those standard i2s concepts should at least be
> documented, with arguments to back them off.
BCLK can be higher than the minimum there in most formats, though some
hardware is more restrictive so we tend to go for the minimum clock rate.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/b9d03659/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Lee Jones @ 2017-12-06 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206111008.3079-1-enric.balletbo@collabora.com>
On Wed, 06 Dec 2017, Enric Balletbo i Serra wrote:
> From: Benson Leung <bleung@chromium.org>
>
> Extend the driver to notify host and device type cables and the presence
> of power.
>
> Signed-off-by: Benson Leung <bleung@chromium.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
> drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
> include/linux/mfd/cros_ec_commands.h | 17 +++++
> 2 files changed, 155 insertions(+), 4 deletions(-)
[...]
> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
> index 2b16e95..c907353 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2904,16 +2904,33 @@ enum usb_pd_control_mux {
> USB_PD_CTRL_MUX_AUTO = 5,
> };
>
> +enum usb_pd_control_swap {
> + USB_PD_CTRL_SWAP_NONE = 0,
> + USB_PD_CTRL_SWAP_DATA = 1,
> + USB_PD_CTRL_SWAP_POWER = 2,
> + USB_PD_CTRL_SWAP_VCONN = 3,
> + USB_PD_CTRL_SWAP_COUNT
> +};
> +
> struct ec_params_usb_pd_control {
> uint8_t port;
> uint8_t role;
> uint8_t mux;
> + uint8_t swap;
> } __packed;
>
> #define PD_CTRL_RESP_ENABLED_COMMS (1 << 0) /* Communication enabled */
> #define PD_CTRL_RESP_ENABLED_CONNECTED (1 << 1) /* Device connected */
> #define PD_CTRL_RESP_ENABLED_PD_CAPABLE (1 << 2) /* Partner is PD capable */
>
> +#define PD_CTRL_RESP_ROLE_POWER (1 << 0) /* 0=SNK/1=SRC */
> +#define PD_CTRL_RESP_ROLE_DATA (1 << 1) /* 0=UFP/1=DFP */
> +#define PD_CTRL_RESP_ROLE_VCONN (1 << 2) /* Vconn status */
> +#define PD_CTRL_RESP_ROLE_DR_POWER (1 << 3) /* Partner is dualrole power */
> +#define PD_CTRL_RESP_ROLE_DR_DATA (1 << 4) /* Partner is dualrole data */
> +#define PD_CTRL_RESP_ROLE_USB_COMM (1 << 5) /* Partner USB comm capable */
> +#define PD_CTRL_RESP_ROLE_EXT_POWERED (1 << 6) /* Partner externally powerd */
Looks like the BIT() macro would serve you well here.
--
Lee Jones
Linaro Services Technical Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 04/18] arm64: alternatives: Enforce alignment of struct alt_instr
From: Marc Zyngier @ 2017-12-06 15:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206151856.GH28074@char.us.oracle.com>
On 06/12/17 15:18, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 06, 2017 at 02:57:29PM +0000, Marc Zyngier wrote:
>> On 06/12/17 14:48, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Dec 06, 2017 at 02:38:25PM +0000, Marc Zyngier wrote:
>>>> We're playing a dangerous game with struct alt_instr, as we produce
>>>> it using assembly tricks, but parse them using the C structure.
>>>> We just assume that the respective alignments of the two will
>>>> be the same.
>>>>
>>>> But as we add more fields to this structure, the alignment requirements
>>>> of the structure may change, and lead to all kind of funky bugs.
>>>>
>>>> TO solve this, let's move the definition of struct alt_instr to its
>>>> own file, and use this to generate the alignment constraint from
>>>> asm-offsets.c. The various macros are then patched to take the
>>>> alignment into account.
>>>
>>> Would it be better to use .p2align as on 32-bit ARM you must
>>> have it 4-byte aligned. Or at least have and BUILD_BUG_ON
>>> to make sure the size can be divided by four??
>>>
>>> Oh wait. You are not even touching ARM-32, how come? The alternative
>>> code can run on ARM-32 ...
>>
>> How? Given that I haven't written yet, I'd be grateful if you could
>> share your time machine...
>
> Oh! I assumed it would be there as the Xen variant runs on ARM-32 and
> it borrowed a bunch of code from Linux.
KVM definitely runs on 32bit, but doesn't have any alternative facility,
at least not in the way arm64 does.
> Please disregard my comment. I will go back to tweaking the time machine.
Let me know once you've debugged it, I have a couple of issues to
address in the past...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 10/37] KVM: arm64: Slightly improve debug save/restore functions
From: Julien Thierry @ 2017-12-06 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201151938.GA6615@lvm>
On 01/12/17 15:19, Christoffer Dall wrote:
> Hi Julien,
>
> On Tue, Nov 14, 2017 at 04:42:13PM +0000, Julien Thierry wrote:
>> On 12/10/17 11:41, Christoffer Dall wrote:
>>> The debug save/restore functions can be improved by using the has_vhe()
>>> static key instead of the instruction alternative. Using the static key
>>> uses the same paradigm as we're going to use elsewhere, it makes the
>>> code more readable, and it generates slightly better code (no
>>> stack setups and function calls unless necessary).
>>>
>>> We also use a static key on the restore path, because it will be
>>> marginally faster than loading a value from memory.
>>>
>>> Finally, we don't have to conditionally clear the debug dirty flag if
>>> it's set, we can just clear it.
>>>
>>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> ---
>>> arch/arm64/kvm/hyp/debug-sr.c | 22 +++++++++-------------
>>> 1 file changed, 9 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
>>> index 0fc0758..a2291b6 100644
>>> --- a/arch/arm64/kvm/hyp/debug-sr.c
>>> +++ b/arch/arm64/kvm/hyp/debug-sr.c
>>> @@ -75,11 +75,6 @@
>>> #define psb_csync() asm volatile("hint #17")
>>> -static void __hyp_text __debug_save_spe_vhe(u64 *pmscr_el1)
>>> -{
>>> - /* The vcpu can run. but it can't hide. */
>>> -}
>>> -
>>> static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
>>> {
>>> u64 reg;
>>> @@ -109,10 +104,6 @@ static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
>>> dsb(nsh);
>>> }
>>> -static hyp_alternate_select(__debug_save_spe,
>>> - __debug_save_spe_nvhe, __debug_save_spe_vhe,
>>> - ARM64_HAS_VIRT_HOST_EXTN);
>>> -
>>> static void __hyp_text __debug_restore_spe(u64 pmscr_el1)
>>> {
>>> if (!pmscr_el1)
>>> @@ -174,17 +165,22 @@ void __hyp_text __debug_cond_save_host_state(struct kvm_vcpu *vcpu)
>>> {
>>> __debug_save_state(vcpu, &vcpu->arch.host_debug_state.regs,
>>> kern_hyp_va(vcpu->arch.host_cpu_context));
>>> - __debug_save_spe()(&vcpu->arch.host_debug_state.pmscr_el1);
>>> +
>>> + /* Non-VHE: Disable and flush SPE data generation
>>> + * VHE: The vcpu can run. but it can't hide. */
>>> + if (!has_vhe())
>>> + __debug_save_spe_nvhe(&vcpu->arch.host_debug_state.pmscr_el1);
>>> }
>>> void __hyp_text __debug_cond_restore_host_state(struct kvm_vcpu *vcpu)
>>> {
>>> - __debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
>>> + if (!has_vhe())
>>> + __debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1);
>>
>> For consistency, would it be worth naming that function
>> '__debug_restore_spe_nvhe' ?
>
> Yes.
>
>>
>> Also, looking at __debug_save_spe_nvhe, I'm not sure how we guarantee that
>> we might not end up using stale data during the restore_spe (though, if this
>> is an issue, it existed before this change).
>> The save function might exit without setting a value to saved pmscr_el1.
>>
>> Basically I'm wondering if the following scenario (in non VHE) is possible
>> and/or whether it is problematic:
>>
>> - save spe
>> - restore spe
>> - host starts using spi -> !(PMBLIMITR_EL1 & PMBLIMITR_EL1_E)
>
> spi ?
spe*
>
>> - save spe -> returns early without setting pmscr_el1
>> - restore spe with old save instead of doing nothing
>>
>
> I think I see what you mean. Basically you're asking if we need this:
>
> diff --git a/arch/arm64/kvm/hyp/debug-sr.c b/arch/arm64/kvm/hyp/debug-sr.c
> index 4112160..8ab3510 100644
> --- a/arch/arm64/kvm/hyp/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/debug-sr.c
> @@ -106,7 +106,7 @@ static void __hyp_text __debug_save_spe_nvhe(u64 *pmscr_el1)
>
> static void __hyp_text __debug_restore_spe_nvhe(u64 &pmscr_el1)
> {
> - if (!pmscr_el1)
> + if (*pmscr_el1 != 0)
> return;
>
> /* The host page table is installed, but not yet synchronised */
> @@ -114,6 +114,7 @@ static void __hyp_text __debug_restore_spe_nvhe(u64 &pmscr_el1)
>
> /* Re-enable data generation */
> write_sysreg_s(pmscr_el1, PMSCR_EL1);
> + *pmscr_el1 = 0;
> }
>
> void __hyp_text __debug_save_state(struct kvm_vcpu *vcpu,
>
> I think we do, and I think this is a separate fix. Would you like to
> write a patch and cc Will and Marc (original author and committer) to
> fix this? Probably worth a cc stable as well.
>
Yes, this is what I was referring to. I agree it is a separate fix. I'll
make a patch for this.
Thanks,
--
Julien Thierry
^ permalink raw reply
* [PATCH 4/9] ASoC: sun8i-codec: Add support for A64 SoC
From: Maxime Ripard @ 2017-12-06 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVdZME2fiMw09NUP4DNCYhk58dqSapCdfBjLrdMq5HFwyg@mail.gmail.com>
On Tue, Dec 05, 2017 at 03:17:39PM -0800, Vasily Khoruzhick wrote:
> On Tue, Dec 5, 2017 at 12:04 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Sun, Dec 03, 2017 at 12:41:52PM -0800, Vasily Khoruzhick wrote:
> >> Digital part of audio codec block in the A64 is very similar to what
> >> is used by the A33(sun8i) devices. However, it uses different LRCK
> >> divider.
> >>
> >> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> >
> > What makes it impossible to derive from the sample rate and number of
> > channels?
>
> It's BCLK / LRCK ratio as per A64 user manual, so it doesn't depend on
> sample rate. BSP driver always uses a fixed value of 64 here.
Well, it kind of does.
BCLK is sample rate * sample size * channels, and LRCK is running at
the sample rate. So the ratio is the sample size * channels.
Anything deviating from those standard i2s concepts should at least be
documented, with arguments to back them off.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/20e46530/attachment.sig>
^ permalink raw reply
* [PATCH 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Stefan Agner @ 2017-12-06 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
Add support for the Computer on Module Colibri iMX7D 1GB along
with the Colibri Evaluation Board device trees. Follow the usual
hierarchic include model, maintaining shared configuration in
imx7-colibri.dtsi and imx7-colibri-eval-v3.dtsi respectively.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx7-colibri.dtsi | 64 +++++++++++++++++++++++-
arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts | 55 ++++++++++++++++++++
arch/arm/boot/dts/imx7d-colibri-emmc.dtsi | 57 +++++++++++++++++++++
arch/arm/boot/dts/imx7d-colibri.dtsi | 4 ++
5 files changed, 180 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
create mode 100644 arch/arm/boot/dts/imx7d-colibri-emmc.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b5ba7ad6ae30..9e4b4ecae572 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -519,6 +519,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ull-14x14-evk.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
imx7d-cl-som-imx7.dtb \
+ imx7d-colibri-emmc-eval-v3.dtb \
imx7d-colibri-eval-v3.dtb \
imx7d-nitrogen7.dtb \
imx7d-pico.dtb \
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index e1c6da0a65e4..4ea654a206e4 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -122,7 +122,6 @@
fsl,use-minimum-ecc;
nand-on-flash-bbt;
nand-ecc-mode = "hw";
- status = "okay";
};
&i2c1 {
@@ -312,6 +311,21 @@
vqmmc-supply = <®_LDO2>;
};
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ assigned-clocks = <&clks IMX7D_USDHC3_ROOT_CLK>;
+ assigned-clock-rates = <400000000>;
+ bus-width = <8>;
+ fsl,tuning-step = <2>;
+ max-frequency = <100000000>;
+ vmmc-supply = <®_module_3v3>;
+ vqmmc-supply = <®_DCDC3>;
+ non-removable;
+};
+
&iomuxc {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpio1 &pinctrl_gpio2 &pinctrl_gpio3 &pinctrl_gpio4>;
@@ -599,6 +613,54 @@
>;
};
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x59
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x19
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x59
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x59
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x59
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x59
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x59
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x59
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x59
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x59
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x19
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp_100mhz {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x5a
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x1a
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x5a
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x5a
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x5a
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x5a
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x5a
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x5a
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x5a
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x5a
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1a
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp_200mhz {
+ fsl,pins = <
+ MX7D_PAD_SD3_CMD__SD3_CMD 0x5b
+ MX7D_PAD_SD3_CLK__SD3_CLK 0x1b
+ MX7D_PAD_SD3_DATA0__SD3_DATA0 0x5b
+ MX7D_PAD_SD3_DATA1__SD3_DATA1 0x5b
+ MX7D_PAD_SD3_DATA2__SD3_DATA2 0x5b
+ MX7D_PAD_SD3_DATA3__SD3_DATA3 0x5b
+ MX7D_PAD_SD3_DATA4__SD3_DATA4 0x5b
+ MX7D_PAD_SD3_DATA5__SD3_DATA5 0x5b
+ MX7D_PAD_SD3_DATA6__SD3_DATA6 0x5b
+ MX7D_PAD_SD3_DATA7__SD3_DATA7 0x5b
+ MX7D_PAD_SD3_STROBE__SD3_STROBE 0x1b
+ >;
+ };
+
pinctrl_sai1: sai1-grp {
fsl,pins = <
MX7D_PAD_ENET1_RX_CLK__SAI1_TX_BCLK 0x1f
diff --git a/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
new file mode 100644
index 000000000000..5d5bb4c2843f
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 Toradex AG
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license,@your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx7d-colibri-emmc.dtsi"
+#include "imx7-colibri-eval-v3.dtsi"
+
+/ {
+ model = "Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3";
+ compatible = "toradex,colibri-imx7d-emmc-eval-v3",
+ "toradex,colibri-imx7d-emmc", "fsl,imx7d";
+};
+
+&usbotg2 {
+ vbus-supply = <®_usbh_vbus>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-colibri-emmc.dtsi b/arch/arm/boot/dts/imx7d-colibri-emmc.dtsi
new file mode 100644
index 000000000000..fce826895abb
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-colibri-emmc.dtsi
@@ -0,0 +1,57 @@
+/*
+ * Copyright 2017 Toradex AG
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx7d.dtsi"
+#include "imx7-colibri.dtsi"
+
+/ {
+ memory {
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+&usbotg2 {
+ dr_mode = "host";
+};
+
+&usdhc3 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx7d-colibri.dtsi b/arch/arm/boot/dts/imx7d-colibri.dtsi
index 3c2cb502b388..6f2bb70c1fbd 100644
--- a/arch/arm/boot/dts/imx7d-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7d-colibri.dtsi
@@ -49,6 +49,10 @@
};
};
+&gpmi {
+ status = "okay";
+};
+
&usbotg2 {
dr_mode = "host";
};
--
2.15.1
^ permalink raw reply related
* [PATCH 8/9] ARM: dts: imx7-colibri: add MCP2515 CAN controller
From: Stefan Agner @ 2017-12-06 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
The Colibri Evaluation Carrier Board provides a MCP2515 CAN
controller connected via SPI. Note that the i.MX 7 provides
an internal CAN controller which is much better suited for CAN
operations. Using the MCP2515 with a Colibri iMX7 module is
mainly useful to test the SPI interface.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 25 +++++++++++++++++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 14 +++++++++++++-
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 87c23b769a08..3d6c282dd258 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -45,6 +45,13 @@
stdout-path = "serial0:115200n8";
};
+ /* fixed crystal dedicated to mpc258x */
+ clk16m: clk16m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ };
+
panel: panel {
compatible = "edt,et057090dhu";
backlight = <&bl>;
@@ -99,6 +106,24 @@
status = "okay";
};
+&ecspi3 {
+ status = "okay";
+
+ mcp258x0: mcp258x at 0 {
+ compatible = "microchip,mcp2515";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can_int>;
+ reg = <0>;
+ clocks = <&clk16m>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <10000000>;
+ vdd-supply = <®_3v3>;
+ xceiver-supply = <®_5v0>;
+ status = "okay";
+ };
+};
+
&fec1 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 689ff6822634..e1c6da0a65e4 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -92,6 +92,13 @@
cpu-supply = <®_DCDC2>;
};
+&ecspi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
+ num-cs = <1>;
+ cs-gpios = <&gpio4 11 GPIO_ACTIVE_HIGH>;
+};
+
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
@@ -313,7 +320,6 @@
fsl,pins = <
MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x74 /* SODIMM 55 */
MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x74 /* SODIMM 63 */
- MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0x14 /* SODIMM 77 */
MX7D_PAD_EPDC_DATA09__GPIO2_IO9 0x14 /* SODIMM 89 */
MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x74 /* SODIMM 91 */
@@ -400,6 +406,12 @@
>;
};
+ pinctrl_can_int: can-int-grp {
+ fsl,pins = <
+ MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
+ >;
+ };
+
pinctrl_enet1: enet1grp {
fsl,pins = <
MX7D_PAD_ENET1_CRS__GPIO7_IO14 0x14
--
2.15.1
^ permalink raw reply related
* [PATCH 7/9] ARM: dts: imx7-colibri: specify backlight GPIO
From: Stefan Agner @ 2017-12-06 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
The Colibri standard defines SODIMM 71 as backlight enable
GPIO. Assign the GPIO to the backlight node in the module
level device tree.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index d623ef0f6e3e..689ff6822634 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -43,7 +43,10 @@
/ {
bl: backlight {
compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_bl_on>;
pwms = <&pwm1 0 5000000 0>;
+ enable-gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
};
reg_module_3v3: regulator-module-3v3 {
@@ -360,7 +363,6 @@
fsl,pins = <
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14 /* SODIMM 65 */
MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x74 /* SODIMM 69 */
- MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
MX7D_PAD_I2C4_SDA__GPIO4_IO15 0x14 /* SODIMM 75 */
MX7D_PAD_ECSPI1_MISO__GPIO4_IO18 0x14 /* SODIMM 79 */
MX7D_PAD_I2C3_SCL__GPIO4_IO12 0x14 /* SODIMM 81 */
@@ -436,6 +438,12 @@
>;
};
+ pinctrl_gpio_bl_on: gpio-bl-on {
+ fsl,pins = <
+ MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
+ >;
+ };
+
pinctrl_gpmi_nand: gpmi-nand-grp {
fsl,pins = <
MX7D_PAD_SD3_CLK__NAND_CLE 0x71
--
2.15.1
^ permalink raw reply related
* [PATCH 6/9] ARM: dts: imx7-colibri: specify usdhc1 supplies
From: Stefan Agner @ 2017-12-06 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
The usdhc1 controller instance is used to provide the default
SD/MMC capabilities of the Colibri standard. The IO pins are
supplied to the SoC on the module whereas the SD-card is powered
by the Carrier Board supply.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 1 +
arch/arm/boot/dts/imx7-colibri.dtsi | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 5ecb3a858c5a..87c23b769a08 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -158,5 +158,6 @@
&usdhc1 {
keep-power-in-suspend;
wakeup-source;
+ vmmc-supply = <®_3v3>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 6498c1136ef1..d623ef0f6e3e 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -299,6 +299,7 @@
no-1-8-v;
cd-gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;
disable-wp;
+ vqmmc-supply = <®_LDO2>;
};
&iomuxc {
--
2.15.1
^ permalink raw reply related
* [PATCH 5/9] ARM: dts: imx7-colibri: specify cpu-supply
From: Stefan Agner @ 2017-12-06 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
Specify CPU supply using the "cpu-supply" property instead of
the invalid "arm-supply" property.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index f61041af026a..6498c1136ef1 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -86,7 +86,7 @@
};
&cpu0 {
- arm-supply = <®_DCDC2>;
+ cpu-supply = <®_DCDC2>;
};
&fec1 {
--
2.15.1
^ permalink raw reply related
* [PATCH 4/9] ARM: dts: imx7-colibri: use NAND_CE1 as GPIO
From: Stefan Agner @ 2017-12-06 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
All Colibri iMX7 SKUs use either single-die NAND or eMMC, hence
NAND_CE1 is not used on the module and can be used as a GPIO by
carrier boards.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index e4e32aa786f4..f61041af026a 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -329,6 +329,7 @@
MX7D_PAD_EPDC_SDCE2__GPIO2_IO22 0x14 /* SODIMM 127 */
MX7D_PAD_UART3_RTS_B__GPIO4_IO6 0x14 /* SODIMM 131 */
MX7D_PAD_EPDC_GDRL__GPIO2_IO26 0x14 /* SODIMM 133 */
+ MX7D_PAD_SAI1_RX_DATA__GPIO6_IO12 0x14 /* SODIMM 169 */
MX7D_PAD_SAI1_RX_BCLK__GPIO6_IO17 0x14 /* SODIMM 24 */
MX7D_PAD_SD2_DATA2__GPIO5_IO16 0x14 /* SODIMM 100 */
MX7D_PAD_SD2_DATA3__GPIO5_IO17 0x14 /* SODIMM 102 */
@@ -439,7 +440,6 @@
MX7D_PAD_SD3_CLK__NAND_CLE 0x71
MX7D_PAD_SD3_CMD__NAND_ALE 0x71
MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B 0x71
- MX7D_PAD_SAI1_RX_DATA__NAND_CE1_B 0x71
MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
MX7D_PAD_SD3_STROBE__NAND_RE_B 0x71
MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
--
2.15.1
^ permalink raw reply related
* [PATCH 3/9] ARM: dts: imx7-colibri: mux pull-ups where appropriate
From: Stefan Agner @ 2017-12-06 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
Use pull-ups instead of pull-downs for the pins which are already
pulled-up externally.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index dae6b561145b..e4e32aa786f4 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -307,17 +307,17 @@
pinctrl_gpio1: gpio1-grp {
fsl,pins = <
- MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x14 /* SODIMM 55 */
- MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x14 /* SODIMM 63 */
+ MX7D_PAD_ENET1_RGMII_RD3__GPIO7_IO3 0x74 /* SODIMM 55 */
+ MX7D_PAD_ENET1_RGMII_RD2__GPIO7_IO2 0x74 /* SODIMM 63 */
MX7D_PAD_SD1_RESET_B__GPIO5_IO2 0X14 /* SODIMM 73 */
- MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0X14 /* SODIMM 77 */
+ MX7D_PAD_SAI1_RX_SYNC__GPIO6_IO16 0x14 /* SODIMM 77 */
MX7D_PAD_EPDC_DATA09__GPIO2_IO9 0x14 /* SODIMM 89 */
- MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x14 /* SODIMM 91 */
+ MX7D_PAD_EPDC_DATA08__GPIO2_IO8 0x74 /* SODIMM 91 */
MX7D_PAD_LCD_RESET__GPIO3_IO4 0x14 /* SODIMM 93 */
MX7D_PAD_EPDC_DATA13__GPIO2_IO13 0x14 /* SODIMM 95 */
MX7D_PAD_ENET1_RGMII_TXC__GPIO7_IO11 0x14 /* SODIMM 99 */
- MX7D_PAD_EPDC_DATA10__GPIO2_IO10 0x14 /* SODIMM 105 */
- MX7D_PAD_EPDC_DATA15__GPIO2_IO15 0x14 /* SODIMM 107 */
+ MX7D_PAD_EPDC_DATA10__GPIO2_IO10 0x74 /* SODIMM 105 */
+ MX7D_PAD_EPDC_DATA15__GPIO2_IO15 0x74 /* SODIMM 107 */
MX7D_PAD_EPDC_DATA00__GPIO2_IO0 0x14 /* SODIMM 111 */
MX7D_PAD_EPDC_DATA01__GPIO2_IO1 0x14 /* SODIMM 113 */
MX7D_PAD_EPDC_DATA02__GPIO2_IO2 0x14 /* SODIMM 115 */
@@ -333,7 +333,7 @@
MX7D_PAD_SD2_DATA2__GPIO5_IO16 0x14 /* SODIMM 100 */
MX7D_PAD_SD2_DATA3__GPIO5_IO17 0x14 /* SODIMM 102 */
MX7D_PAD_EPDC_GDSP__GPIO2_IO27 0x14 /* SODIMM 104 */
- MX7D_PAD_EPDC_BDR0__GPIO2_IO28 0x14 /* SODIMM 106 */
+ MX7D_PAD_EPDC_BDR0__GPIO2_IO28 0x74 /* SODIMM 106 */
MX7D_PAD_EPDC_BDR1__GPIO2_IO29 0x14 /* SODIMM 110 */
MX7D_PAD_EPDC_PWR_COM__GPIO2_IO30 0x14 /* SODIMM 112 */
MX7D_PAD_EPDC_SDCLK__GPIO2_IO16 0x14 /* SODIMM 114 */
@@ -357,7 +357,7 @@
pinctrl_gpio2: gpio2-grp { /* On X22 Camera interface */
fsl,pins = <
MX7D_PAD_ECSPI2_SS0__GPIO4_IO23 0x14 /* SODIMM 65 */
- MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x14 /* SODIMM 69 */
+ MX7D_PAD_SD1_CD_B__GPIO5_IO0 0x74 /* SODIMM 69 */
MX7D_PAD_SD1_WP__GPIO5_IO1 0x14 /* SODIMM 71 */
MX7D_PAD_I2C4_SDA__GPIO4_IO15 0x14 /* SODIMM 75 */
MX7D_PAD_ECSPI1_MISO__GPIO4_IO18 0x14 /* SODIMM 79 */
@@ -378,8 +378,8 @@
MX7D_PAD_LCD_DATA19__GPIO3_IO24 0x14 /* SODIMM 138 */
MX7D_PAD_LCD_DATA20__GPIO3_IO25 0x14 /* SODIMM 140 */
MX7D_PAD_LCD_DATA21__GPIO3_IO26 0x14 /* SODIMM 142 */
- MX7D_PAD_LCD_DATA22__GPIO3_IO27 0x14 /* SODIMM 146 */
- MX7D_PAD_LCD_DATA23__GPIO3_IO28 0x14 /* SODIMM 148 */
+ MX7D_PAD_LCD_DATA22__GPIO3_IO27 0x74 /* SODIMM 144 */
+ MX7D_PAD_LCD_DATA23__GPIO3_IO28 0x74 /* SODIMM 146 */
>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH 2/9] ARM: dts: imx7-colibri: make sure multiplexed pins are not active
From: Stefan Agner @ 2017-12-06 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206153005.6144-1-stefan@agner.ch>
The Colibri pins PWM<A> and <D> are multiplexed on the module, make
sure the secondary SoC pin is not active.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index 60ea7557d8c9..dae6b561145b 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -507,6 +507,7 @@
pinctrl_pwm1: pwm1-grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO08__PWM1_OUT 0x79
+ MX7D_PAD_ECSPI2_MOSI__GPIO4_IO21 0x4
>;
};
@@ -525,6 +526,7 @@
pinctrl_pwm4: pwm4-grp {
fsl,pins = <
MX7D_PAD_GPIO1_IO11__PWM4_OUT 0x79
+ MX7D_PAD_ECSPI2_SCLK__GPIO4_IO20 0x4
>;
};
--
2.15.1
^ permalink raw reply related
* [PATCH 1/9] ARM: dts: imx7-colibri: move and rename USB Host power regulator
From: Stefan Agner @ 2017-12-06 15:29 UTC (permalink / raw)
To: linux-arm-kernel
The Colibri default which enables USB Host power is not necessarily
tied to the OTG2 controller, some carrier board use the pin to
control USB power for both controllers. Hence name the pinctrl
group more generic.
Also move the regulator to the generic eval-v3 device tree since
the regulator is always on the carrier board. In the Colibri iMX7S
case the regulator is just not used. This allows to reuse the
regulator in a upcoming SKU Colibri iMX7D 1GB with eMMC.
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi | 11 +++++++++++
arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
arch/arm/boot/dts/imx7d-colibri-eval-v3.dts | 13 +------------
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
index 18bebd6d8d47..5ecb3a858c5a 100644
--- a/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi
@@ -70,6 +70,17 @@
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
};
+
+ reg_usbh_vbus: regulator-usbh-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh_reg>;
+ regulator-name = "VCC_USB[1-4]";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 7 GPIO_ACTIVE_LOW>;
+ vin-supply = <®_5v0>;
+ };
};
&bl {
diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
index bb5bf94f1a32..60ea7557d8c9 100644
--- a/arch/arm/boot/dts/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/imx7-colibri.dtsi
@@ -559,7 +559,7 @@
>;
};
- pinctrl_usbotg2_reg: gpio-usbotg2-vbus {
+ pinctrl_usbh_reg: gpio-usbh-vbus {
fsl,pins = <
MX7D_PAD_UART3_CTS_B__GPIO4_IO7 0x14 /* SODIMM 129 USBH PEN */
>;
diff --git a/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts b/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
index a608a14d8c85..136e11ab4893 100644
--- a/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
+++ b/arch/arm/boot/dts/imx7d-colibri-eval-v3.dts
@@ -48,20 +48,9 @@
model = "Toradex Colibri iMX7D on Colibri Evaluation Board V3";
compatible = "toradex,colibri-imx7d-eval-v3", "toradex,colibri-imx7d",
"fsl,imx7d";
-
- reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_usbotg2_reg>;
- regulator-name = "VCC_USB[1-4]";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio4 7 GPIO_ACTIVE_LOW>;
- vin-supply = <®_5v0>;
- };
};
&usbotg2 {
- vbus-supply = <®_usb_otg2_vbus>;
+ vbus-supply = <®_usbh_vbus>;
status = "okay";
};
--
2.15.1
^ permalink raw reply related
* [PATCH 2/9] ASoC: sun4i-i2s: Add compatibility with A64 codec I2S
From: Maxime Ripard @ 2017-12-06 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVeZtWqLZddHtZMv264bWaVcReToYqkriYryf+wZnUVtCA@mail.gmail.com>
On Tue, Dec 05, 2017 at 03:04:19PM -0800, Vasily Khoruzhick wrote:
> On Tue, Dec 5, 2017 at 12:01 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Sun, Dec 03, 2017 at 11:34:06PM -0800, Vasily Khoruzhick wrote:
> >> I'd keep it sun50i_a64_acodec_i2s, since other 3 I2S modules aren't
> >> compatible with this one, but similar to H3.
> >
> > Please don't top-post.
> >
> > What are those differences?
>
> Different registers and their locations. Compare quirks for
> sun50i_a64_acodec_i2s and sun8i_h3_i2s fro details.
Whatever differences should also be mentionned in your commit log.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/77ec3a6e/attachment.sig>
^ permalink raw reply
* [PATCH] drm/sun4i: Fix uninitialized variables in vi layer
From: Jernej Skrabec @ 2017-12-06 15:26 UTC (permalink / raw)
To: linux-arm-kernel
min_scale and max_scale in sun8i_vi_layer_atomic_check() can be used
without initialization.
Fix that.
Fixes: b862a648de3b (drm/sun4i: Add support for HW scaling to DE2)
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
index e39af8d377d0..40c3b303068a 100644
--- a/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_vi_layer.c
@@ -253,6 +253,9 @@ static int sun8i_vi_layer_atomic_check(struct drm_plane *plane,
clip.x2 = crtc_state->adjusted_mode.hdisplay;
clip.y2 = crtc_state->adjusted_mode.vdisplay;
+ min_scale = DRM_PLANE_HELPER_NO_SCALING;
+ max_scale = DRM_PLANE_HELPER_NO_SCALING;
+
if (layer->mixer->cfg->scaler_mask & BIT(layer->channel)) {
min_scale = SUN8I_VI_SCALER_SCALE_MIN;
max_scale = SUN8I_VI_SCALER_SCALE_MAX;
--
2.15.1
^ permalink raw reply related
* [PATCH] spi: sun4i: disable clocks in the remove function
From: Takuo Koguchi @ 2017-12-06 15:22 UTC (permalink / raw)
To: linux-arm-kernel
mclk and hclk need to be disabled explicitly since pm_runtime_disable does
not disable the clocks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Takuo Koguchi <takuo.koguchi.sw@hitachi.com>
---
drivers/spi/spi-sun4i.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index c5cd635..9011c09 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -525,6 +525,11 @@ static int sun4i_spi_probe(struct platform_device *pdev)
static int sun4i_spi_remove(struct platform_device *pdev)
{
+ struct spi_master *master = dev_get_drvdata(&pdev->dev);
+ struct sun4i_spi *sspi = spi_master_get_devdata(master);
+
+ clk_disable_unprepare(sspi->mclk);
+ clk_disable_unprepare(sspi->hclk);
pm_runtime_disable(&pdev->dev);
return 0;
--
2.7.4
^ permalink raw reply related
* [RFC] spi: sun6i: disable/unprepare clocks on remove
From: Maxime Ripard @ 2017-12-06 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206125028.fqzmy354tgf7afis@agrajag.zerfleddert.de>
Hi Tobias,
On Wed, Dec 06, 2017 at 01:50:29PM +0100, Tobias Jordan wrote:
> sun6i_spi_probe() uses sun6i_spi_runtime_resume() to prepare/enable clocks,
> so sun6i_spi_remove() should use sun6i_spi_runtime_suspend() to
> disable/unprepare them.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Fixes: 3558fe900e8af spi: sunxi: Add Allwinner A31 SPI controller driver
> Signed-off-by: Tobias Jordan <Tobias.Jordan@elektrobit.com>
> ---
> This was found by LDV, and it looks very suspicious to me, but I'm not
> sure if the fix is that easy. Is suspend() called automatically when the
> driver is removed? If not, is it correct to unconditionally call
> suspend(), or should there be a check for the PM state instead?
>
> drivers/spi/spi-sun6i.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
> index fb38234249a8..5e5df09e5d04 100644
> --- a/drivers/spi/spi-sun6i.c
> +++ b/drivers/spi/spi-sun6i.c
> @@ -541,6 +541,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
>
> static int sun6i_spi_remove(struct platform_device *pdev)
> {
> + sun6i_spi_runtime_suspend(&pdev->dev);
Yeah, that's not ideal. The best solution would be to call
pm_runtime_force_suspend I guess.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/812de598/attachment.sig>
^ permalink raw reply
* [RFC PATCH 2/5] perf jevents: add support for arch recommended events
From: John Garry @ 2017-12-06 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171206133607.GA12508@krava>
On 06/12/2017 13:36, Jiri Olsa wrote:
> On Wed, Dec 06, 2017 at 12:13:16AM +0800, John Garry wrote:
>> For some architectures (like arm64), there are architecture-
>> defined recommended events. Vendors may not be obliged to
>> follow the recommendation and may implement their own pmu
>> event for a specific event code.
>>
>> This patch adds support for parsing events from arch-defined
>> recommended JSONs, and then fixing up vendor events when
>> they have implemented these events as recommended.
>
> in the previous patch you added the vendor support, so
> you have arch|vendor|platform key for the event list
> and perf have the most current/local event list
>
> why would you need to fix it? if there's new event list,
> the table gets updated, perf is rebuilt.. I'm clearly
> missing something ;-)
The 2 patches are quite separate. In the first patch, I just added
support for the vendor subdirectory.
So this patch is not related to rebuilding when adding a new event list
or dependency checking.
Here we are trying to allow the vendor to just specify that an event is
supported as standard in their platform, without duplicating all the
standard event fields in their JSON. When processing the vendor JSONs,
the jevents tool can figure which events are standard and create the
proper event entries in the pmu events table, referencing the
architecture JSON.
>
>> In the vendor JSON, to specify that the event is supported
>> according to the recommendation, only the event code is
>> added to the JSON entry - no other event elements need be
>> added, like below:
>> [
>> {
>> "EventCode": "0x40",
>> },
>>
>> ]
>>
>> The pmu event parsing will check for "BriefDescription"
>> field presence only for this.
>>
>> If "BriefDescription" is present, then it is implied
>> that the vendor has implemented their own custom event,
>> and there is no fixup. Other fields are ignored.
>
> if we are going this way, please use some new token,
> this list is supposed to be human readable
A new token could work also, but it would be just a flag to mark the
event "standard".
Ideally we could reference another entry in another JSON, like a
pointer, but I don't think that this is possible with JSONs; not unless
we introduce some elaborate custom scheme to allow JSONs to be
cross-referenced.
Cheers,
John
>
> thanks,
> jirka
>
> .
>
^ permalink raw reply
* [PATCH] spi: sun4i: disable clocks in the remove function
From: Maxime Ripard @ 2017-12-06 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512573752-13091-1-git-send-email-takuo.koguchi.sw@hitachi.com>
Hi,
On Thu, Dec 07, 2017 at 12:22:13AM +0900, Takuo Koguchi wrote:
> mclk and hclk need to be disabled explicitly since pm_runtime_disable does
> not disable the clocks.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Takuo Koguchi <takuo.koguchi.sw@hitachi.com>
> ---
> drivers/spi/spi-sun4i.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
> index c5cd635..9011c09 100644
> --- a/drivers/spi/spi-sun4i.c
> +++ b/drivers/spi/spi-sun4i.c
> @@ -525,6 +525,11 @@ static int sun4i_spi_probe(struct platform_device *pdev)
>
> static int sun4i_spi_remove(struct platform_device *pdev)
> {
> + struct spi_master *master = dev_get_drvdata(&pdev->dev);
> + struct sun4i_spi *sspi = spi_master_get_devdata(master);
> +
> + clk_disable_unprepare(sspi->mclk);
> + clk_disable_unprepare(sspi->hclk);
And that will in turn create an unbalanced disable call if suspend was
called before the remove, which is very likely.
Why are you not calling pm_runtime_force_suspend? How did you test
that patch?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171206/abb6347c/attachment.sig>
^ permalink raw reply
* [PATCH 04/18] arm64: alternatives: Enforce alignment of struct alt_instr
From: Konrad Rzeszutek Wilk @ 2017-12-06 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd8995ce-3065-3aba-2d93-9ed91de5cd50@arm.com>
On Wed, Dec 06, 2017 at 02:57:29PM +0000, Marc Zyngier wrote:
> On 06/12/17 14:48, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 06, 2017 at 02:38:25PM +0000, Marc Zyngier wrote:
> >> We're playing a dangerous game with struct alt_instr, as we produce
> >> it using assembly tricks, but parse them using the C structure.
> >> We just assume that the respective alignments of the two will
> >> be the same.
> >>
> >> But as we add more fields to this structure, the alignment requirements
> >> of the structure may change, and lead to all kind of funky bugs.
> >>
> >> TO solve this, let's move the definition of struct alt_instr to its
> >> own file, and use this to generate the alignment constraint from
> >> asm-offsets.c. The various macros are then patched to take the
> >> alignment into account.
> >
> > Would it be better to use .p2align as on 32-bit ARM you must
> > have it 4-byte aligned. Or at least have and BUILD_BUG_ON
> > to make sure the size can be divided by four??
> >
> > Oh wait. You are not even touching ARM-32, how come? The alternative
> > code can run on ARM-32 ...
>
> How? Given that I haven't written yet, I'd be grateful if you could
> share your time machine...
Oh! I assumed it would be there as the Xen variant runs on ARM-32 and
it borrowed a bunch of code from Linux.
Please disregard my comment. I will go back to tweaking the time machine.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 3/3] ARM: dts: imx6sl-evk: Convert from fbdev to drm bindings
From: Marco Franchi @ 2017-12-06 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512573319-6624-1-git-send-email-marcofrk@gmail.com>
It is preferred to use the panel compatible string rather than passing
the LCD timing in the device tree.
So pass the "sii,43wvf1g" compatible string which describes the parallel
LCD.
Also, pass the 'backlight' property as described in
Documentation/devicetree/bindings/display/panel/simple-panel.txt
Signed-off-by: Marco Franchi <marco.franchi@nxp.com>
---
Changes since v2:
-none
arch/arm/boot/dts/imx6sl-evk.dts | 48 ++++++++++++++++++++--------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index c9114cc..2844ab5 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -20,7 +20,7 @@
reg = <0x80000000 0x40000000>;
};
- backlight {
+ backlight_display: backlight_display {
compatible = "pwm-backlight";
pwms = <&pwm1 0 5000000>;
brightness-levels = <0 4 8 16 32 64 128 255>;
@@ -82,6 +82,13 @@
enable-active-high;
};
+ reg_lcd_5v: regulator-lcd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd-5v0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
sound {
compatible = "fsl,imx6sl-evk-wm8962", "fsl,imx-audio-wm8962";
model = "wm8962-audio";
@@ -97,6 +104,19 @@
mux-int-port = <2>;
mux-ext-port = <3>;
};
+
+ panel {
+ compatible = "sii,43wvf1g";
+ backlight = <&backlight_display>;
+ dvdd-supply = <®_lcd_3v3>;
+ avdd-supply = <®_lcd_5v>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
};
&audmux {
@@ -535,31 +555,11 @@
&lcdif {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcd>;
- lcd-supply = <®_lcd_3v3>;
- display = <&display0>;
status = "okay";
- display0: display0 {
- bits-per-pixel = <32>;
- bus-width = <24>;
-
- display-timings {
- native-mode = <&timing0>;
- timing0: timing0 {
- clock-frequency = <33500000>;
- hactive = <800>;
- vactive = <480>;
- hback-porch = <89>;
- hfront-porch = <164>;
- vback-porch = <23>;
- vfront-porch = <10>;
- hsync-len = <10>;
- vsync-len = <10>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ port {
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] ARM: dts: imx6sl-evk: Rearrange the regulators node
From: Marco Franchi @ 2017-12-06 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512573319-6624-1-git-send-email-marcofrk@gmail.com>
It is not recommended to place regulators inside "simple-bus", so move
them out.
The motivation for doing this is to make it easier to adding new
regulators.
Signed-off-by: Marco Franchi <marcofrk@gmail.com>
---
Changes since v2:
-include GPIO_ACTIVE_HIGH instead of numerical values
arch/arm/boot/dts/imx6sl-evk.dts | 85 +++++++++++++++++-----------------------
1 file changed, 37 insertions(+), 48 deletions(-)
diff --git a/arch/arm/boot/dts/imx6sl-evk.dts b/arch/arm/boot/dts/imx6sl-evk.dts
index 60600b4..c9114cc 100644
--- a/arch/arm/boot/dts/imx6sl-evk.dts
+++ b/arch/arm/boot/dts/imx6sl-evk.dts
@@ -39,58 +39,47 @@
};
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reg_usb_otg1_vbus: regulator at 0 {
- compatible = "regulator-fixed";
- reg = <0>;
- regulator-name = "usb_otg1_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio4 0 0>;
- enable-active-high;
- vin-supply = <&swbst_reg>;
- };
+ reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&swbst_reg>;
+ };
- reg_usb_otg2_vbus: regulator at 1 {
- compatible = "regulator-fixed";
- reg = <1>;
- regulator-name = "usb_otg2_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- gpio = <&gpio4 2 0>;
- enable-active-high;
- vin-supply = <&swbst_reg>;
- };
+ reg_usb_otg2_vbus: regulator-usb-otg2-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg2_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&swbst_reg>;
+ };
- reg_aud3v: regulator at 2 {
- compatible = "regulator-fixed";
- reg = <2>;
- regulator-name = "wm8962-supply-3v15";
- regulator-min-microvolt = <3150000>;
- regulator-max-microvolt = <3150000>;
- regulator-boot-on;
- };
+ reg_aud3v: regulator-aud3v {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8962-supply-3v15";
+ regulator-min-microvolt = <3150000>;
+ regulator-max-microvolt = <3150000>;
+ regulator-boot-on;
+ };
- reg_aud4v: regulator at 3 {
- compatible = "regulator-fixed";
- reg = <3>;
- regulator-name = "wm8962-supply-4v2";
- regulator-min-microvolt = <4325000>;
- regulator-max-microvolt = <4325000>;
- regulator-boot-on;
- };
+ reg_aud4v: regulator-aud4v {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8962-supply-4v2";
+ regulator-min-microvolt = <4325000>;
+ regulator-max-microvolt = <4325000>;
+ regulator-boot-on;
+ };
- reg_lcd_3v3: regulator at 4 {
- compatible = "regulator-fixed";
- reg = <4>;
- regulator-name = "lcd-3v3";
- gpio = <&gpio4 3 0>;
- enable-active-high;
- };
+ reg_lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd-3v3";
+ gpio = <&gpio4 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
};
sound {
--
2.7.4
^ 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