* Re: [PATCH 10/11] Document: dt: binding: imx: update doc for imx6sll
From: Stephen Boyd @ 2016-12-08 22:54 UTC (permalink / raw)
To: Bai Ping
Cc: shawnguo, mturquette, robh+dt, mark.rutland, linus.walleij,
kernel, fabio.estevam, daniel.lezcano, tglx, p.zabel, linux-clk,
devicetree, linux-gpio, linux-arm-kernel
In-Reply-To: <1480660774-25055-11-git-send-email-ping.bai@nxp.com>
On 12/02, Bai Ping wrote:
> Add necessary document update for i.MX6SLL support.
>
> Signed-off-by: Bai Ping <ping.bai@nxp.com>
> ---
> .../devicetree/bindings/clock/imx6sll-clock.txt | 13 ++++++++
> .../bindings/pinctrl/fsl,imx6sll-pinctrl.txt | 37 ++++++++++++++++++++++
Please split the bindings into different patches and put them
closer to the drivers that use them in the series.
> 2 files changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> create mode 100644 Documentation/devicetree/bindings/pinctrl/fsl,imx6sll-pinctrl.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/imx6sll-clock.txt b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> new file mode 100644
> index 0000000..4f52efa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/imx6sll-clock.txt
> @@ -0,0 +1,13 @@
> +* Clock bindings for Freescale i.MX6 UltraLite
> +
> +Required properties:
> +- compatible: Should be "fsl,imx6sll-ccm"
> +- reg: Address and length of the register set
> +- #clock-cells: Should be <1>
> +- clocks: list of clock specifiers, must contain an entry for each required
> + entry in clock-names
> +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> +
> +The clock consumer should specify the desired clock by having the clock
> +ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6sll-clock.h
> +for the full list of i.MX6 SLL clock IDs.
Can you add an example node here?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH] misc: eeprom: implement compatible DT probing
From: Linus Walleij @ 2016-12-08 23:32 UTC (permalink / raw)
To: Peter Rosin
Cc: Wolfram Sang, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <95d9c739-8a69-b990-2840-b5381d54a99d@axentia.se>
On Thu, Dec 8, 2016 at 7:23 PM, Peter Rosin <peda@axentia.se> wrote:
> On 2016-12-08 18:47, Linus Walleij wrote:
>> Before this patch, the following device tree node does not probe,
>> which might be considered a bug:
>>
>> eeprom@52 {
>> compatible = "atmel,at24c128";
>
> The way I read it, that should be "atmel,24c128", i.e. w/o the "at" prefix.
(...)
> and then lists the compatibles you have added to the match table (but you
> have this extra "at" prefix for the atmel manufacturer).
>
> The way I read the above, you are free to use any manufacturer and still
> have it work, and indeed, I have success with this node:
>
> eeprom@50 {
> compatible = "nxp,24c02";
> reg = <0x50>;
> pagesize = <16>;
> };
>
> I fear that your patch will regress this matching on the wildcard
> manufacturer. I haven't tested that though, but there are enough
> question marks anyway...
Bah I probably just screwed up syntactically and now worked around
a non-existing problem. I will try as you suggest, just "vendor,type"
and see if it works. It probably does.
Some days I feel just utterly stupid. Sorry for the fuzz.
Wolfram: ignore the patch for now.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: simple-card: use devm_get_clk_from_child()
From: Kuninori Morimoto @ 2016-12-09 0:20 UTC (permalink / raw)
To: Stephen Boyd
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <20161208220942.GO5423@codeaurora.org>
Hi Stephen
> > @@ -111,14 +112,13 @@ int asoc_simple_card_parse_clk(struct device_node *node,
> > * or "system-clock-frequency = <xxx>"
> > * or device's module clock.
> > */
> > - clk = of_clk_get(node, 0);
> > + clk = devm_get_clk_from_child(dev, node, NULL);
> > if (!IS_ERR(clk)) {
> > simple_dai->sysclk = clk_get_rate(clk);
> > - simple_dai->clk = clk;
> > } else if (!of_property_read_u32(node, "system-clock-frequency", &val)) {
> > simple_dai->sysclk = val;
> > } else {
> > - clk = of_clk_get(dai_of_node, 0);
> > + clk = devm_get_clk_from_child(dev, dai_of_node, NULL);
>
>
> I was confused for a minute about how the second of_clk_get()
> call with the dai_link node could work. Is that documented
> anywhere or used by anyone? It seems like it's at least another
> child node of the sound node (which is dev here) so it seems ok.
Documentation/devicetree/bindings/sound/simple-card.txt
explains 1st of_clk_get will be used as "if needed",
2nd of_clk_get will be used as "not needed pattern".
1st pattern will use specific clock, 2nd pattern will use
"cpu" or "codec" clock.
2nd one was added by someone (I forgot), and many driver is
based on this feature.
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: simple-card-utils: enable clocks/clock-names/clock-ranges
From: Kuninori Morimoto @ 2016-12-09 0:21 UTC (permalink / raw)
To: Stephen Boyd
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
In-Reply-To: <20161208220901.GN5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi Stephen
> > From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> >
> > Current simple-card is supporting this style for clocks
> >
> > sound {
> > ...
> > simple-audio-card,cpu {
> > sound-dai = <&xxx>;
> > clocks = <&cpu_clock>;
> > };
> > simple-audio-card,codec {
> > sound-dai = <&xxx>;
> > clocks = <&codec_clock>;
> > };
> > };
> >
> > Now, it can support this style too, because we can use
> > devm_get_clk_from_child() now.
> >
> > sound {
> > ...
> > clocks = <&cpu_clock>, <&codec_clock>;
> > clock-names = "cpu", "codec";
> > clock-ranges;
> > ...
> > simple-audio-card,cpu {
> > sound-dai = <&xxx>;
> > };
> > simple-audio-card,codec {
> > sound-dai = <&xxx>;
> > };
> > };
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> I don't see any reason why we need this patch though. The binding
> works as is, so supporting different styles doesn't seem like a
> good idea to me. Let's just keep what we have? Even if a sub-node
> like cpu or codec gets more than one element in the clocks list
> property, we can make that work by passing a clock-name then
> based on some sort of other knowledge.
OK, thanks. Let's skip this patch.
But I believe this idea itself is not wrong (?)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: simple-card-utils: enable clocks/clock-names/clock-ranges
From: Kuninori Morimoto @ 2016-12-09 0:22 UTC (permalink / raw)
To: Stephen Boyd
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
In-Reply-To: <20161208220901.GN5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi Stephen
> > From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> >
> > Current simple-card is supporting this style for clocks
> >
> > sound {
> > ...
> > simple-audio-card,cpu {
> > sound-dai = <&xxx>;
> > clocks = <&cpu_clock>;
> > };
> > simple-audio-card,codec {
> > sound-dai = <&xxx>;
> > clocks = <&codec_clock>;
> > };
> > };
> >
> > Now, it can support this style too, because we can use
> > devm_get_clk_from_child() now.
> >
> > sound {
> > ...
> > clocks = <&cpu_clock>, <&codec_clock>;
> > clock-names = "cpu", "codec";
> > clock-ranges;
> > ...
> > simple-audio-card,cpu {
> > sound-dai = <&xxx>;
> > };
> > simple-audio-card,codec {
> > sound-dai = <&xxx>;
> > };
> > };
> >
> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> I don't see any reason why we need this patch though. The binding
> works as is, so supporting different styles doesn't seem like a
> good idea to me. Let's just keep what we have? Even if a sub-node
> like cpu or codec gets more than one element in the clocks list
> property, we can make that work by passing a clock-name then
> based on some sort of other knowledge.
OK, thanks. Let's skip this patch.
But I believe this idea/method itself is not wrong (?)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] clkdev: add devm_get_clk_from_child()
From: Kuninori Morimoto @ 2016-12-09 0:25 UTC (permalink / raw)
To: Stephen Boyd
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
In-Reply-To: <20161208220824.GM5423-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Hi Stephen, Mark
> > This is v5 of "clkdev: add devm_of_clk_get()", but new series.
> > I hope my understanding was correct with your idea.
>
> Yes this looks good. Given that we're so close to the merge
> window, perhaps I should just merge the first patch into clk-next
> and then it will be ready for anyone who wants to use it? The
> sound patches can be left up to others to handle.
OK thanks.
Mark, I think I should re-post 2nd patch (3rd will be dropped) after
merge window ? There will be no branch dependency
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: simple-card-utils: enable clocks/clock-names/clock-ranges
From: Stephen Boyd @ 2016-12-09 0:26 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <874m2eymu3.wl%kuninori.morimoto.gx@renesas.com>
On 12/09, Kuninori Morimoto wrote:
>
> Hi Stephen
>
> > > From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> > >
> > > Current simple-card is supporting this style for clocks
> > >
> > > sound {
> > > ...
> > > simple-audio-card,cpu {
> > > sound-dai = <&xxx>;
> > > clocks = <&cpu_clock>;
> > > };
> > > simple-audio-card,codec {
> > > sound-dai = <&xxx>;
> > > clocks = <&codec_clock>;
> > > };
> > > };
> > >
> > > Now, it can support this style too, because we can use
> > > devm_get_clk_from_child() now.
> > >
> > > sound {
> > > ...
> > > clocks = <&cpu_clock>, <&codec_clock>;
> > > clock-names = "cpu", "codec";
> > > clock-ranges;
> > > ...
> > > simple-audio-card,cpu {
> > > sound-dai = <&xxx>;
> > > };
> > > simple-audio-card,codec {
> > > sound-dai = <&xxx>;
> > > };
> > > };
> > >
> > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> >
> > I don't see any reason why we need this patch though. The binding
> > works as is, so supporting different styles doesn't seem like a
> > good idea to me. Let's just keep what we have? Even if a sub-node
> > like cpu or codec gets more than one element in the clocks list
> > property, we can make that work by passing a clock-name then
> > based on some sort of other knowledge.
>
> OK, thanks. Let's skip this patch.
> But I believe this idea/method itself is not wrong (?)
>
Right it's not wrong, just seems confusing to have two methods.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: simple-card: use devm_get_clk_from_child()
From: Stephen Boyd @ 2016-12-09 0:28 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
In-Reply-To: <877f7aymxu.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On 12/09, Kuninori Morimoto wrote:
>
> Hi Stephen
>
> > > @@ -111,14 +112,13 @@ int asoc_simple_card_parse_clk(struct device_node *node,
> > > * or "system-clock-frequency = <xxx>"
> > > * or device's module clock.
> > > */
> > > - clk = of_clk_get(node, 0);
> > > + clk = devm_get_clk_from_child(dev, node, NULL);
> > > if (!IS_ERR(clk)) {
> > > simple_dai->sysclk = clk_get_rate(clk);
> > > - simple_dai->clk = clk;
> > > } else if (!of_property_read_u32(node, "system-clock-frequency", &val)) {
> > > simple_dai->sysclk = val;
> > > } else {
> > > - clk = of_clk_get(dai_of_node, 0);
> > > + clk = devm_get_clk_from_child(dev, dai_of_node, NULL);
> >
> >
> > I was confused for a minute about how the second of_clk_get()
> > call with the dai_link node could work. Is that documented
> > anywhere or used by anyone? It seems like it's at least another
> > child node of the sound node (which is dev here) so it seems ok.
>
> Documentation/devicetree/bindings/sound/simple-card.txt
> explains 1st of_clk_get will be used as "if needed",
> 2nd of_clk_get will be used as "not needed pattern".
> 1st pattern will use specific clock, 2nd pattern will use
> "cpu" or "codec" clock.
> 2nd one was added by someone (I forgot), and many driver is
> based on this feature.
>
Can you point to some dts file in the kernel that falls into the
devm_get_clk_from_child(dev, dai_of_node, NULL) part?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] ASoC: simple-card: use devm_get_clk_from_child()
From: Kuninori Morimoto @ 2016-12-09 0:33 UTC (permalink / raw)
To: Stephen Boyd
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <20161209002837.GE5423@codeaurora.org>
Hi Stephen
> > Documentation/devicetree/bindings/sound/simple-card.txt
> > explains 1st of_clk_get will be used as "if needed",
> > 2nd of_clk_get will be used as "not needed pattern".
> > 1st pattern will use specific clock, 2nd pattern will use
> > "cpu" or "codec" clock.
> > 2nd one was added by someone (I forgot), and many driver is
> > based on this feature.
> >
>
> Can you point to some dts file in the kernel that falls into the
> devm_get_clk_from_child(dev, dai_of_node, NULL) part?
How about this ?
linux/arch/arm/boot/dts/r8a7790-lager.dts :: rsnd_ak4643
^ permalink raw reply
* Re: [PATCH 2/6] net: ethernet: ti: cpts: add support for ext rftclk selection
From: Stephen Boyd @ 2016-12-09 0:47 UTC (permalink / raw)
To: Grygorii Strashko
Cc: Richard Cochran, Murali Karicheri, David S. Miller, netdev,
Mugunthan V N, Sekhar Nori, linux-kernel, linux-omap, Rob Herring,
devicetree, Wingman Kwok, linux-clk
In-Reply-To: <11994fbc-3713-6ef7-8a44-8a2442106dfc@ti.com>
On 12/06, Grygorii Strashko wrote:
> Subject: [PATCH] cpts refclk sel
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> arch/arm/boot/dts/keystone-k2e-netcp.dtsi | 10 +++++-
> drivers/net/ethernet/ti/cpts.c | 52 ++++++++++++++++++++++++++++++-
> 2 files changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/keystone-k2e-netcp.dtsi b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
> index 919e655..b27aa22 100644
> --- a/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
> +++ b/arch/arm/boot/dts/keystone-k2e-netcp.dtsi
> @@ -138,7 +138,7 @@ netcp: netcp@24000000 {
> /* NetCP address range */
> ranges = <0 0x24000000 0x1000000>;
>
> - clocks = <&clkpa>, <&clkcpgmac>, <&chipclk12>;
> + clocks = <&clkpa>, <&clkcpgmac>, <&cpts_mux>;
> clock-names = "pa_clk", "ethss_clk", "cpts";
> dma-coherent;
>
> @@ -162,6 +162,14 @@ netcp: netcp@24000000 {
> cpts-ext-ts-inputs = <6>;
> cpts-ts-comp-length;
>
> + cpts_mux: cpts_refclk_mux {
> + #clock-cells = <0>;
> + clocks = <&chipclk12>, <&chipclk13>;
> + cpts-mux-tbl = <0>, <1>;
> + assigned-clocks = <&cpts_mux>;
> + assigned-clock-parents = <&chipclk12>;
Is there a binding update? Why the subnode? Why not have it as
part of the netcp node? Does the cpts-mux-tbl property change?
> + };
> +
> interfaces {
> gbe0: interface-0 {
> slave-port = <0>;
> diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
> index 938de22..ef94316 100644
> --- a/drivers/net/ethernet/ti/cpts.c
> +++ b/drivers/net/ethernet/ti/cpts.c
> @@ -17,6 +17,7 @@
> * along with this program; if not, write to the Free Software
> * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
> */
> +#include <linux/clk-provider.h>
> #include <linux/err.h>
> #include <linux/if.h>
> #include <linux/hrtimer.h>
> @@ -672,6 +673,7 @@ int cpts_register(struct cpts *cpts)
> cpts->phc_index = ptp_clock_index(cpts->clock);
>
> schedule_delayed_work(&cpts->overflow_work, cpts->ov_check_period);
> +
Maybe in another patch.
> return 0;
>
> err_ptp:
> @@ -741,6 +743,54 @@ static void cpts_calc_mult_shift(struct cpts *cpts)
> freq, cpts->cc_mult, cpts->cc.shift, (ns - NSEC_PER_SEC));
> }
>
> +static int cpts_of_mux_clk_setup(struct cpts *cpts, struct device_node *node)
> +{
> + unsigned int num_parents;
> + const char **parent_names;
> + struct device_node *refclk_np;
> + void __iomem *reg;
> + struct clk *clk;
> + u32 *mux_table;
> + int ret;
> +
> + refclk_np = of_get_child_by_name(node, "cpts_refclk_mux");
> + if (!refclk_np)
> + return -EINVAL;
> +
> + num_parents = of_clk_get_parent_count(refclk_np);
> + if (num_parents < 1) {
> + dev_err(cpts->dev, "mux-clock %s must have parents\n",
> + refclk_np->name);
> + return -EINVAL;
> + }
> + parent_names = devm_kzalloc(cpts->dev, (sizeof(char *) * num_parents),
> + GFP_KERNEL);
> + if (!parent_names)
> + return -ENOMEM;
> +
> + of_clk_parent_fill(refclk_np, parent_names, num_parents);
> +
> + mux_table = devm_kzalloc(cpts->dev, sizeof(*mux_table) * (32 + 1),
> + GFP_KERNEL);
> + if (!mux_table)
> + return -ENOMEM;
> +
> + ret = of_property_read_variable_u32_array(refclk_np, "cpts-mux-tbl",
> + mux_table, 1, 32);
> + if (ret < 0)
> + return ret;
> +
> + reg = &cpts->reg->rftclk_sel;
> +
> + clk = clk_register_mux_table(cpts->dev, refclk_np->name,
> + parent_names, num_parents,
> + 0, reg, 0, 0x1F, 0, mux_table, NULL);
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + return of_clk_add_provider(refclk_np, of_clk_src_simple_get, clk);
Can you please use the clk_hw APIs instead?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: simple-card-utils: enable clocks/clock-names/clock-ranges
From: Kuninori Morimoto @ 2016-12-09 0:55 UTC (permalink / raw)
To: Stephen Boyd
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <20161209002635.GD5423@codeaurora.org>
Hi Stephen
> > > I don't see any reason why we need this patch though. The binding
> > > works as is, so supporting different styles doesn't seem like a
> > > good idea to me. Let's just keep what we have? Even if a sub-node
> > > like cpu or codec gets more than one element in the clocks list
> > > property, we can make that work by passing a clock-name then
> > > based on some sort of other knowledge.
> >
> > OK, thanks. Let's skip this patch.
> > But I believe this idea/method itself is not wrong (?)
> >
> Right it's not wrong, just seems confusing to have two methods.
Thanks.
Very clear for me :)
^ permalink raw reply
* [PATCH v3 0/3] ARM: dts: imx6: Support Poslab Savageboard dual & quad
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Fabio Estevam, linux-arm-kernel, devicetree, linux-kernel,
Milo Kim
Poslab Savageboard is i.MX6 SoC base, but BSP code from the vendor is
not mainline u-boot and kernel. Personal reason of using this board is
testing etnaviv user-space driver, so I re-write device tree files based on
mainline kernel for the first step.
This patchset includes common DT file, dual and quad board files.
Supported components are
- Display: HDMI and LVDS panel
- eMMC and SD card
- Ethernet
- Pinmux configuration
- SATA: only for Savageboard quad
- UART1 for debug console
- USB host
Missing features are
- Audio (WM8903)
- USB OTG
- PMIC WM8326: default settings are used so no issue to bring-up the system
- MIPI DSI, CSI
Patches are tested on the Savageboard quad but the dual version should work
because the only difference between dual and quad is SATA support.
More information in http://www.savageboard.org
v3:
Specify the dtbs for i.MX6 build.
v2:
Fix DT node for regulator, phy-reset-gpios and iomuxc node.
Milo Kim (3):
ARM: dts: imx6: Add Savageboard common file
ARM: dts: imx6: Support Savageboard dual
ARM: dts: imx6: Support Savageboard quad
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++
arch/arm/boot/dts/imx6q-savageboard.dts | 54 ++++++
arch/arm/boot/dts/imx6qdl-savageboard.dtsi | 262 +++++++++++++++++++++++++++++
4 files changed, 368 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
create mode 100644 arch/arm/boot/dts/imx6q-savageboard.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-savageboard.dtsi
--
2.9.3
^ permalink raw reply
* [PATCH v3 1/3] ARM: dts: imx6: Add Savageboard common file
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Fabio Estevam, linux-arm-kernel, devicetree, linux-kernel,
Milo Kim
In-Reply-To: <20161209010436.7994-1-woogyom.kim@gmail.com>
* Memory
memblock for DDR3 1GB
* Regulator
3.3V for panel and backlight.
* Display
Enable HDMI and LVDS panel. Savageboard supports AVIC TM097TDH02 panel
which is compatible with Hannstar HSD100PXN1, so reuse it.
* Clock
The commit d28be499c45e6 is applied to support LVDS and HDMI output
simultaneously.
* Pinmux
eMMC, ethernet, HDMI, I2C, power button, PWM, SD card and UART.
* Others
Enable ethernet, UART1 debug, USB host, USDHC3 for microSD card and
USDHC4 for built-in eMMC storage.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/imx6qdl-savageboard.dtsi | 262 +++++++++++++++++++++++++++++
1 file changed, 262 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6qdl-savageboard.dtsi
diff --git a/arch/arm/boot/dts/imx6qdl-savageboard.dtsi b/arch/arm/boot/dts/imx6qdl-savageboard.dtsi
new file mode 100644
index 0000000..a7a7e1d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-savageboard.dtsi
@@ -0,0 +1,262 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.com>
+ *
+ * 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.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ memory@10000000 {
+ device_type = "memory";
+ reg = <0x10000000 0x40000000>;
+ };
+
+ backlight: panel_bl {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <4>;
+ power-supply = <®_3p3v>;
+ pwms = <&pwm1 0 10000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ power {
+ gpios = <&gpio3 7 GPIO_ACTIVE_LOW>;
+ label = "Power Button";
+ linux,code = <KEY_POWER>;
+ wakeup-source;
+ };
+ };
+
+ panel {
+ compatible = "avic, tm097tdh02", "hannstar,hsd100pxn1";
+ backlight = <&backlight>;
+ power-supply = <®_3p3v>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+};
+
+&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>;
+};
+
+&fec {
+ phy-mode = "rgmii";
+ phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi_tx_cec>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel@0 {
+ reg = <0>;
+ status = "okay";
+
+ port@4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbh1 {
+ status = "okay";
+};
+
+/* SD card */
+&usdhc3 {
+ bus-width = <4>;
+ cd-gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sd>;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc4 {
+ bus-width = <8>;
+ keep-power-in-suspend;
+ no-1-8-v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_emmc>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_emmc: emmcgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
+ MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
+ MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
+ MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
+ MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
+ MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
+ MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
+ MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
+ MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
+ MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ /* PHY reset */
+ MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x1b0b0
+ >;
+ };
+
+ pinctrl_hdmi_tx_cec: hdmitxcecgrp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__HDMI_TX_CEC_LINE 0x1f8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_gpio_keys: gpiokeysgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA7__GPIO3_IO07 0x1b0b1
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT3__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_sd: sdgrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ 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
+ /* CD pin */
+ MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+ >;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/3] ARM: dts: imx6: Support Savageboard dual
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Milo Kim
In-Reply-To: <20161209010436.7994-1-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Common savageboard DT file is used for board support.
Specify this dtb file for i.MX6Q build.
Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-savageboard.dts | 50 ++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-savageboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..64660c7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -348,6 +348,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-sabreauto.dtb \
imx6dl-sabrelite.dtb \
imx6dl-sabresd.dtb \
+ imx6dl-savageboard.dtb \
imx6dl-ts4900.dtb \
imx6dl-tx6dl-comtft.dtb \
imx6dl-tx6s-8034.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-savageboard.dts b/arch/arm/boot/dts/imx6dl-savageboard.dts
new file mode 100644
index 0000000..2cac30d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-savageboard.dts
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ *
+ * 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 "imx6dl.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Dual";
+ compatible = "poslab,imx6dl-savageboard", "fsl,imx6dl";
+};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 3/3] ARM: dts: imx6: Support Savageboard quad
From: Milo Kim @ 2016-12-09 1:04 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Fabio Estevam, linux-arm-kernel, devicetree, linux-kernel,
Milo Kim
In-Reply-To: <20161209010436.7994-1-woogyom.kim@gmail.com>
Use common board file and support SATA interface additionally.
Specify this dtb file for i.MX6 build.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-savageboard.dts | 54 +++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-savageboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 64660c7..25b1e19 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -392,6 +392,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-sabreauto.dtb \
imx6q-sabrelite.dtb \
imx6q-sabresd.dtb \
+ imx6q-savageboard.dtb \
imx6q-sbc6x.dtb \
imx6q-tbs2910.dtb \
imx6q-ts4900.dtb \
diff --git a/arch/arm/boot/dts/imx6q-savageboard.dts b/arch/arm/boot/dts/imx6q-savageboard.dts
new file mode 100644
index 0000000..8d74002
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-savageboard.dts
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2016 Milo Kim <woogyom.kim@gmail.com>
+ *
+ * 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 "imx6q.dtsi"
+#include "imx6qdl-savageboard.dtsi"
+
+/ {
+ model = "Poslab SavageBoard Quad";
+ compatible = "poslab,imx6q-savageboard", "fsl,imx6q";
+};
+
+&sata {
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: sun8i: Support DTB build for NanoPi M1
From: Milo Kim @ 2016-12-09 1:47 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Milo Kim
The commit 10efbf5f1633 introduced NanoPi M1 board but it's missing in
Allwinner H3 DTB build.
Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..4cbdf6f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -845,6 +845,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
sun8i-h3-orangepi-lite.dtb \
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 2/2] eeprom: Add IDT 89HPESx driver bindings file
From: Serge Semin @ 2016-12-09 1:57 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Srinivas Kandagatla, Andrew Lunn,
Mark Rutland, Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161205190456.GA25116@mobilestation>
Rob,
Could you please respond on these comments? I've got some free time, so I wanna
rewrite the code until I've not got busy again.
Regards,
-Sergey
On Mon, Dec 05, 2016 at 10:04:56PM +0300, Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, Dec 05, 2016 at 11:27:07AM -0600, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, Dec 5, 2016 at 9:25 AM, Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > On Mon, Dec 05, 2016 at 08:46:21AM -0600, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > >> On Tue, Nov 29, 2016 at 01:38:21AM +0300, Serge Semin wrote:
> > >> > See cover-letter for changelog
> > >> >
> > >> > Signed-off-by: Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >> >
> > >> > ---
> > >> > .../devicetree/bindings/misc/idt_89hpesx.txt | 41 ++++++++++++++++++++++
> > >>
> > >> There's not a better location for this? I can't tell because you don't
> > >> describe what the device is.
> > >>
> > >
> > > The device is PCIe-switch EEPROM driver with additional debug-interface to
> > > access the switch CSRs. EEPROM is accesses via a separate i2c-slave
> > > interface of the switch.
> > >
> > > There might be another place to put the binding file in. There is a special
> > > location for EEPROM drivers bindings - Documentation/devicetree/bindings/eeprom/ .
> > > But as far as I understood from the files put in there, it's intended for
> > > pure EEPROM drivers only. On the other hand the directory I've chosen:
> > > Documentation/devicetree/bindings/misc/
> > > mostly intended for some unusual devices. My device isn't usual, since it
> > > has CSRs debug-interface as well. Additionally I've found
> > > eeprom-93xx46.txt binding file there, which describes EEPROM bindings.
> > >
> > > Anyway if you find the file should be placed in
> > > Documentation/devicetree/bindings/eeprom/ instead, I'll move it, it's not
> > > that a big problem.
> > >
>
> What about this comment? Shall the file be left at the path I placed it?
>
> > >> > 1 file changed, 41 insertions(+)
> > >> > create mode 100644 Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> > >> >
> > >> > diff --git a/Documentation/devicetree/bindings/misc/idt_89hpesx.txt b/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> > >> > index 0000000..469cc93
> > >> > --- /dev/null
> > >> > +++ b/Documentation/devicetree/bindings/misc/idt_89hpesx.txt
> > >> > @@ -0,0 +1,41 @@
> > >> > +EEPROM / CSR SMBus-slave interface of IDT 89HPESx devices
> > >> > +
> > >> > +Required properties:
> > >> > + - compatible : should be "<manufacturer>,<type>"
> > >> > + Basically there is only one manufacturer: idt, but some
> > >> > + compatible devices may be produced in future. Following devices
> > >> > + are supported: 89hpes8nt2, 89hpes12nt3, 89hpes24nt6ag2,
> > >> > + 89hpes32nt8ag2, 89hpes32nt8bg2, 89hpes12nt12g2, 89hpes16nt16g2,
> > >> > + 89hpes24nt24g2, 89hpes32nt24ag2, 89hpes32nt24bg2;
> > >> > + 89hpes12n3, 89hpes12n3a, 89hpes24n3, 89hpes24n3a;
> > >> > + 89hpes32h8, 89hpes32h8g2, 89hpes48h12, 89hpes48h12g2,
> > >> > + 89hpes48h12ag2, 89hpes16h16, 89hpes22h16, 89hpes22h16g2,
> > >> > + 89hpes34h16, 89hpes34h16g2, 89hpes64h16, 89hpes64h16g2,
> > >> > + 89hpes64h16ag2;
> > >> > + 89hpes12t3g2, 89hpes24t3g2, 89hpes16t4, 89hpes4t4g2,
> > >> > + 89hpes10t4g2, 89hpes16t4g2, 89hpes16t4ag2, 89hpes5t5,
> > >> > + 89hpes6t5, 89hpes8t5, 89hpes8t5a, 89hpes24t6, 89hpes6t6g2,
> > >> > + 89hpes24t6g2, 89hpes16t7, 89hpes32t8, 89hpes32t8g2,
> > >> > + 89hpes48t12, 89hpes48t12g2.
> > >> > + Current implementation of the driver doesn't have any device-
> > >>
> > >> Driver capabilties are irrelevant to bindings.
> > >>
> > >
> > > Why? I've told in the comment, that the devices actually differ by the CSRs
> > > map. Even though it's not reflected in the code at the moment, the CSRs
> > > read/write restrictions can be added by some concerned programmer in
> > > future. But If I left something like "compatible : idt,89hpesx" device
> > > only, it will be problematic to add that functionality.
> >
> > Bindings describe the h/w, not what the Linux, FreeBSD, etc. driver
> > does. You don't want to be changing the binding doc when the driver
> > changes.
> >
> > > Howbeit If you think it's not necessary and "compatible = idt,89hpesx" is
> > > ok, it's perfectly fine for me to make it this way. The property will be
> > > even simpler, than current approach.
> >
> > NO! That's not at all what I'm suggesting. Specific compatible strings
> > are the right way to go for the reasons you give. You just don't need
> > to state why here (because it is true for all bindings).
> >
>
> Oh, I just misunderstood what you said. I'll discard the comment.
>
> > >> > + specific functionalities. But since each of them differs
> > >> > + by registers mapping, CSRs read/write restrictions can be
> > >> > + added in future.
> > >> > + - reg : I2C address of the IDT 89HPES device.
> > >> > +
> > >> > +Optional properties:
> > >> > + - read-only : Parameterless property disables writes to the EEPROM
> > >> > + - idt,eesize : Size of EEPROM device connected to IDT 89HPES i2c-master bus
> > >> > + (default value is 4096 bytes if option isn't specified)
> > >> > + - idt,eeaddr : Custom address of EEPROM device
> > >> > + (If not specified IDT 89HPESx device will try to communicate
> > >> > + with EEPROM sited by default address - 0x50)
> > >>
> > >> Don't we already have standard EEPROM properties that could be used
> > >> here?
> > >>
> > >
> > > If we do, just tell me which one. There are standard options:
> >
> > You can grep thru bindings as easily as I can. I can't do that for
> > everyone's binding.
> >
>
> It won't be necessary due to the next comment.
>
> > > "compatible, reg, pagesize, read-only". There isn't any connected with
> > > EEPROM actual size.
> > > Why so? Because standard EEPROM-drivers determine the device size from the
> > > compatible-string name. Such approach won't work in this case, because
> > > PCIe-switch and it EEPROM are actually two different devices. Look at the
> > > chain of the usual platform board design:
> > > Host <--- i2c ----> i2c-slave iface |PCIe-switch| i2c-master iface <--- i2c ---> EEPROM
> > >
> > > As you cas see the Host reaches EEPROM through the set of PCIe-switch
> > > i2c-interfaces. In order to properly get data from it my driver needs actual
> > > EEPROM size and it address in the i2c-master bus of the PCIe-switch, in
> > > addition to the standard reg-field, which is address of PCIe-switch i2c-slave
> > > interface and read-only parameter if EEPROM-device has got WP pin asserted.
> >
> > Ah, this needs to be much different than I thought. You need to model
> > (i.e. use the same binding) the EEPROM node just like it was directly
> > attached to the host. So this means you need the 2nd i2c bus modeled
> > which means you need the PCIe switch modeled. A rough outline of the
> > nodes would look like this:
> >
> > host-i2c: i2c {
> > compatible ="host-i2c"
> > };
> >
> > pcie {
> > pcie-switch {
> > i2c-bus = <&host-i2c>;
> > i2c-bus {
> > eeprom@50 {
> > };
> > };
> > };
> > };
> >
> > So this models the PCIe switch as a PCIe device, it has a phandle back
> > to it's controller since it's not a child of the i2c controller. Then
> > the devices on switches i2c bus are modeled as children of the switch.
> >
> > Alternatively, it could be described all as children of host-i2c node.
> > It's common for i2c devices to have downstream i2c buses. I2C muxes
> > are one example and there are bindings defined for all this. There's
> > also chips like mpu-6050 that have slave buses.
> >
> > Rob
>
> I think I understand what you says. However let me just bring some details
> to make things clear.
>
> First of all the driver doesn't do any PCI-Express-related work. The device
> !IDT PCI Express switch! just has two additional i2c interfaces: i2c-slave
> and i2c-master. As it is obvious from the bus-names i2c-slave is the interface,
> where IDT PCIe-switch device is actually slave. This interface can be reached
> from the host by ordinary i2c buses. i2c-master interface is connected to an
> i2c-bus, where IDT PCIe-switch is single master. This bus can have just one
> EEPROM device to store some initialization data. Host can send some specific
> smbus-packets to i2c-slave interface of IDT PCIe-switch in order to
> preinitialize EEPROM data, connected to i2c-master interface of the device.
>
> Additionally IDT PCIe-switch handles some special smbus packets coming to it
> i2c-slave interface to read/write its internal CSR. This interface can be
> used to debug the device, when there are problems with it usual PCI Express
> related functioning.
>
> So to speak, it wouldn't be good to have PCIe-switch declared in dts as a
> PCI-device, since PCI-bus is actually dynamically populated by PCI-core
> subsystem.
>
> According to what you said and the device/driver design I described, the
> following bindings can be suggested:
>
> i2c0: i2c@FFFF0000 {
> compatible = "vendor,i2c-adapter";
> #address-cells = <1>;
> #size-cells = <0>;
>
> idt_i2c_iface: idt@60 {
> compatible = "idt,89hpes32nt8ag2";
> reg = <0x60>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> eeprom@51 {
> compatible = "at,24c64";
> reg = <0x51>;
> read-only;
> };
> };
> };
>
> Suppose there is some host-i2c adapter like "vendor,i2c-adapter" and
> i2c-slave interface of IDT PCIe-switch is connected to it. In this way
> i2c-slave interface will be visible like ordinary i2c-device with just
> one subnode. This subnode explains the actual EEPROM connected to
> IDT PCIe-switch i2c-master interface.
>
> Does it look acceptable? It seems like your last suggestion. Is it?
>
> Thanks,
> -Sergey
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-12-09 2:00 UTC (permalink / raw)
To: Philipp Zabel
Cc: Rob Herring, Arnd Bergmann, haojian.zhuang-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481031753.3202.57.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2016年12月06日 21:42, Philipp Zabel wrote:
> Am Dienstag, den 06.12.2016, 09:51 +0800 schrieb Zhangfei Gao:
>> Add DT bindings documentation for hi3660 SoC reset controller.
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> .../bindings/reset/hisilicon,hi3660-reset.txt | 36 ++++++++++++++++++++++
>> 1 file changed, 36 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>>
>> diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> new file mode 100644
>> index 0000000..178e478
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
>> @@ -0,0 +1,36 @@
>> +Hisilicon System Reset Controller
>> +======================================
>> +
>> +Please also refer to reset.txt in this directory for common reset
>> +controller binding usage.
>> +
>> +The reset controller registers are part of the system-ctl block on
>> +hi3660 SoC.
>> +
>> +Required properties:
>> +- compatible: should be
>> + "hisilicon,hi3660-reset"
>> +- #reset-cells: 2, see below
>> +- hisi,rst-syscon: phandle of the reset's syscon.
>> +
>> +Example:
>> + iomcu: iomcu@ffd7e000 {
>> + compatible = "hisilicon,hi3660-iomcu", "syscon";
>> + reg = <0x0 0xffd7e000 0x0 0x1000>;
>> + };
>> +
>> + iomcu_rst: iomcu_rst_controller {
>> + compatible = "hisilicon,hi3660-reset";
>> + hisi,rst-syscon = <&iomcu>;
>> + #reset-cells = <2>;
>> + };
>> +
>> +Specifying reset lines connected to IP modules
>> +==============================================
>> +example:
>> +
>> + i2c0: i2c@..... {
>> + ...
>> + resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
> Should this mention somewhere what register the offset is supposed to
> point to? This is the address offset to the set register, with the
> corresponding clear register being placed at offset + 4.
How about this description.
-- #reset-cells: 2, see below
- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
May paste in this thread for a clear view.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] dt-bindings: Document the hi3660 reset bindings
From: Zhangfei Gao @ 2016-12-09 2:11 UTC (permalink / raw)
To: Rob Herring, Philipp Zabel, Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Zhangfei Gao
In-Reply-To: <1480989092-31847-2-git-send-email-zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Add DT bindings documentation for hi3660 SoC reset controller.
Signed-off-by: Zhangfei Gao <zhangfei.gao-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
.../bindings/reset/hisilicon,hi3660-reset.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
new file mode 100644
index 0000000..2bf3344
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt
@@ -0,0 +1,43 @@
+Hisilicon System Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller registers are part of the system-ctl block on
+hi3660 SoC.
+
+Required properties:
+- compatible: should be
+ "hisilicon,hi3660-reset"
+- hisi,rst-syscon: phandle of the reset's syscon.
+- #reset-cells : Specifies the number of cells needed to encode a
+ reset source. The type shall be a <u32> and the value shall be 2.
+
+ Cell #1 : offset of the reset assert control
+ register from the syscon register base
+ offset + 4: deassert control register
+ offset + 8: status control register
+ Cell #2 : bit position of the reset in the reset control register
+
+Example:
+ iomcu: iomcu@ffd7e000 {
+ compatible = "hisilicon,hi3660-iomcu", "syscon";
+ reg = <0x0 0xffd7e000 0x0 0x1000>;
+ };
+
+ iomcu_rst: iomcu_rst_controller {
+ compatible = "hisilicon,hi3660-reset";
+ hisi,rst-syscon = <&iomcu>;
+ #reset-cells = <2>;
+ };
+
+Specifying reset lines connected to IP modules
+==============================================
+example:
+
+ i2c0: i2c@..... {
+ ...
+ resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */
+ ...
+ };
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-12-09 2:29 UTC (permalink / raw)
To: Cédric Le Goater, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, Cyrille Pitchen,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Joel Stanley
In-Reply-To: <cd9a46ac-049f-e6b8-586c-d386f6012a51-Bxea+6Xhats@public.gmane.org>
On 12/08/2016 05:36 PM, Cédric Le Goater wrote:
> Hello Marek,
Hi!
[...]
>>> @@ -0,0 +1,72 @@
>>> +* Aspeed Static Memory controller
>>> +* Aspeed SPI Flash Controller
>>> +
>>> +The Static memory controller in the ast2400 supports 5 chip selects
>>> +each can be attached to NAND, parallel NOR, or SPI NOR attached flash.
>>
>> So this controller is supported by this driver, which behaves like a SPI
>> controller driver, yet the block can also do NAND and parallel NOR ?
>
> I think that was answered in a previous email.
Yep, thanks!
>>> +The Firmware Memory Controller in the ast2500 supports 3 chip selects,
>>> +two of which are always in SPI-NOR mode and the third can be SPI-NOR
>>> +or parallel flash. The SPI flash controller in the ast2400 supports
>>> +one of 2 chip selects selected by pinmux. The two SPI flash
>>> +controllers in the ast2500 each support two chip selects.
>>
>> This paragraph is confusing, it's hard to grok down how many different
>> controllers does this driver support and what are their properties from
>> it. It is all there, it's just hard to read.
>
> I will start with the AST2500 controllers only, which are consistent.
That works too :-)
[...]
>>> + tristate "Aspeed flash controllers in SPI mode"
>>> + depends on HAS_IOMEM && OF
>>> + depends on ARCH_ASPEED || COMPILE_TEST
>>> + # IO_SPACE_LIMIT must be equivalent to (~0UL)
>>> + depends on !NEED_MACH_IO_H
>>
>> Why?
>
> Some left over from the patch we have been keeping for too long (+1year)
> in our tree.
Hehe, I see, so it's fixed now.
>>> + help
>>> + This enables support for the New Static Memory Controller
>>> + (FMC) in the Aspeed SoCs (AST2400 and AST2500) when attached
>>> + to SPI nor chips, and support for the SPI Memory controller
>>> + (SPI) for the BIOS.
>>
>> I think there is a naming chaos between FMC, SMC (as in Static MC) and
>> SMC (as in SPI MC).
>
> I agree, I will try to clarify the naming in the next version. I will keep
> the smc suffix for the driver name though.
Thanks!
[...]
>>> +static void aspeed_smc_chip_set_4b_smc_2400(struct aspeed_smc_chip *chip);
>>> +static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
>>> +
>>> +static const struct aspeed_smc_info fmc_2400_info = {
>>> + .maxsize = 64 * 1024 * 1024,
>>> + .nce = 5,
>>> + .maxwidth = 4,
>>> + .hastype = true,
>>
>> Shouldn't all this be specified in DT ?
>
> I am not sure, these values are not configurable. I will remove a few
> of them in the next version as they are unused.
Sooo, I had a discussion with Boris (which we didn't finish yet).
Please ignore my comment for now and yes please, drop unused params.
>>> + .we0 = 16,
>>> + .ctl0 = 0x10,
>>> + .time = 0x94,
>>> + .misc = 0x54,
>>> + .set_4b = aspeed_smc_chip_set_4b,
>>> +};
[...]
>>> +static u32 spi_control_fill_opcode(u8 opcode)
>>> +{
>>> + return ((u32)(opcode)) << CONTROL_SPI_COMMAND_SHIFT;
>>
>> return opcode << CONTROL... , fix these horrible casts and parenthesis
>> globally.
>
> I killed the helper.
Nice, thanks for all the cleanups :)
>>> +}
>>> +
>>> +static inline u32 aspeed_smc_chip_write_bit(struct aspeed_smc_chip *chip)
>>> +{
>>> + return ((u32)1 << (chip->controller->info->we0 + chip->cs));
>>
>> return BIT(...)
>>
>> I'm not sure these microfunctions are even needed.
>
> well, this one is used in a couple of places.
Ah all right, then just return BIT(...) and be done with it.
>>> +}
[...]
>>> +static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
>>> +{
>>> + struct aspeed_smc_chip *chip = nor->priv;
>>> +
>>> + mutex_lock(&chip->controller->mutex);
>>
>> Won't this have a horrid overhead ?
>
> Shall I use the prepare() and unprepare() ops instead ?
I think that'd trim down the amount of locking, yes.
>>> + aspeed_smc_start_user(nor);
>>> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
>>> + aspeed_smc_read_from_ahb(buf, chip->base, len);
>>> + aspeed_smc_stop_user(nor);
>>> +
>>> + mutex_unlock(&chip->controller->mutex);
>>> +
>>> + return 0;
>>> +}
[...]
>>> +static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
>>> + struct resource *r)
>>> +{
>>> + struct aspeed_smc_controller *controller = chip->controller;
>>> + const struct aspeed_smc_info *info = controller->info;
>>> + u32 reg, base_reg;
>>> +
>>> + /*
>>> + * Always turn on the write enable bit to allow opcodes to be
>>> + * sent in user mode.
>>> + */
>>> + aspeed_smc_chip_enable_write(chip);
>>> +
>>> + /* The driver only supports SPI type flash for the moment */
>>> + if (info->hastype)
>>> + aspeed_smc_chip_set_type(chip, smc_type_spi);
>>> +
>>> + /*
>>> + * Configure chip base address in memory
>>> + */
>>> + chip->base = window_start(controller, r, chip->cs);
>>> + if (!chip->base) {
>>> + dev_warn(chip->nor.dev, "CE segment window closed.\n");
>>> + return -1;
>>> + }
>>> +
>>> + /*
>>> + * Read the existing control register to get basic values.
>>> + *
>>> + * XXX This register probably needs more sanitation.
>>
>> What's this comment about ?
>
> This is an initial comment about settings being done by U-Boot
> before the kernel is loaded, and some optimisations should be
> nice to keep, for the FMC controller. I will rephrase.
Shouldn't that be passed via DT instead ? We want to be bootloader
agnostic in Linux.
btw off-topic, but is U-Boot support for these aspeed devices ever be
upstreamed ?
>>> + * Do we need support for mode 3 vs mode 0 clock phasing?
>>> + */
>>> + reg = readl(chip->ctl);
>>> + dev_dbg(controller->dev, "control register: %08x\n", reg);
>>> +
>>> + base_reg = reg & CONTROL_SPI_KEEP_MASK;
>>> + if (base_reg != reg) {
>>> + dev_info(controller->dev,
>>> + "control register changed to: %08x\n",
>>> + base_reg);
>>> + }
[...]
>>> + err = mtd_device_register(&chip->nor.mtd, NULL, 0);
>>> + if (err)
>>> + continue;
>>
>> What happens if some chip fails to register ?
>
> That's not correctly handled ... I have a fix for it.
>
> Thanks,
Thanks for all the work :)
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 16/16] drivers/fsi: Add GPIO based FSI master
From: Jeremy Kerr @ 2016-12-09 4:12 UTC (permalink / raw)
To: Chris Bostic, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
sre-DgEjT+Ai2ygdnm+yROfE0A, mturquette-rdvid1DuHRBWk0Htik3J/w,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Chris Bostic, joel-U3u1mxZcP9KHXe+LvDLADg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, andrew-zrmu5oMJ5Fs,
alistair-Y4h6yKqj69EXC2x5gXVKYQ,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r
In-Reply-To: <1481069677-53660-17-git-send-email-christopher.lee.bostic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Chris,
> +static ssize_t store_scan(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct fsi_master_gpio *master = dev_get_drvdata(dev);
> +
> + fsi_master_gpio_init(master);
> +
> + /* clear out any old scan data if present */
> + fsi_master_unregister(&master->master);
> + fsi_master_register(&master->master);
> +
> + return count;
> +}
> +
> +static DEVICE_ATTR(scan, 0200, NULL, store_scan);
I think it would make more sense to have the scan attribute populated by
the fsi core; we want this on all masters, not just GPIO.
Currently, the only GPIO-master-specific functionality here is the
fsi_master_gpio_init() - but isn't this something that we can do at
probe time instead?
> +static int fsi_master_gpio_probe(struct platform_device *pdev)
> +{
> + struct fsi_master_gpio *master;
> + struct gpio_desc *gpio;
> +
> + master = devm_kzalloc(&pdev->dev, sizeof(*master), GFP_KERNEL);
> + if (!master)
> + return -ENOMEM;
We should be populating master->dev.parent, see
https://github.com/jk-ozlabs/linux/commit/5225d6c47
> + /* Optional pins */
> +
> + gpio = devm_gpiod_get(&pdev->dev, "trans", 0);
> + if (IS_ERR(gpio))
> + dev_dbg(&pdev->dev, "probe: failed to get trans pin\n");
> + else
> + master->gpio_trans = gpio;
I found devm_gpiod_get_optional(), which might make this a little
neater.
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v9 1/3] of: Add vendor prefix for Lattice Semiconductor
From: Joel Holdsworth @ 2016-12-09 5:35 UTC (permalink / raw)
To: atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, marex-ynQEQJNshbs
Cc: Joel Holdsworth
Lattice Semiconductor Corporation is a manufacturer of integrated
circuits and IP products, including low-power FPGAs, video connectivity
devices and millimeter wave wireless products.
Website: http://latticesemi.com
Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Acked-by: Alan Tull <atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx@public.gmane.org>
Acked-by: Moritz Fischer <moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 64fdc8c..7a87932 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -158,6 +158,7 @@ kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
lantiq Lantiq Semiconductor
+lattice Lattice Semiconductor
lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v9 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Joel Holdsworth @ 2016-12-09 5:35 UTC (permalink / raw)
To: atull, moritz.fischer, robh, devicetree, linux-kernel, linux-spi,
marex
Cc: Joel Holdsworth
In-Reply-To: <1481261749-15301-1-git-send-email-joel@airwebreathe.org.uk>
This adds documentation of the device tree bindings of the Lattice iCE40
FPGA driver for the FPGA manager framework.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Alan Tull <atull@opensource.altera.com>
Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
Acked-by: Marek Vasut <marex@denx.de>
---
.../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
new file mode 100644
index 0000000..7e7a78b
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
@@ -0,0 +1,21 @@
+Lattice iCE40 FPGA Manager
+
+Required properties:
+- compatible: Should contain "lattice,ice40-fpga-mgr"
+- reg: SPI chip select
+- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
+- cdone-gpios: GPIO input connected to CDONE pin
+- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
+ that unless the GPIO is held low during startup, the
+ FPGA will enter Master SPI mode and drive SCK with a
+ clock signal potentially jamming other devices on the
+ bus until the firmware is loaded.
+
+Example:
+ ice40: ice40@0 {
+ compatible = "lattice,ice40-fpga-mgr";
+ reg = <0>;
+ spi-max-frequency = <1000000>;
+ cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v9 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Joel Holdsworth @ 2016-12-09 5:35 UTC (permalink / raw)
To: atull, moritz.fischer, robh, devicetree, linux-kernel, linux-spi,
marex
Cc: Joel Holdsworth
In-Reply-To: <1481261749-15301-1-git-send-email-joel@airwebreathe.org.uk>
The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
and very regular structure, designed for low-cost, high-volume consumer
and system applications.
This patch adds support to the FPGA manager for configuring the SRAM of
iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
UltraPlus devices, through slave SPI.
The iCE40 family is notable because it is the first FPGA family to have
complete reverse engineered bit-stream documentation for the iCE40LP and
iCE40HX devices. Furthermore, there is now a Free Software Verilog
synthesis tool-chain: the "IceStorm" tool-chain.
This project is the work of Clifford Wolf, who is the maintainer of
Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
contributions from "Cotton Seed", the main author of "arachne-pnr"; a
place-and-route tool for iCE40 FPGAs.
Having a Free Software synthesis tool-chain offers interesting
opportunities for embedded devices that are able reconfigure themselves
with open firmware that is generated on the device itself. For example
a mobile device might have an application processor with an iCE40 FPGA
attached, which implements slave devices, or through which the processor
communicates with other devices through the FPGA fabric.
A kernel driver for the iCE40 is useful, because in some cases, the FPGA
may need to be configured before other devices can be accessed.
An example of such a device is the icoBoard; a RaspberryPI HAT which
features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
Digilent-compatible PMOD modules. A PMOD module may contain a device
with which the kernel communicates, via the FPGA.
Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
---
drivers/fpga/Kconfig | 6 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/ice40-spi.c | 213 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 220 insertions(+)
create mode 100644 drivers/fpga/ice40-spi.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..967cda4 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -20,6 +20,12 @@ config FPGA_REGION
FPGA Regions allow loading FPGA images under control of
the Device Tree.
+config FPGA_MGR_ICE40_SPI
+ tristate "Lattice iCE40 SPI"
+ depends on OF && SPI
+ help
+ FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
+
config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bc..cc0d364 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
new file mode 100644
index 0000000..3c99859
--- /dev/null
+++ b/drivers/fpga/ice40-spi.c
@@ -0,0 +1,213 @@
+/*
+ * FPGA Manager Driver for Lattice iCE40.
+ *
+ * Copyright (c) 2016 Joel Holdsworth
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This driver adds support to the FPGA manager for configuring the SRAM of
+ * Lattice iCE40 FPGAs through slave SPI.
+ */
+
+#include <linux/fpga/fpga-mgr.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/spi/spi.h>
+
+#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
+#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
+
+#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
+
+struct ice40_fpga_priv {
+ struct spi_device *dev;
+ struct gpio_desc *reset;
+ struct gpio_desc *cdone;
+};
+
+static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+
+ return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
+ FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ice40_fpga_ops_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t count)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+ struct spi_device *dev = priv->dev;
+ struct spi_message message;
+ struct spi_transfer assert_cs_then_reset_delay = {
+ .cs_change = 1,
+ .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
+ };
+ struct spi_transfer housekeeping_delay_then_release_cs = {
+ .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY
+ };
+ int ret;
+
+ if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
+ dev_err(&dev->dev,
+ "Partial reconfiguration is not supported\n");
+ return -ENOTSUPP;
+ }
+
+ /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
+ spi_bus_lock(dev->master);
+
+ gpiod_set_value(priv->reset, 1);
+
+ spi_message_init(&message);
+ spi_message_add_tail(&assert_cs_then_reset_delay, &message);
+ ret = spi_sync_locked(dev, &message);
+
+ /* Come out of reset */
+ gpiod_set_value(priv->reset, 0);
+
+ /* Abort if the chip-select failed */
+ if (ret)
+ goto fail;
+
+ /* Check CDONE is de-asserted i.e. the FPGA is reset */
+ if (gpiod_get_value(priv->cdone)) {
+ dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
+ ret = -EIO;
+ goto fail;
+ }
+
+ /* Wait for the housekeeping to complete, and release SS_B */
+ spi_message_init(&message);
+ spi_message_add_tail(&housekeeping_delay_then_release_cs, &message);
+ ret = spi_sync_locked(dev, &message);
+
+fail:
+ spi_bus_unlock(dev->master);
+
+ return ret;
+}
+
+static int ice40_fpga_ops_write(struct fpga_manager *mgr,
+ const char *buf, size_t count)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+
+ return spi_write(priv->dev, buf, count);
+}
+
+static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+ struct ice40_fpga_priv *priv = mgr->priv;
+ struct spi_device *dev = priv->dev;
+ const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0};
+
+ /* Check CDONE is asserted */
+ if (!gpiod_get_value(priv->cdone)) {
+ dev_err(&dev->dev,
+ "CDONE was not asserted after firmware transfer\n");
+ return -EIO;
+ }
+
+ /* Send of zero-padding to activate the firmware */
+ return spi_write(dev, padding, sizeof(padding));
+}
+
+static const struct fpga_manager_ops ice40_fpga_ops = {
+ .state = ice40_fpga_ops_state,
+ .write_init = ice40_fpga_ops_write_init,
+ .write = ice40_fpga_ops_write,
+ .write_complete = ice40_fpga_ops_write_complete,
+};
+
+static int ice40_fpga_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct device_node *np = spi->dev.of_node;
+ struct ice40_fpga_priv *priv;
+ int ret;
+
+ if (!np) {
+ dev_err(dev, "No Device Tree entry\n");
+ return -EINVAL;
+ }
+
+ priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = spi;
+
+ /* Check board setup data. */
+ if (spi->max_speed_hz > 25000000) {
+ dev_err(dev, "Speed is too high\n");
+ return -EINVAL;
+ }
+
+ if (spi->max_speed_hz < 1000000) {
+ dev_err(dev, "Speed is too low\n");
+ return -EINVAL;
+ }
+
+ if (spi->mode & SPI_CPHA) {
+ dev_err(dev, "Bad mode\n");
+ return -EINVAL;
+ }
+
+ /* Set up the GPIOs */
+ priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
+ if (IS_ERR(priv->cdone)) {
+ dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
+ PTR_ERR(priv->cdone));
+ return -EINVAL;
+ }
+
+ priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(priv->reset)) {
+ dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
+ PTR_ERR(priv->reset));
+ return -EINVAL;
+ }
+
+ /* Register with the FPGA manager */
+ ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
+ &ice40_fpga_ops, priv);
+ if (ret) {
+ dev_err(dev, "Unable to register FPGA manager");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ice40_fpga_remove(struct spi_device *spi)
+{
+ fpga_mgr_unregister(&spi->dev);
+ return 0;
+}
+
+static const struct of_device_id ice40_fpga_of_match[] = {
+ { .compatible = "lattice,ice40-fpga-mgr", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
+
+static struct spi_driver ice40_fpga_driver = {
+ .probe = ice40_fpga_probe,
+ .remove = ice40_fpga_remove,
+ .driver = {
+ .name = "ice40spi",
+ .of_match_table = of_match_ptr(ice40_fpga_of_match),
+ },
+};
+
+module_spi_driver(ice40_fpga_driver);
+
+MODULE_AUTHOR("Joel Holdsworth <joel@airwebreathe.org.uk>");
+MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] misc: eeprom: implement compatible DT probing
From: Peter Rosin @ 2016-12-09 5:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CACRpkda+_0+y6U-gjt2ym45gi=KZ69hixMw6T=tAQGTGy5J37Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2016-12-09 00:32, Linus Walleij wrote:
> On Thu, Dec 8, 2016 at 7:23 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> On 2016-12-08 18:47, Linus Walleij wrote:
>
>>> Before this patch, the following device tree node does not probe,
>>> which might be considered a bug:
>>>
>>> eeprom@52 {
>>> compatible = "atmel,at24c128";
>>
>> The way I read it, that should be "atmel,24c128", i.e. w/o the "at" prefix.
> (...)
>> and then lists the compatibles you have added to the match table (but you
>> have this extra "at" prefix for the atmel manufacturer).
>>
>> The way I read the above, you are free to use any manufacturer and still
>> have it work, and indeed, I have success with this node:
>>
>> eeprom@50 {
>> compatible = "nxp,24c02";
>> reg = <0x50>;
>> pagesize = <16>;
>> };
>>
>> I fear that your patch will regress this matching on the wildcard
>> manufacturer. I haven't tested that though, but there are enough
>> question marks anyway...
>
> Bah I probably just screwed up syntactically and now worked around
> a non-existing problem. I will try as you suggest, just "vendor,type"
> and see if it works. It probably does.
But it is a bit strange. Grepping for compatible.*24c finds quite
a few instances of "bad" compatible strings.
Many on the patterns at,24c256 and at24,24c256 (should be probably
be atmel,24c256) but also a few atmel,at24c16 and atmel,at24c128b.
I don't understand how those last ones ever worked, if it is not
working for you? Especially those with the trailing "b". WTF?
> Some days I feel just utterly stupid. Sorry for the fuzz.
Join the club...
Cheers,
Peter
> Wolfram: ignore the patch for now.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox