* [PATCH 2/6] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: Gabriel Fernandez @ 2016-11-07 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <45a332b6-5170-9ae3-8d5e-c5f827c3edea@linaro.org>
Hi Daniel,
On 11/07/2016 02:55 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
>> from pll-sai-p.
>>
>> The SDIO clock could be also derived from 48Mhz or from sys clock.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 18 +++++++++++++++++-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index 7641acd..dda15bc 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -199,7 +199,7 @@ struct stm32f4_gate_data {
>> { STM32F4_RCC_APB2ENR, 8, "adc1", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 9, "adc2", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 10, "adc3", "apb2_div" },
>> - { STM32F4_RCC_APB2ENR, 11, "sdio", "pll48" },
>> + { STM32F4_RCC_APB2ENR, 11, "sdio", "sdmux" },
>
> I'm confused. How do the "sdmux" clock come to exist on STM32F429?
>
"sdmux" only exist on STM32F469 (struct stm32f4_gate_data stm32f469_gates[])
BR
Gabriel
>
>> { STM32F4_RCC_APB2ENR, 12, "spi1", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 13, "spi4", "apb2_div" },
>> { STM32F4_RCC_APB2ENR, 14, "syscfg", "apb2_div" },
>> @@ -940,6 +940,10 @@ static struct clk_hw *stm32_register_cclk(struct
>> device *dev, const char *name,
>> "no-clock", "lse", "lsi", "hse-rtc"
>> };
>>
>> +static const char *pll48_parents[2] = { "pll-q", "pllsai-p" };
>> +
>> +static const char *sdmux_parents[2] = { "pll48", "sys" };
>> +
>> struct stm32f4_clk_data {
>> const struct stm32f4_gate_data *gates_data;
>> const u64 *gates_map;
>> @@ -1109,6 +1113,18 @@ static void __init stm32f4_rcc_init(struct
>> device_node *np)
>> goto fail;
>> }
>>
>> + if (of_device_is_compatible(np, "st,stm32f469-rcc")) {
>> + clk_hw_register_mux_table(NULL, "pll48",
>> + pll48_parents, ARRAY_SIZE(pll48_parents), 0,
>> + base + STM32F4_RCC_DCKCFGR, 27, 1, 0, NULL,
>> + &stm32f4_clk_lock);
>> +
>> + clk_hw_register_mux_table(NULL, "sdmux",
>> + sdmux_parents, ARRAY_SIZE(sdmux_parents), 0,
>> + base + STM32F4_RCC_DCKCFGR, 28, 1, 0, NULL,
>> + &stm32f4_clk_lock);
>> + }
>> +
>> of_clk_add_hw_provider(np, stm32f4_rcc_lookup_clk, NULL);
>> return;
>> fail:
>>
>
^ permalink raw reply
* [PATCH] ARM: tegra: nyan: Mark all USB ports as host
From: Jon Hunter @ 2016-11-07 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107132854.GF12559@ulmo.ba.sec>
On 07/11/16 13:28, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Sun, Sep 18, 2016 at 12:28:52PM +0200, Paul Kocialkowski wrote:
>> Nyan boards only have host USB ports (2 external, 1 internal), there is
>> no OTG-enabled connector.
>>
>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>> ---
>> arch/arm/boot/dts/tegra124-nyan.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Where is this information coming from? I don't have one of the Nyans
> myself, but one of the Tegra132 devices I have, which I think was
> derived from one of the Nyans uses one of the external host ports as
> forced recovery port, for which it would need OTG.
>
> I suspect that the way to get U-Boot onto the Nyans is via tegrarcm?
> In that case I think one of the ports must be OTG.
It is true that the port on the back on the nyan-big can be used with
recovery mode. I was thinking that this is not a true OTG port as it is
just a 4-pin type A socket and does not have an ID pin. Thinking some
more about this the USB spec does include a "Host Negotiation Protocol
(HNP)" that allows a host and device to swap roles and so keeping it as
OTG seems valid afterall.
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH 3/3] ARM: gr8: evb: Add i2s codec
From: Chen-Yu Tsai @ 2016-11-07 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4d99da31af41b26d9109113e19223ee8b88f76ae.1478524066.git-series.maxime.ripard@free-electrons.com>
On Mon, Nov 7, 2016 at 9:08 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The GR8-EVB comes with a wm8978 codec connected to the i2s bus.
>
> Add a card in order to have it working
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm/boot/dts/ntc-gr8-evb.dts | 14 ++++++++++++++
> 1 file changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/ntc-gr8-evb.dts b/arch/arm/boot/dts/ntc-gr8-evb.dts
> index 12b4317a4383..5291e425caf9 100644
> --- a/arch/arm/boot/dts/ntc-gr8-evb.dts
> +++ b/arch/arm/boot/dts/ntc-gr8-evb.dts
> @@ -76,6 +76,20 @@
> default-brightness-level = <8>;
> };
>
> + i2s {
"sound" might be a better node name? The I2S controllers are also named "i2s".
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "gr8-evb-wm8978";
> + simple-audio-card,format = "i2s";
> + simple-audio-card,mclk-fs = <512>;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s0>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <&wm8978>;
> + };
> + };
>
> panel {
> compatible = "allwinner,sun4i-a10-sub-evb-5-lcd";
> --
> git-series 0.8.11
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Maxime Ripard @ 2016-11-07 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEqLBRknDAKQu1641BEd_MKe42hYx+Jz8FcASZvC1dn6+yazxg@mail.gmail.com>
Hi Sean,
On Thu, Nov 03, 2016 at 03:11:26PM -0600, Sean Paul wrote:
> On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi Russell,
> >
> > On Mon, Oct 31, 2016 at 08:42:34AM +0000, Russell King - ARM Linux wrote:
> >> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> >> > The first one is that this overscanning should be reported by the
> >> > connector I guess? but this is really TV specific, so we need one way
> >> > to let the user tell how the image is displayed on its side, and we
> >> > cannot really autodetect it, and this needs to be done at runtime so
> >> > that we can present some shiny interface to let it select which
> >> > overscan ratio works for him/her.
> >>
> >> See xbmc... they go through a nice shiny setup which includes adjusting
> >> the visible area. From what I remember, it has pointers on each corner
> >> which you can adjust to be just visible on the screen, so xbmc knows
> >> how much overscan there is, and xbmc itself reduces down to the user
> >> set size.
> >
> > Yes. And that is an XBMC only solution, that doesn't work with the
> > fbdev emulation and is probably doing an additional composition to
> > scale down and center their frames through OpenGL.
> >
> > We might not have a GPU in the system, and we might not even have an
> > entire graphic stack on top either, so I don't think fixing at the
> > user-space level is a good option (especially since we already have an
> > overscan property in DRM).
> >
>
> Hi Maxime,
> I took a quick look at the first 2 patches in the series and they look
> good at first glance. I have them in my queue to review more
> carefully.
Yes, the first one is pretty scary.
If it can ease your review, I made a bunch of unittests to test that
code. It's pretty hacky (basically a copy of some kernel structures
and the new logic to parse the command line), but it should test it
with a significant number of cases:
http://code.bulix.org/4lnlk7-107122?raw
It's pretty straightforward to compile, you just have to link against
cmocka.
> Can you explain why you can't fix this by specifying a new mode with
> big porches (as Russell suggested)?
I'll reply to his mail.
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/f6460e69/attachment.sig>
^ permalink raw reply
* [PATCH 3/6] clk: stm32f4: Add post divisor for I2S & SAI PLLs and Add lcd-tft clock
From: Gabriel Fernandez @ 2016-11-07 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <860ce6a2-066f-2b44-3cf5-2d73720ed588@linaro.org>
Hi Daniel,
On 11/07/2016 02:58 PM, Daniel Thompson wrote:
> On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>
>> This patch adds post dividers of I2S & SAI PLLs.
>> These dividers are managed by a dedicated register (RCC_DCKCFGR).
>> The PLL should be off before a set rate.
>> This patch also introduces the lcd-tft clock.
>>
>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>> ---
>> drivers/clk/clk-stm32f4.c | 27 +++++++++++++++++++++++++--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
>> index dda15bc..5fa5d51 100644
>> --- a/drivers/clk/clk-stm32f4.c
>> +++ b/drivers/clk/clk-stm32f4.c
>> @@ -215,6 +215,7 @@ struct stm32f4_gate_data {
>> enum {
>> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
>> PLL_VCO_I2S, PLL_VCO_SAI,
>> + CLK_LCD,
>> END_PRIMARY_CLK
>> };
>>
>> @@ -599,6 +600,9 @@ static struct clk_hw *clk_register_pll_div(const
>> char *name,
>> static const struct clk_div_table pll_divp_table[] = {
>> { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 },
>> };
>> +static const struct clk_div_table pll_lcd_div_table[] = {
>> + { 0, 2 }, { 1, 4 }, { 2, 8 }, { 3, 16 },
>> +};
>>
>> /*
>> * Decode current PLL state and (statically) model the state we
>> inherit from
>> @@ -659,16 +663,35 @@ static struct clk_hw
>> *stm32f4_rcc_register_pll(const char *pllsrc,
>> clk_register_pll_div(data->p_name, data->vco_name, 0, reg,
>> 16, 2, 0, pll_divp_table, pll_hw, lock);
>>
>> - if (data->q_name)
>> + if (data->q_name) {
>> clk_register_pll_div(data->q_name, data->vco_name, 0, reg,
>> 24, 4, CLK_DIVIDER_ONE_BASED, NULL,
>> pll_hw, lock);
>>
>> - if (data->r_name)
>> + if (data->pll_num == PLL_I2S)
>> + clk_register_pll_div("plli2s-q-div", data->q_name,
>> + 0, base + STM32F4_RCC_DCKCFGR,
>> + 0, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
>> +
>> + if (data->pll_num == PLL_SAI)
>> + clk_register_pll_div("pllsai-q-div", data->q_name,
>> + 0, base + STM32F4_RCC_DCKCFGR,
>> + 8, 5, 0, NULL, pll_hw, &stm32f4_clk_lock);
>> + }
>
> Shouldn't this be in the config structures?
>
> It seems very odd to me to allow the config structures to control
> whether we take the branch or not and then add these hard coded hacks.
>
ok i will put it in the config structure.
BR
Gabriel.
>
> Daniel.
^ permalink raw reply
* [PATCH 4/6] clk: stm32f4: Add I2S clock
From: Daniel Thompson @ 2016-11-07 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478523943-23142-5-git-send-email-gabriel.fernandez@st.com>
On 07/11/16 13:05, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch introduces I2S clock for stm32f4 soc.
> The I2S clock could be derived from an external clock or from pll-i2s
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> drivers/clk/clk-stm32f4.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
> index 5fa5d51..b7cb359 100644
> --- a/drivers/clk/clk-stm32f4.c
> +++ b/drivers/clk/clk-stm32f4.c
> @@ -216,6 +216,7 @@ enum {
> SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC,
> PLL_VCO_I2S, PLL_VCO_SAI,
> CLK_LCD,
> + CLK_I2S,
Sorry, this has just clicked and it applies to most of the other
patches, but adding things to this list effectively extends the clock
bindings (i.e. the list of valid "other" clocks access with a primary
index of 1).
This list if a list of "arbitrary" constants by which DT periphericals
can be linked to specific clocks.
So...
1) If a clock is introduced here we should update the clock binding
documentations.
2) If no peripheral can connect to the clock (because it is internal
to the clock gen logic and peripherals must connect to the gated
version) it should not be included in this enum.
3) I failed to mention this when the four undocumented clocks
(LSI, LSE, HSE_RTC and RTC) were added.
4) I *should* have added a comment explaining the above to the code.
> END_PRIMARY_CLK
> };
>
> @@ -967,6 +968,8 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
>
> static const char *sdmux_parents[2] = { "pll48", "sys" };
>
> +static const char *i2s_parents[2] = { "plli2s-r", NULL };
> +
> struct stm32f4_clk_data {
> const struct stm32f4_gate_data *gates_data;
> const u64 *gates_map;
> @@ -1005,7 +1008,7 @@ struct stm32f4_clk_data {
>
> static void __init stm32f4_rcc_init(struct device_node *np)
> {
> - const char *hse_clk;
> + const char *hse_clk, *i2s_in_clk;
> int n;
> const struct of_device_id *match;
> const struct stm32f4_clk_data *data;
> @@ -1038,6 +1041,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> stm32f4_gate_map = data->gates_map;
>
> hse_clk = of_clk_get_parent_name(np, 0);
> + i2s_in_clk = of_clk_get_parent_name(np, 1);
Again this looks like a change to the DT bindings.
Also does the code work if i2s_in_clk is NULL or as you hoping to get
away with a not-backwards compatible change?
Daniel.
>
> clk_register_fixed_rate_with_accuracy(NULL, "hsi", NULL, 0,
> 16000000, 160000);
> @@ -1053,6 +1057,12 @@ static void __init stm32f4_rcc_init(struct device_node *np)
> clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll(pllsrc,
> &data->pll_data[2], &stm32f4_clk_lock);
>
> + i2s_parents[1] = i2s_in_clk;
> +
> + clks[CLK_I2S] = clk_hw_register_mux_table(NULL, "i2s",
> + i2s_parents, ARRAY_SIZE(i2s_parents), 0,
> + base + STM32F4_RCC_CFGR, 23, 1, 0, NULL,
> + &stm32f4_clk_lock);
> sys_parents[1] = hse_clk;
> clk_register_mux_table(
> NULL, "sys", sys_parents, ARRAY_SIZE(sys_parents), 0,
>
^ permalink raw reply
* [PATCH v1 03/11] drivers: soc: hisi: Add support for Hisilicon Djtag driver
From: John Garry @ 2016-11-07 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2127881.qmAR1XgW9F@wuerfel>
On 07/11/2016 13:26, Arnd Bergmann wrote:
> On Wednesday, November 2, 2016 11:42:46 AM CET Anurup M wrote:
>> From: Tan Xiaojun <tanxiaojun@huawei.com>
>>
>> The Hisilicon Djtag is an independent component which connects
>> with some other components in the SoC by Debug Bus. This driver
>> can be configured to access the registers of connecting components
>> (like L3 cache) during real time debugging.
>
> The formatting of the text seems odd, please remove the leading spaces.
>
My only response is at the bottom (I will not snip the code for early
referencing convenience).
Anurup/Tan can respond to the rest.
>> drivers/soc/Kconfig | 1 +
>> drivers/soc/Makefile | 1 +
>> drivers/soc/hisilicon/Kconfig | 12 +
>> drivers/soc/hisilicon/Makefile | 1 +
>> drivers/soc/hisilicon/djtag.c | 639 ++++++++++++++++++++++++++++++++++++
>> include/linux/soc/hisilicon/djtag.h | 38 +++
>
> Do you expect other drivers to be added that reference this interface?
> If not, or if you are unsure, just put all of it under drivers/perf
> so we don't introduce a global API that has only one user.
>
>> +
>> +#include <linux/bitops.h>
>> +#include <linux/init.h>
>> +#include <linux/list.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/slab.h>
>> +#include <linux/spinlock.h>
>> +
>> +#include <asm-generic/delay.h>
>
> Never include files from asm-generic directly except from
> an architecture specific asm/*.h header file.
>
>
>> +DEFINE_IDR(djtag_hosts_idr);
>
> make this static
>
>> +static void djtag_read32_relaxed(void __iomem *regs_base, u32 off, u32 *value)
>> +{
>> + void __iomem *reg_addr = regs_base + off;
>> +
>> + *value = readl_relaxed(reg_addr);
>> +}
>> +
>> +static void djtag_write32(void __iomem *regs_base, u32 off, u32 val)
>> +{
>> + void __iomem *reg_addr = regs_base + off;
>> +
>> + writel(val, reg_addr);
>> +}
>
> This looks like an odd combination of interfaces.
> Why can the reads be "relaxed" when the writes can not?
>
> Generally speaking, I'd advise to always use non-relaxed accessors
> unless there is a strong performance reason, and in that case there
> should be a comment explaining the use at each of the callers
> of a relaxed accessor.
>
>> + /* ensure the djtag operation is done */
>> + do {
>> + djtag_read32_relaxed(regs_base, SC_DJTAG_MSTR_START_EN_EX, &rd);
>> +
>> + if (!(rd & DJTAG_MSTR_START_EN_EX))
>> + break;
>> +
>> + udelay(1);
>> + } while (timeout--);
>
> This one is obviously not performance critical at all, so use a non-relaxed
> accessor. Same for the other two in this function.
>
> Are these functions ever called from atomic context? If yes, please document
> from what context they can be called, otherwise please consider changing
> the udelay calls into sleeping waits.
>
>> +int hisi_djtag_writel(struct hisi_djtag_client *client, u32 offset, u32 mod_sel,
>> + u32 mod_mask, u32 val)
>> +{
>> + void __iomem *reg_map = client->host->sysctl_reg_map;
>> + unsigned long flags;
>> + int ret = 0;
>> +
>> + spin_lock_irqsave(&client->host->lock, flags);
>> + ret = client->host->djtag_readwrite(reg_map, offset, mod_sel, mod_mask,
>> + true, val, 0, NULL);
>> + if (ret)
>> + pr_err("djtag_writel: error! ret=%d\n", ret);
>> + spin_unlock_irqrestore(&client->host->lock, flags);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(hisi_djtag_writel);
>
> That would of course imply changing the spinlock to a mutex here as well.
>
>> +static const struct of_device_id djtag_of_match[] = {
>> + /* for hip05(D02) cpu die */
>> + { .compatible = "hisilicon,hip05-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip05(D02) io die */
>> + { .compatible = "hisilicon,hip05-io-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) cpu die */
>> + { .compatible = "hisilicon,hip06-cpu-djtag-v1",
>> + .data = (void *)djtag_readwrite_v1 },
>> + /* for hip06(D03) io die */
>> + { .compatible = "hisilicon,hip06-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + /* for hip07(D05) cpu die */
>> + { .compatible = "hisilicon,hip07-cpu-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + /* for hip07(D05) io die */
>> + { .compatible = "hisilicon,hip07-io-djtag-v2",
>> + .data = (void *)djtag_readwrite_v2 },
>> + {},
>> +};
>
> If these are backwards compatible, just mark them as compatible in DT,
> e.g. hip06 can use
>
> compatible = "hisilicon,hip06-cpu-djtag-v1", "hisilicon,hip05-cpu-djtag-v1";
>
> so you can tell the difference if you need to, but the driver only has to
> list the oldest one here.
>
> What is the difference between the cpu and io djtag interfaces?
>
> I think you can also drop the '(void *)'.
>
>> +static void djtag_register_devices(struct hisi_djtag_host *host)
>> +{
>> + struct device_node *node;
>> + struct hisi_djtag_client *client;
>> +
>> + if (!host->of_node)
>> + return;
>> +
>> + for_each_available_child_of_node(host->of_node, node) {
>> + if (of_node_test_and_set_flag(node, OF_POPULATED))
>> + continue;
>> + client = hisi_djtag_of_register_device(host, node);
>> + list_add(&client->next, &host->client_list);
>> + }
>> +}
>
> Can you explain your thoughts behind creating a new bus type
> and adding the child devices manually rather than using
> platform_device structures with of_platform_populate()?
>
> Do you expect to see other implementations of this bus type
> with incompatible bus drivers?
>
> Arnd
>
Hi Arnd,
The new bus type tries to model the djtag in a similar way to I2C/USB
driver arch, where we have a host bus adapter and child devices attached
to the bus. The child devices are bus driver devices and have bus
addresses. We think of the djtag as a separate bus, so we are modelling
it as such.
The bus driver offers a simple host interface for clients to read/write
to the djtag bus: bus accesses are hidden from the client, the host
drives the bus.
> Do you expect to see other implementations of this bus type
> with incompatible bus drivers?
Maybe, not sure.
Cheers,
John
>
> .
>
^ permalink raw reply
* [PATCH 1/6] mfd: max8997: Initialize max8997 register map
From: Javier Martinez Canillas @ 2016-11-07 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-2-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> This patch add regmap initialization to use register map
> in max8997-clk device driver
>
> CC: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Patch looks good to me. Now that the driver uses regmap, I think you should
be able to get rid of drivers/mfd/max8997-irq.c and use the regmap IRQ chip
like is done in most Maxim PMIC MFD drivers.
That can be done as a follow-up of this series though.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset
From: Lucas Stach @ 2016-11-07 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C+3rCnpQvonXyDaMmUxsDYAnXRBXrUwbP3AT5TbofSgQ@mail.gmail.com>
Am Montag, den 07.11.2016, 10:15 -0200 schrieb Fabio Estevam:
> Hi Lucas,
>
> On Mon, Nov 7, 2016 at 8:34 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
>
> > The problem is definitely present in current mainline Linux. I intent to
> > remove this workaround from the kernel, but we need to make sure that
> > the bootloader properly disables PCIe before jumping to the kernel
> > image.
> >
> > I don't know what the status of this is in U-Boot, but Barebox already
> > does this correctly.
> >
> > Fabio, would you mind to port this coed to U-Boot, or at least check if
> > it does the right thing?
>
> Sure, could you point me to the Barebox fix so I can take a look?
>
Sure,
https://git.pengutronix.de/cgit/barebox/commit/?id=f1da98da2760c21487bbba8f7fb957c843a22896
Regards,
Lucas
^ permalink raw reply
* [PATCH 2/6] dt-bindings: clk: max8997: Add DT binding documentation
From: Javier Martinez Canillas @ 2016-11-07 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-3-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> Add Device Tree binding documentation for the clocks
> outputs in the Maxim-8997 Power Management IC.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> CC: linux-clk at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 1/6] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: Radosław Pietrzyk @ 2016-11-07 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478523943-23142-2-git-send-email-gabriel.fernandez@st.com>
> +static struct clk_hw *clk_register_pll_div(const char *name,
> + const char *parent_name, unsigned long flags,
> + void __iomem *reg, u8 shift, u8 width,
> + u8 clk_divider_flags, const struct clk_div_table *table,
> + struct clk_hw *pll_hw, spinlock_t *lock)
> +{
> + struct stm32f4_pll_div *pll_div;
> + struct clk_hw *hw;
> + struct clk_init_data init;
> + int ret;
> +
> + /* allocate the divider */
> + pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
> + if (!pll_div)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &stm32f4_pll_div_ops;
> + init.flags = flags;
Maybe it's worth to have CLK_SET_RATE_PARENT here and the VCO clock
should have CLK_SET_RATE_GATE flag and we can get rid of custom
divider ops.
> -static void stm32f4_rcc_register_pll(const char *hse_clk, const char *hsi_clk)
> +
> +static struct clk_hw *stm32f4_rcc_register_pll(const char *pllsrc,
> + const struct stm32f4_pll_data *data, spinlock_t *lock)
> {
> - unsigned long pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
> + struct stm32f4_pll *pll;
> + struct clk_init_data init = { NULL };
> + void __iomem *reg;
> + struct clk_hw *pll_hw;
> + int ret;
> +
> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> + if (!pll)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = data->vco_name;
> + init.ops = &stm32f4_pll_gate_ops;
> + init.flags = CLK_IGNORE_UNUSED;
CLK_SET_RATE_GATE here
Moreover why not having VCO as a composite clock from gate and mult ?
According to docs SAI VCO (don't know about I2S ) must be within
certain range so clk_set_rate_range should be somewhere.
^ permalink raw reply
* [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Javier Martinez Canillas @ 2016-11-07 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-4-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
> accurate low frequency clock for MAX8997 internal circuit as well as
> external circuit. This patch adds support for these two clocks.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> CC: linux-clk at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
What kernel version are you basing this on? The Maxim common clock code
is going away for v4.9 and instead the clk-max77686 driver supports both
77686 and 77802 clocks. See commit 8ad313fe4e00 ("clk: max77686: Combine
Maxim max77686 and max77802 driver").
Since the 8997 clock IP looks very similar to 77802 AFAICT, you should
also extend the clk-max77686 driver to have 8997 support.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Adam Ford @ 2016-11-07 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105070043.GA5597@dragon>
On Sat, Nov 5, 2016 at 2:00 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> On Fri, Nov 04, 2016 at 12:44:21PM -0500, Adam Ford wrote:
>> >> +&iomuxc {
>> >> + imx6qdl-logicpd-baseboard {
>> >> +
>> >
>> > Drop this container node and put the following pinctrl nodes directly
>> > under &iomuxc.
>> >
>>
>> Like the regulators above, if I remove this connector, the system
>> won't boot. I compared both the regulator and the iomuxc containers
>> in this device tree with other imx6q boards, and I seem to be
>> consistent with what other boards are doing.
>
> You might want to rebase the patch to latest mainline like v4.9-rc3 and
> test first.
I rebased on the 4.9-rc4, and the pinmux errors go away, but the
regulators appear to need their own container or I get the following
error:
Warning (reg_format): "reg" property in /regulator-otg-vbus has
invalid length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /regulator-h1-vbus has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /regulator-3v3 has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)
Warning (reg_format): "reg" property in /regulator-pcie has invalid
length (4 bytes) (#address-cells == 1, #size-cells == 1)
Can I leave the the regulator container? This seems consistent with
the other imx6 boards.
adam
>
> Shawn
^ permalink raw reply
* [PATCH 4/6] ARM: dts: Add clock provider specific properties to max8997 node
From: Javier Martinez Canillas @ 2016-11-07 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-5-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> This patch adds a label and #clock-cells property to device node of
> max8997 PMIC to allow using it as a clock provider.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/boot/dts/exynos4210-origen.dts | 3 ++-
> arch/arm/boot/dts/exynos4210-trats.dts | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
> index cb3a255..6c7ef4e 100644
> --- a/arch/arm/boot/dts/exynos4210-origen.dts
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -147,11 +147,12 @@
> pinctrl-0 = <&i2c0_bus>;
> pinctrl-names = "default";
>
> - max8997_pmic at 66 {
> + max8997: max8997_pmic at 66 {
The ePAPR says that the node name should be "somewhat generic, reflecting
the function of the device and not its precise programming model". So I
think this should be instead:
max8997: pmic at 66 {
[...]
> - max8997_pmic at 66 {
> + max8997: max8997_pmic at 66 {
Same here.
The rest looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 5/6] mfd: max8997: Add max8997-clk name in mfd_cell
From: Javier Martinez Canillas @ 2016-11-07 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-6-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> This patch add max8997-clk in mfd_cell max8997_devs in order to probe
> max8997-clk device driver.
>
> CC: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 6/6] ARM: dts: Extend the S3C RTC node with rtc_src clock
From: Javier Martinez Canillas @ 2016-11-07 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478513376-14307-7-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
> Extend the S3C RTC node with rtc_src clock so it could be operational.
> The rtc_src clock is provided by MAX8997.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree at vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Maxime Ripard @ 2016-11-07 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103095444.GX1041@n2100.armlinux.org.uk>
Hi Russell,
On Thu, Nov 03, 2016 at 09:54:45AM +0000, Russell King - ARM Linux wrote:
> > Yes. And that is an XBMC only solution, that doesn't work with the
> > fbdev emulation and is probably doing an additional composition to
> > scale down and center their frames through OpenGL.
>
> Well, it will have to be doing a scaling step anyway. If the video
> frame is a different size to the active area, scaling is required
> no matter what. A 576p SD image needs to be scaled up, and a 1080p
> image would need to be scaled down for a 1080p overscanned display
> with a reduced active area to counter the overscanning - no matter
> how you do it.
Yes, except that scaling is not always an option. In my particular
example, there's no scaler after the CRTC, which essentially prevents
it from being used in that use case. Which is also why I ended up
reducing the mode reported to the user.
> For graphics, userspace could add mode(s) with increased porches and
> reduced active area itself to achieve an underscanned display on a
> timing which the display device always overscans - there's no need to
> do that in the kernel, all the APIs are there to be able to do it
> already.
>
> That means your framebuffer will be smaller, but that's the case
> anyway.
Yes, that would be a good idea. But it's not always an option for
applications that would rely on the fbdev emulation (like QT's eglfs),
which would then have no way to change whatever default there is (and
the only one able to know how bad it actually is is the user).
> > > > The second one is that we still need to expose the reduced modes to
> > > > userspace, and not only the displayed size, so that the applications
> > > > know what they must draw on. But I guess this could be adjusted by the
> > > > core too.
> > > >
> > > > In order to work consistently, I think all planes should be adjusted
> > > > that way, so that relative coordinates are from the primary plane
> > > > origin, and not the display origin. But that could be adjusted too by
> > > > the core I guess.
> > >
> > > I'm not sure about that - we want the graphics to be visible, but that
> > > may not be appropriate for an video overlay frame. It's quite common
> > > for (eg) broadcast video to contain dead pixels or other artifacts on
> > > the right hand side, and the broadcast video expects overscan to be
> > > present.
> > >
> > > I know this because I have run my TV with overscan disabled, even for
> > > broadcast TV.
> >
> > I know, but on this particular hardware, composite really is just
> > another video output. There's not even a TV receiver in it, so I don't
> > think we have to worry about it.
>
> Whether or not there's a TV receiver is irrelevant - if you can decode
> broadcast video, then you run into the problem. For example, if you
> plug in a USB DVB stick, stream it across the network, etc.
Good point.
> Remember, you're proposing a generic solution, so making arguments
> about things that are not possible with your specific hardware isn't
> really that relevant to a generic solution.
This is definitely not what I'm proposing. I've been told very early
on that such a generic solution was not even worth working on.
> So, I may want my graphics to appear on an overscanned display such
> that I can see the borders, but I may want the overlaid video to use
> the full active area (including overscan) to hide some of the broadcast
> mess at the edges of the screen.
>
> > > Yea, that's quite sad, "analog" has become a dirty word, but really
> > > this has nothing to do with "analog" at all - there are LCD TVs (and
> > > some monitors) out there which take HDMI signals but refuse to
> > > disable overscan no matter what you do to them if you provide them
> > > with a "broadcast" mode - so the analog excuse is very poor.
> >
> > I'd agree with you, but I was also told to not turn that into a
> > generic code and deal with that in my driver.
>
> I guess whoever told you that was wrong. I used to have a cheap TV
> here which took HDMI, and always overscans broadcast modes, and
> underscans PC modes. No amount of fiddling with various settings
> (either in the TV or AVI frames) changes that.
>
> I've run into that with a _monitor_ that Andrew Hutton has, which has
> a HDMI input - exactly the same thing - 1080p, 720p etc are all
> unconditionally overscanned, 1024x768 etc are all unconditionally
> underscanned and there's nothing that can be done to change it.
>
> The problem is that TVs are at liberty to have this behaviour, so
> the overscaned problem is always going to be there, and each driver
> should not be dealing with it in their own specific ways.
I agree with you, however, without any directions on how to do this,
and willingness to merge this, I don't really see why we would work on
such a generic implementation in the first place.
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/8a156bb1/attachment.sig>
^ permalink raw reply
* [PATCH] drm/sun4i: Propagate error to the caller
From: Maxime Ripard @ 2016-11-07 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107011957.GK3327@joana>
On Mon, Nov 07, 2016 at 10:19:57AM +0900, Gustavo Padovan wrote:
> Hi Christophe,
>
> 2016-11-04 Christophe JAILLET <christophe.jaillet@wanadoo.fr>:
>
> > If 'sun4i_layers_init()' returns an error, propagate it instead of
> > returning -EINVAL unconditionally.
> >
> > Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> > ---
> > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Applied, 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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161107/310f8f7b/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Fabio Estevam @ 2016-11-07 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xJ=KK-=5sVu0Or5bep-cdk3hq4+a3gFj-W0bCcVhQyWNw@mail.gmail.com>
Hi Adam,
On Mon, Nov 7, 2016 at 1:03 PM, Adam Ford <aford173@gmail.com> wrote:
> I rebased on the 4.9-rc4, and the pinmux errors go away, but the
> regulators appear to need their own container or I get the following
> error:
You can write the regulators without the container as follows:
reg_3p3v: regulator-3p3v {
reg_usb_otg_vbus: regulator-usbotgvbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg_vbus";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Fabio Estevam @ 2016-11-07 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5DOjGAJytMruLT7mZg2BEbNB2FW-Fyo0Xx0tsr-sZ=6Rw@mail.gmail.com>
On Mon, Nov 7, 2016 at 1:11 PM, Fabio Estevam <festevam@gmail.com> wrote:
> You can write the regulators without the container as follows:
Or just look at arch/arm/boot/dts/imx6qdl-ts4900.dtsi for an example.
^ permalink raw reply
* [PATCH] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: Adam Ford @ 2016-11-07 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BVYchz8qrUn8mssn3L7AbD0pvFkKy0zp2CJmsG+hzVxA@mail.gmail.com>
On Mon, Nov 7, 2016 at 9:16 AM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Nov 7, 2016 at 1:11 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
>> You can write the regulators without the container as follows:
>
> Or just look at arch/arm/boot/dts/imx6qdl-ts4900.dtsi for an example.
Thank you for the hint. It was the reg = <0> causing the issue. Once
I removed these, It all went away.
I appreciate the patience. This is my first IMX6 board. I'll push a
V2 Patch shortly.
adam
^ permalink raw reply
* [PATCH 1/2] cpufreq: enable the DT cpufreq driver on the Integrators
From: Linus Walleij @ 2016-11-07 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477380085-6929-1-git-send-email-linus.walleij@linaro.org>
On Tue, Oct 25, 2016 at 9:21 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> This enables the generic DT and OPP-based cpufreq driver on the
> ARM Integrator/AP and Integrator/CP.
>
> Cc: Rafael J. Wysocki <rafael@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Rafael could you merge these two patches so that I can merge the
corresponding DTS files into the ARM SoC tree?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] ARM: dts: imx6: Add support for Logic PD SOM and Baseboard
From: aford173 at gmail.com @ 2016-11-07 15:22 UTC (permalink / raw)
To: linux-arm-kernel
From: Adam Ford <aford173@gmail.com>
The system on module (SOM) specific portions are in the .dtsi
while the baseboard specific portions are in the .dts file.
V2: Fix small bug and update style for 4.9 Kernel
Signed-off-by: Adam Ford <aford173@gmail.com>
diff --git a/arch/arm/boot/dts/imx6q-logicpd.dts b/arch/arm/boot/dts/imx6q-logicpd.dts
new file mode 100644
index 0000000..ab42a33
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-logicpd.dts
@@ -0,0 +1,439 @@
+/*
+ * Copyright 2011 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ * Copyright 2016 Logic PD
+ *
+ * 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 , 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 "imx6qdl-logicpd.dtsi"
+
+/ {
+ model = "Logic PD Acuity SOM";
+ compatible = "fsl,imx6q";
+
+ aliases {
+ display = &lcd_display;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ gen_led0 {
+ label = "cpu0";
+ gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "cpu0";
+ };
+
+ gen_led1 {
+ label = "cpu1";
+ gpios = <&gpio3 20 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "cpu1";
+ };
+
+ gen_led2 {
+ label = "heartbeat";
+ gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ gen_led3 {
+ label = "Always On";
+ gpios = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ reg_usb_otg_vbus: regulator-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usb_h1_vbus: regulator-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ regulator-always-on;
+ gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "reg_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_pcie: regulator-pcie {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie_reg>;
+ regulator-name = "MPCIE_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ power {
+ label = "Power Button";
+ gpios = <&gpio3 28 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ linux,code = <KEY_POWER>;
+ };
+
+ volume-up {
+ label = "Volume Up";
+ gpios = <&gpio3 29 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ linux,code = <KEY_VOLUMEUP>;
+ };
+
+ volume-down {
+ label = "Volume Down";
+ gpios = <&gpio3 30 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ linux,code = <KEY_VOLUMEDOWN>;
+ };
+
+ recovery-button {
+ label = "Recover";
+ gpios = <&gpio3 31 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ linux,code = <0x198>;
+ };
+ };
+
+ backlight_lcd: backlight-lcd {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ enable-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
+ pwms = <&pwm3 0 5000000>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ };
+
+
+ lcd_display: display at di0 {
+ compatible = "fsl,imx-parallel-display";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interface-pix-fmt = "rgb565";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcd>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&type15_timing>;
+ type15_timing: type_15 {
+ clock-frequency = <9000000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <3>;
+ hback-porch = <2>;
+ hsync-len = <42>;
+ vback-porch = <3>;
+ vfront-porch = <2>;
+ vsync-len = <11>;
+ hsync-active = <1>;
+ vsync-active = <1>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+
+ port at 0 {
+ reg = <0>;
+ display_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+ panel: panel {
+ compatible = "innolux,at043tn24", "simple-panel";
+ enable-gpios = <&gpio4 17 GPIO_ACTIVE_HIGH>;
+ backlight = <&backlight_lcd>;
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+};
+
+&ipu1_di0_disp0 {
+ remote-endpoint = <&display_in>;
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "okay";
+};
+
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&usbh1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh1>;
+ vbus-supply = <®_usb_h1_vbus>;
+ status = "okay";
+};
+
+&usbh2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbh2>;
+ phy_type = "hsic";
+ disable-over-current;
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ status = "okay";
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rmii";
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ status = "okay";
+};
+
+&i2c3 {
+ touchscreen: tsc2004 at 48 {
+ compatible = "ti,tsc2004";
+ vio-supply = <®_3v3>;
+ reg = <0x48>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ reset-gpios = <&gpio4 10 GPIO_ACTIVE_HIGH>;
+ interrupts-extended = <&gpio1 6 IRQ_TYPE_EDGE_RISING>;
+ touchscreen-fuzz-x = <4>;
+ touchscreen-fuzz-y = <7>;
+ touchscreen-fuzz-pressure = <2>;
+ touchscreen-size-x = <4096>;
+ touchscreen-size-y = <4096>;
+ touchscreen-max-pressure = <2048>;
+ ti,x-plate-ohms = <280>;
+ ti,esd-recovery-timeout-ms = <8000>;
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ reset-gpio = <&gpio1 9 0>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1
+ MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1
+ MX6QDL_PAD_EIM_EB3__UART3_RTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x130b0
+ >;
+ };
+
+ pinctrl_usbh1: usbh1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_0__GPIO1_IO00 0x1b0b0
+ >;
+ };
+
+ pinctrl_usbh2: usbh2grp {
+ fsl,pins = <
+ MX6QDL_PAD_RGMII_TXC__USB_H2_DATA 0x13030
+ MX6QDL_PAD_RGMII_TX_CTL__USB_H2_STROBE 0x17030
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
+ MX6QDL_PAD_KEY_ROW1__GPIO4_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x130b0
+ MX6QDL_PAD_EIM_D20__GPIO3_IO20 0x130b0
+ MX6QDL_PAD_EIM_D21__GPIO3_IO21 0x130b0
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x130b0
+ >;
+ };
+
+ pinctrl_gpio_keys: gpio_keysgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D28__GPIO3_IO28 0x1b0b0
+ MX6QDL_PAD_EIM_D29__GPIO3_IO29 0x1b0b0
+ MX6QDL_PAD_EIM_D30__GPIO3_IO30 0x1b0b0
+ MX6QDL_PAD_EIM_D31__GPIO3_IO31 0x1b0b0
+ >;
+ };
+
+ pinctrl_touchscreen: touchscreengrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x1b0b0
+ MX6QDL_PAD_GPIO_6__GPIO1_IO06 0x1b0b0
+ >;
+ };
+
+ pinctrl_pcie_reg: pciereggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_7__GPIO1_IO07 0x1b0b0
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x1b0b0
+ MX6QDL_PAD_GPIO_9__GPIO1_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_lcd: lcdgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x10
+ MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x100b0
+ MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02 0x10
+ MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03 0x10
+ MX6QDL_PAD_DI0_PIN4__IPU1_DI0_PIN04 0x10
+ MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01 0x10
+ MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02 0x10
+ MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03 0x10
+ MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04 0x10
+ MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05 0x10
+ MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06 0x10
+ MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07 0x10
+ MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08 0x10
+ MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09 0x10
+ MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10 0x10
+ MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11 0x10
+ MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12 0x10
+ MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13 0x10
+ MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14 0x10
+ MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15 0x10
+ MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16 0x10
+ >;
+ };
+
+ pinctrl_backlight: backlightgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT2__GPIO2_IO10 0x100b0
+ >;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT1__PWM3_OUT 0x1b0b1
+ >;
+ };
+};
+
+
diff --git a/arch/arm/boot/dts/imx6qdl-logicpd.dtsi b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
new file mode 100644
index 0000000..18f98b12
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-logicpd.dtsi
@@ -0,0 +1,331 @@
+/*
+ * Copyright 2016 Logic PD
+ * This file is adapted from imx6qdl-sabresd.dtsi.
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "imx6q.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ memory {
+ reg = <0x10000000 0x80000000>;
+ };
+
+
+};
+
+/* Reroute power feeding the CPU to come from the external PMIC */
+&cpu0 {
+ arm-supply = <&sw1a_reg>;
+ soc-supply = <&sw1c_reg>;
+};
+
+®_arm
+{
+ vin-supply = <&sw1a_reg>;
+};
+
+®_soc
+{
+ vin-supply = <&sw1c_reg>;
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ pmic: pfuze100 at 08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-name = "vddcore";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <725000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-name = "vddsoc";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "gen_3v3";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-name = "sw3a_vddr";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-name = "sw3b_vddr";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "gen_rgmii";
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ regulator-name = "gen_5v0";
+ };
+
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "gen_vsns";
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "gen_1v5";
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-name = "vgen2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-name = "gen_vadj_0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-name = "gen_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-name = "gen_adj_1";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-name = "gen_2v5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+ };
+ };
+
+ temp_sense1: tmp102 at 49 {
+ compatible = "ti,tmp102";
+ reg = <0x49>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tempsense>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ temp_sense0: tmp102 at 4a {
+ compatible = "ti,tmp102";
+ reg = <0x4a>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+ #thermal-sensor-cells = <1>;
+ };
+
+ user_eeprom: at24 at 52 {
+ compatible = "atmel,24c64";
+ pagesize = <32>;
+ reg = <0x52>;
+ };
+
+ mfg_eeprom: at24 at 51 {
+ compatible = "atmel,24c64";
+ pagesize = <32>;
+ read-only;
+ reg = <0x51>;
+ };
+};
+
+&iomuxc {
+ pinctrl_gpmi_nand: gpminandgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CLE__NAND_CLE 0x0b0b1
+ MX6QDL_PAD_NANDF_ALE__NAND_ALE 0x0b0b1
+ MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0x0b0b1
+ MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0x0b000
+ MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0x0b0b1
+ MX6QDL_PAD_SD4_CMD__NAND_RE_B 0x0b0b1
+ MX6QDL_PAD_SD4_CLK__NAND_WE_B 0x0b0b1
+ MX6QDL_PAD_NANDF_D0__NAND_DATA00 0x0b0b1
+ MX6QDL_PAD_NANDF_D1__NAND_DATA01 0x0b0b1
+ MX6QDL_PAD_NANDF_D2__NAND_DATA02 0x0b0b1
+ MX6QDL_PAD_NANDF_D3__NAND_DATA03 0x0b0b1
+ MX6QDL_PAD_NANDF_D4__NAND_DATA04 0x0b0b1
+ MX6QDL_PAD_NANDF_D5__NAND_DATA05 0x0b0b1
+ MX6QDL_PAD_NANDF_D6__NAND_DATA06 0x0b0b1
+ MX6QDL_PAD_NANDF_D7__NAND_DATA07 0x0b0b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D17__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_DAT6__UART1_RX_DATA 0x1b0b1
+ MX6QDL_PAD_SD3_DAT7__UART1_TX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_DAT5__UART2_RTS_B 0x1b0b1
+ MX6QDL_PAD_SD4_DAT6__UART2_CTS_B 0x1b0b1
+ MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17071
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10071
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17071
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17071
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17071
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17071
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_RST__GPIO7_IO08 0x1f0b0
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__GPIO7_IO01 0x1f0b0
+ MX6QDL_PAD_SD3_DAT5__GPIO7_IO00 0x1f0b0
+ >;
+ };
+
+ pinctrl_tempsense: tempsensegrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x1b0b0
+ >;
+ };
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio6 16 GPIO_ACTIVE_HIGH>;
+ keep-power-in-suspend;
+ enable-sdio-wakeup;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ non-removable;
+ keep-power-in-suspend;
+ enable-sdio-wakeup;
+ vmmc-supply = <&sw2_reg>;
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ wlcore: wlcore at 0 {
+ compatible = "ti,wl1837";
+ reg = <2>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <1 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] mm: hugetlb: support gigantic surplus pages
From: Gerald Schaefer @ 2016-11-07 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478141499-13825-3-git-send-email-shijie.huang@arm.com>
On Thu, 3 Nov 2016 10:51:38 +0800
Huang Shijie <shijie.huang@arm.com> wrote:
> When testing the gigantic page whose order is too large for the buddy
> allocator, the libhugetlbfs test case "counter.sh" will fail.
>
> The failure is caused by:
> 1) kernel fails to allocate a gigantic page for the surplus case.
> And the gather_surplus_pages() will return NULL in the end.
>
> 2) The condition checks for "over-commit" is wrong.
>
> This patch adds code to allocate the gigantic page in the
> __alloc_huge_page(). After this patch, gather_surplus_pages()
> can return a gigantic page for the surplus case.
>
> This patch also changes the condition checks for:
> return_unused_surplus_pages()
> nr_overcommit_hugepages_store()
>
> After this patch, the counter.sh can pass for the gigantic page.
>
> Acked-by: Steve Capper <steve.capper@arm.com>
> Signed-off-by: Huang Shijie <shijie.huang@arm.com>
> ---
> mm/hugetlb.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 0bf4444..2b67aff 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1574,7 +1574,7 @@ static struct page *__alloc_huge_page(struct hstate *h,
> struct page *page;
> unsigned int r_nid;
>
> - if (hstate_is_gigantic(h))
> + if (hstate_is_gigantic(h) && !gigantic_page_supported())
> return NULL;
Is it really possible to stumble over gigantic pages w/o having
gigantic_page_supported()?
Also, I've just tried this on s390 and counter.sh still fails after these
patches, and it should fail on all archs as long as you use the gigantic
hugepage size as default hugepage size. This is because you only changed
nr_overcommit_hugepages_store(), which handles nr_overcommit_hugepages
in sysfs, and missed hugetlb_overcommit_handler() which handles
/proc/sys/vm/nr_overcommit_hugepages for the default sized hugepages.
However, changing hugetlb_overcommit_handler() in a similar way
produces a lockdep warning, see below, and counters.sh now results in
FAIL mmap failed: Cannot allocate memory
So I guess this needs more thinking (or just a proper annotation, as
suggested, didn't really look into it):
[ 129.595054] INFO: trying to register non-static key.
[ 129.595060] the code is fine but needs lockdep annotation.
[ 129.595062] turning off the locking correctness validator.
[ 129.595066] CPU: 4 PID: 1108 Comm: counters Not tainted 4.9.0-rc3-00261-g577f12c-dirty #12
[ 129.595067] Hardware name: IBM 2964 N96 704 (LPAR)
[ 129.595069] Stack:
[ 129.595070] 00000003b4833688 00000003b4833718 0000000000000003 0000000000000000
[ 129.595075] 00000003b48337b8 00000003b4833730 00000003b4833730 0000000000000020
[ 129.595078] 0000000000000000 0000000000000020 000000000000000a 000000000000000a
[ 129.595082] 000000000000000c 00000003b4833780 0000000000000000 00000003b4830000
[ 129.595086] 0000000000000000 0000000000112d90 00000003b4833718 00000003b4833770
[ 129.595089] Call Trace:
[ 129.595095] ([<0000000000112c6a>] show_trace+0x8a/0xe0)
[ 129.595098] [<0000000000112d40>] show_stack+0x80/0xd8
[ 129.595103] [<0000000000744eec>] dump_stack+0x9c/0xe0
[ 129.595106] [<00000000001b0760>] register_lock_class+0x1a8/0x530
[ 129.595109] [<00000000001b59fa>] __lock_acquire+0x10a/0x7f0
[ 129.595110] [<00000000001b69b8>] lock_acquire+0x2e0/0x330
[ 129.595115] [<0000000000a44920>] _raw_spin_lock_irqsave+0x70/0xb8
[ 129.595118] [<000000000031cdce>] alloc_gigantic_page+0x8e/0x2c8
[ 129.595120] [<000000000031e95a>] __alloc_huge_page+0xea/0x4d8
[ 129.595122] [<000000000031f4c6>] hugetlb_acct_memory+0xa6/0x418
[ 129.595125] [<0000000000323b32>] hugetlb_reserve_pages+0x132/0x240
[ 129.595152] [<000000000048be62>] hugetlbfs_file_mmap+0xd2/0x130
[ 129.595155] [<0000000000303918>] mmap_region+0x368/0x6e0
[ 129.595157] [<0000000000303fb8>] do_mmap+0x328/0x400
[ 129.595160] [<00000000002dc1aa>] vm_mmap_pgoff+0x9a/0xe8
[ 129.595162] [<00000000003016dc>] SyS_mmap_pgoff+0x23c/0x288
[ 129.595164] [<00000000003017b6>] SyS_old_mmap+0x8e/0xb0
[ 129.595166] [<0000000000a45b06>] system_call+0xd6/0x270
[ 129.595167] INFO: lockdep is turned off.
^ permalink raw reply
* [PATCHv4 0/4] WX checking for arm64
From: Mark Rutland @ 2016-11-07 15:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030150307.33vc2m7y5y6wzbqc@localhost>
On Sun, Oct 30, 2016 at 03:03:07PM +0000, Catalin Marinas wrote:
> On Thu, Oct 27, 2016 at 09:27:30AM -0700, Laura Abbott wrote:
> > Laura Abbott (4):
> > arm64: dump: Make ptdump debugfs a separate option
> > arm64: dump: Make the page table dumping seq_file optional
> > arm64: dump: Remove max_addr
> > arm64: dump: Add checking for writable and exectuable pages
>
> Queued for 4.10. Thanks.
Catalin mentioned to me that he saw some KASAN splats when testing; it
looks like need a fixup something like the below.
Apologies for not having spotted this when testing!
Thanks,
Mark.
---->8----
>From 06fef1ad1138d0808eec770e64458a350941bd2d Mon Sep 17 00:00:00 2001
From: Mark Rutland <mark.rutland@arm.com>
Date: Mon, 7 Nov 2016 15:24:40 +0000
Subject: [PATCH] Fix KASAN splats with DEBUG_WX
Booting a kernel built with both CONFIG_KASAN and CONFIG_DEBUG_WX
results in a stream of KASAN splats for stack-out-of-bounds accesses,
e.g.
==================================================================
BUG: KASAN: stack-out-of-bounds in note_page+0xd8/0x650 at addr ffff8009364ebdd0
Read of size 8 by task swapper/0/1
page:ffff7e0024d93ac0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x4000000000000000()
page dumped because: kasan: bad access detected
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc3-00004-g25f7267 #77
Hardware name: ARM Juno development board (r1) (DT)
Call trace:
[<ffff20000808b2d8>] dump_backtrace+0x0/0x278
[<ffff20000808b564>] show_stack+0x14/0x20
[<ffff2000084e4e4c>] dump_stack+0xa4/0xc8
[<ffff200008256ee0>] kasan_report_error+0x4a8/0x4d0
[<ffff200008257330>] kasan_report+0x40/0x48
[<ffff200008255894>] __asan_load8+0x84/0x98
[<ffff2000080a0928>] note_page+0xd8/0x650
[<ffff2000080a0fb4>] walk_pgd.isra.1+0x114/0x220
[<ffff2000080a1248>] ptdump_check_wx+0xa8/0x118
[<ffff20000809ed40>] mark_rodata_ro+0x90/0xd0
[<ffff200008cafb88>] kernel_init+0x28/0x110
[<ffff200008083680>] ret_from_fork+0x10/0x50
Memory state around the buggy address:
ffff8009364ebc80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8009364ebd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8009364ebd80: 00 00 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2
^
ffff8009364ebe00: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00 00 00
ffff8009364ebe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
... this happens because note_page assumes that the marker array has at
least two elements (the latter of which may be the terminator), but the
marker array for ptdump_check_wx only contains one element. Thus we
dereference some garbage on the stack when looking at
marker[1].start_address.
Given we don't need the markers for the WX checks, we could modify
note_page to allow for a NULL marker array, but for now it's simpler to
add an entry to the ptdump_check_wx marker array, so let's do that. As
it's somewhat confusing to have two identical entries, we add an initial
entry with a start address of zero.
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/mm/dump.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index ef8aca8..ca74a2a 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -383,6 +383,7 @@ void ptdump_check_wx(void)
struct pg_state st = {
.seq = NULL,
.marker = (struct addr_marker[]) {
+ { 0, NULL},
{ -1, NULL},
},
.check_wx = true,
--
1.9.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