* Re: [PATCH v3 4/7] ARM: dts: r7s72100: add RTC_X clock inputs to device tree
From: Geert Uytterhoeven @ 2017-03-30 8:46 UTC (permalink / raw)
To: Chris Brandt
Cc: Alessandro Zummo, Alexandre Belloni, Rob Herring, Mark Rutland,
Simon Horman, RTCLINUX,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas
In-Reply-To: <20170329173035.67477-5-chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Wed, Mar 29, 2017 at 7:30 PM, Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org> wrote:
> Add the RTC clocks to device tree. The frequencies must be fixed values
> according to the hardware manual.
>
> Signed-off-by: Chris Brandt <chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header
From: Linus Walleij @ 2017-03-30 8:33 UTC (permalink / raw)
To: jacopo
Cc: Jacopo Mondi, Bjorn Andersson, Geert Uytterhoeven,
Laurent Pinchart, Chris Brandt, Rob Herring, Mark Rutland,
Russell King, Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20170329155654.GD6247@w540>
On Wed, Mar 29, 2017 at 5:56 PM, jacopo <jacopo@jmondi.org> wrote:
> I can try to give you a few reasons why I don't see those flags fit in
> the pin configuration flags definition.
>
> *) those flags are used during pin multiplexing procedure only and that
> procedure has a specific order to be respected:
>
> You can have a look here:
> https://www.spinics.net/lists/linux-renesas-soc/msg12793.html
> In "rza1_alternate_function_conf()" function, we need to set bidir
> before setting every other register.
> The same applies some lines below:, the PIPC, PMC and PM register set order
> has to be respected, and depends on those BIDIR and SWIO_* parameters.
> This implies those configuration cannot be applied after pin muxing,
> certainly not in pin_config[_group]_set() whose invocation time
> is independent from pin_mux_set()'s one.
But now you are mixing up syntax and semantics.
You are describing what steps are necessary on this hardware to
apply a certain setting. That is fine, if you didn't need any specific
semantics there, you could be using pinctrl-single which will just
hammer stuff into registers, one register per pin. You have a pin
controller driver exactly beacause your hardware has semantics.
How this is described in the device tree or a board file is a different
thing from how you write your driver.
I understand why i makes for easier code, but does it make for more
generic and understandable device trees for people maintaining
several systems? I don't think so.
> One way forward would be, every time we mux a pin, look for a pinconf group
> that includes the pin we're muxing. That would happen for each pin,
> for no added benefits imo.
The benefit is clearly abstraction, standardization and readability of the
device tree. I, as developer, understand what is going on electrically,
having seen this on other systems, and being able to access generic
documentation on generic pin config properties.
> *) as Geert already pointed out, we may need dedicated subnodes to
> specify those pin configuration flags, not only because of what Chris
> said, but because pinconf_generic_dt_subnode_to_map() wants "pins" or
> "groups" to be there in the subnode, and in our pin multiplexing
> sub-nodes we only have "pinmux" property (say: we cannot specify
> pin_conf flags in the same sub-node where we describe pin
> multiplexing, we always need a dedicated sub-node).
> Chris and Geert gave some examples in their replies on how that would
> like, and how it makes the bindings a little more complex.
Very little more complex, and actually it could be argued that this
is exactly why subnodes exist: to be able to have different pin config
on pins. I think it is very readable.
> *) those flags, according to Chris, won't be used in RZ/A2, and
> reasonably not in any other RZ device. Do we want to add them to the
> generic bindings, being them so specific to this hardware platform?
I have seen so much stuff that people say is "necessarily different"
for their platform. It turns our that silicon IO and solid state physics
isn't that much different between systems. The same things invariably
pop up in several chips.
Hell this was what people said about this whole subsystem from the
beginning: pin control is so necessarily different that there is no point
in trying to create an abstraction for it.
If I had listened to that kind of advice we wouldn't be where we are today.
And that said, I have already pointed out that two of them already
exist in the pin control subsystem (PIN_CONFIG*). Because other SoCs
are doing similar things.
> One thing I suggest considering is to get rid of those flags, at
> least in bindings, and introduce 3 variants for each pin multiplexing
> function identifier.
>
> Say:
> include/dt-bindings/pinctrl/r7s72100-pinctrl.h:
> #define MUX_1 (1 << 16)
> #define MUX_1_BIDIR (1 << 16 | 1 << 24)
> #define MUX_1_SWIO_IN (1 << 16 | 2 << 24)
> #define MUX_1_SWIO_OUT (1 << 16 | 3 << 24)
> ...
> #define MUX_8 (8 << 16)
> #define MUX_8_BIDIR (8 << 16 | 1 << 24)
> ....
I understand they can be made more beautiful, but in my view
that is putting make up on a pig, I want generic pin config for these
things.
>> What is wrong in doing this with generic pin config using
>> PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT
>> (ignoring the argument)?
>>
>> In the device tree use input-enable and add a new output-enable
>> (with unspecified value) with proper description and DT bindings?
>>
>> And if you think these have no general applicability, by the end
>> of the day they are *still* pin config, not magic flags we can choose to
>> toss in with the muxing, so you can do what the Qualcomm driver
>> does and add custom pin configurations extending the generic
>> pin config, see drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
>> qcom,pull-up-strength etc.
>>
>
> I see, but that custom pin configuration flag can be applied
> independently from pin muxing procedure and it can be applied to pins
> while they're configured in GPIO mode.
See "GPIO mode pitfalls" in Documentation/pinctrl.txt
I've been over this hardware lingo so many times already.
It is not about "GPIO" at all, it is about pin configuration. The
generic pin config was not invented for GPIO, it was just recently
that we started to provide pin config back-ends for GPIO. Only
Intel do that so far.
> Our "flags" are not of that nature, and only apply to some register
> setting during pinmux, as I hopefully tried to clarify above.
And that is a driver semantic. Or even a subsystem semantic. No
big deal, accumulate such writes in the driver and apply it all when you have
it all available no matter if pin multiplexing or pin config happens first?
Surely this is just a hardware pecularity, then it warrants some special
driver code.
If you definately feel you must get a call from the pin control core setting
up muxing and config at the same time we need to think of a way to
augment the pin control core if necessary?
The fact that Linux pin control subsystem semantics you don't
like does not affect the relevant device tree bindings.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
From: Guochun Mao @ 2017-03-30 8:23 UTC (permalink / raw)
To: Boris Brezillon, Marek Vasut
Cc: Mark Rutland, devicetree, Guochun Mao, Richard Weinberger,
Russell King, linux-kernel, Rob Herring, linux-mtd,
Matthias Brugger, linux-mediatek, Cyrille Pitchen,
David Woodhouse, linux-arm-kernel
In-Reply-To: <1490862222-723-1-git-send-email-guochun.mao@mediatek.com>
when nor's size larger than 16MByte, nor and controller should
enter 4Byte mode simultaneously.
Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
---
drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
index e661877..05cd8a8 100644
--- a/drivers/mtd/spi-nor/mtk-quadspi.c
+++ b/drivers/mtd/spi-nor/mtk-quadspi.c
@@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
/* We only handle 1 byte */
ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
break;
+ case SPINOR_OP_EN4B:
+ /* Set nor controller to 4-byte address mode,
+ * and simultaneously set nor flash.
+ * This case should cooperate with default operation.
+ */
+ writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
+ mt8173_nor->base + MTK_NOR_DUAL_REG);
default:
ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
if (ret)
--
1.7.9.5
^ permalink raw reply related
* [PATCH V1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
From: Guochun Mao @ 2017-03-30 8:23 UTC (permalink / raw)
To: Boris Brezillon, Marek Vasut
Cc: Mark Rutland, devicetree, Richard Weinberger, Russell King,
linux-kernel, Rob Herring, linux-mtd, Matthias Brugger,
linux-mediatek, Cyrille Pitchen, David Woodhouse,
linux-arm-kernel
Guochun Mao (1):
mtd: mtk-nor: set controller to 4B mode with large capacity flash
drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
1 file changed, 7 insertions(+)
--
1.9.1
^ permalink raw reply
* Re: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD driver
From: Lucas Stach @ 2017-03-30 8:22 UTC (permalink / raw)
To: Lothar Waßmann
Cc: A.S. Dong, devicetree@vger.kernel.org,
patchwork-lst@pengutronix.de, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170330090833.09ac3c33@ipc1.ka-ro>
Am Donnerstag, den 30.03.2017, 09:08 +0200 schrieb Lothar Waßmann:
> Hi,
>
> On Wed, 29 Mar 2017 18:13:46 +0200 Lucas Stach wrote:
> > Am Mittwoch, den 29.03.2017, 16:08 +0000 schrieb A.S. Dong:
> > > Hi Lucas,
> > >
> > > > -----Original Message-----
> > > > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > > > Sent: Thursday, March 23, 2017 10:44 PM
> > > > To: Shawn Guo
> > > > Cc: Fabio Estevam; A.S. Dong; devicetree@vger.kernel.org; linux-arm-
> > > > kernel@lists.infradead.org; kernel@pengutronix.de; patchwork-
> > > > lst@pengutronix.de
> > > > Subject: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD
> > > > driver
> > > >
> > > > On i.MX6QP, due to hardware erratum ERR009619, the PRE clocks may be
> > > > stalled during the power up sequencing of the PU power domain. As this may
> > > > lead to a complete loss of display output, the recommended workaround is
> > > > to keep the PU domain enabled during normal system operation.
> > > >
> > > > Implement this by rejecting the domain power down request on the affected
> > > > SoC.
> > > >
> > > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > > ---
> > > > drivers/soc/imx/gpc.c | 19 +++++++++++++++++++
> > > > 1 file changed, 19 insertions(+)
> > > >
> > > > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c index
> > > > 4294287e5f6c..599e1e46f694 100644
> > > > --- a/drivers/soc/imx/gpc.c
> > > > +++ b/drivers/soc/imx/gpc.c
> > > > @@ -45,6 +45,7 @@ struct imx_pm_domain {
> > > > unsigned int reg_offs;
> > > > signed char cntr_pdn_bit;
> > > > unsigned int ipg_rate_mhz;
> > > > + bool allow_dynamic_pd;
> > > > };
> > > >
> > > > static inline struct imx_pm_domain *
> > > > @@ -59,6 +60,9 @@ static int imx6_pm_domain_power_off(struct
> > > > generic_pm_domain *genpd)
> > > > int iso, iso2sw;
> > > > u32 val;
> > > >
> > > > + if (!pd->allow_dynamic_pd)
> > > > + return -EBUSY;
> > > > +
> > > > /* Read ISO and ISO2SW power down delays */
> > > > regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
> > > > iso = val & 0x3f;
> > > > @@ -255,6 +259,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > > > },
> > > > .reg_offs = 0x260,
> > > > .cntr_pdn_bit = 0,
> > > > + .allow_dynamic_pd = true,
> > > > }, {
> > > > .base = {
> > > > .name = "DISPLAY",
> > > > @@ -263,23 +268,33 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > > > },
> > > > .reg_offs = 0x240,
> > > > .cntr_pdn_bit = 4,
> > > > + .allow_dynamic_pd = true,
> > >
> > > Just a Nitpick, besides shawn's comment in another mail,
> > > if we use a domain flag like IMX_PD_ALWAYS_ON set by SoC errata flag,
> > > then probably we can save all the default allow_dynamic_pd lines.
> > > This also release the life when adding new domains.
> >
> > If other things like that show up we can certainly switch to a flags
> > field. In the meantime I like that the current style is more explicit
> > about it.
> >
> Since the purpose of the driver is all about dynamic power management,
> I would rather add a 'disable_dynamic_pd' for the case(s) where it's
> not allowed, rather than having to state the obvious over and over
> again.
Convincing argument. I'll change that in v2.
Regards,
Lucas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5 v3] iio: xoadc: augment DT bindings a bit
From: Peter Meerwald-Stadler @ 2017-03-30 8:18 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170330080541.4065-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6134 bytes --]
> In order to accommodate in a logical manner for the premuxed channels
> in PM8921 and the similarly addressed channels in later PMICs, we
> need a twocell arrangement with premux and analog mux setting as
> a tuple to uniquely identify a hardware channel.
>
> These bindings are not yet in use, so it should be fine to augment
> them before we actually start using it in drivers and device trees.
nitpicking below
> This scheme came out of lengthy discussions and reverse-engineering
> and reading of the few information sources we have.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v2->v3:
> - Drop leading zeroes on unit addresses.
> ChangeLog v1->v2:
> - Name nodes with <01 02> in a foo@0102 pattern.
> - Minor spelling nits.
> - Delete flimsy leftover docs from an interrim development path.
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 76 ++++++++++++----------
> 1 file changed, 42 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> index 53cd146d8096..69c404112df1 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -19,32 +19,42 @@ Required properties:
> with PMIC variant but is typically something like 2.2 or 1.8V.
>
> The following required properties are standard for IO channels, see
> -iio-bindings.txt for more details:
> +iio-bindings.txt for more details, but noitice that this particular
notice
> +ADC has a special adressing scheme that require two cells for
addressing
> +identifying each ADC channel:
>
> -- #address-cells: should be set to <1>
> +- #address-cells: should be set to <2>, the first cell is the
> + prescaler (on PM8058) or premux (on PM8921) with two valid bits
> + so legal values are 0x00, 0x01 or 0x02. The second cell
> + is the main analog mux setting (0x00..0x0f). The combination
> + of prescaler/premux and analog mux uniquely addresses a hardware
> + channel on all systems.
>
> - #size-cells: should be set to <0>
>
> -- #io-channel-cells: should be set to <1>
> +- #io-channel-cells: should be set to <2>, again the cells are
> + precaler or premux followed by the analog muxing line.
>
> - interrupts: should refer to the parent PMIC interrupt controller
> and reference the proper ADC interrupt.
>
> Required subnodes:
>
> -The ADC channels are configured as subnodes of the ADC. Since some of
> -them are used for calibrating the ADC, these nodes are compulsory:
> +The ADC channels are configured as subnodes of the ADC.
> +
> +Since some of them are used for calibrating the ADC, these nodes are
> +compulsory:
>
> adc-channel@c {
> - reg = <0x0c>;
> + reg = <0x00 0x0c>;
> };
>
> adc-channel@d {
> - reg = <0x0d>;
> + reg = <0x00 0x0d>;
> };
>
> adc-channel@f {
> - reg = <0x0f>;
> + reg = <0x00 0x0f>;
> };
>
> These three nodes are used for absolute and ratiometric calibration
> @@ -52,13 +62,13 @@ and only need to have these reg values: they are by hardware definition
> 1:1 ratio converters that sample 625, 1250 and 0 milliV and create
> an interpolation calibration for all other ADCs.
>
> -Optional subnodes: any channels other than channel 0x0c, 0x0d and
> -0x0f are optional.
> +Optional subnodes: any channels other than channels [0x00 0x0c],
> +[0x00 0x0d] and [0x00 0x0f] are optional.
>
> Required channel node properties:
>
> - reg: should contain the hardware channel number in the range
> - 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> + 0 .. 0xff (8 bits).
>
> Optional channel node properties:
>
> @@ -94,56 +104,54 @@ Example:
> xoadc: xoadc@197 {
> compatible = "qcom,pm8058-adc";
> reg = <0x197>;
> - interrupt-parent = <&pm8058>;
> - interrupts = <76 1>;
> - #address-cells = <1>;
> + interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <2>;
> #size-cells = <0>;
> - #io-channel-cells = <1>;
> + #io-channel-cells = <2>;
>
> vcoin: adc-channel@0 {
> - reg = <0x00>;
> + reg = <0x00 0x00>;
> };
> vbat: adc-channel@1 {
> - reg = <0x01>;
> + reg = <0x00 0x01>;
> };
> dcin: adc-channel@2 {
> - reg = <0x02>;
> + reg = <0x00 0x02>;
> };
> ichg: adc-channel@3 {
> - reg = <0x03>;
> + reg = <0x00 0x03>;
> };
> vph_pwr: adc-channel@4 {
> - reg = <0x04>;
> + reg = <0x00 0x04>;
> };
> usb_vbus: adc-channel@a {
> - reg = <0x0a>;
> + reg = <0x00 0x0a>;
> };
> die_temp: adc-channel@b {
> - reg = <0x0b>;
> + reg = <0x00 0x0b>;
> };
> ref_625mv: adc-channel@c {
> - reg = <0x0c>;
> + reg = <0x00 0x0c>;
> };
> ref_1250mv: adc-channel@d {
> - reg = <0x0d>;
> + reg = <0x00 0x0d>;
> };
> ref_325mv: adc-channel@e {
> - reg = <0x0e>;
> + reg = <0x00 0x0e>;
> };
> ref_muxoff: adc-channel@f {
> - reg = <0x0f>;
> + reg = <0x00 0x0f>;
> };
> };
>
> -
> /* IIO client node */
> iio-hwmon {
> compatible = "iio-hwmon";
> - io-channels = <&xoadc 0x01>, /* Battery */
> - <&xoadc 0x02>, /* DC in (charger) */
> - <&xoadc 0x04>, /* VPH the main system voltage */
> - <&xoadc 0x0b>, /* Die temperature */
> - <&xoadc 0x0c>, /* Reference voltage 1.25V */
> - <&xoadc 0x0d>, /* Reference voltage 0.625V */
> - <&xoadc 0x0e>; /* Reference voltage 0.325V */
> + io-channels = <&xoadc 0x00 0x01>, /* Battery */
> + <&xoadc 0x00 0x02>, /* DC in (charger) */
> + <&xoadc 0x00 0x04>, /* VPH the main system voltage */
> + <&xoadc 0x00 0x0b>, /* Die temperature */
> + <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
> + <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
> + <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
> };
>
--
Peter Meerwald-Stadler
Mobile: +43 664 24 44 418
^ permalink raw reply
* Re: [PATCH v1 0/8] clk: meson: gxbb: more clock controller update for audio support
From: Neil Armstrong @ 2017-03-30 8:15 UTC (permalink / raw)
To: Michael Turquette, Jerome Brunet, Stephen Boyd, Kevin Hilman,
Carlo Caione
Cc: linux-clk, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <149082017390.31513.12254031076684821992@resonance>
On 03/29/2017 10:42 PM, Michael Turquette wrote:
> Hi Jerome,
>
> Adding Neil Armstong to Cc.
>
> Quoting Jerome Brunet (2017-03-28 07:45:57)
>> The patchset is the 2nd round of update to the meson gxbb clock controller
>> to add initial audio support. The patchset is based on clk-next.
>>
>> There is not much out of the ordinary here (adding new clocks and exposing
>> them) except maybe for 2 patches:
>> Patch #2: Adds a safety check while registering clocks to protect against
>> holes in clk_hw_onecell_data, if it ever happens. Same thing is
>> done for the meson8b clock controller.
>> Patch #3: Adds a new clock divider driver to implement the necessary
>> policy for the i2s master clock (see patch changelog)
>>
>> This patchset has been test on the gxbb p200 and gxl p230.
>
> First off, this series looks fine to me. Please add,
>
> Acked-by: Michael Turquette <mturquette@baylibre.com>
>
> Secondly, it seems the AmLogic clock drivers have mostly calmed down and
> things are in the "add new clocks when we need them" phase, which is
> nice. Since you and Neil are doing a lot of this work, might I suggest
> that you both start collecting patches for the AmLogic/meson clock
> drivers begin submitting pull requests to Stephen and myself?
>
> As usual the rules are the same as always: all patches in the PR must
> first be posted for review on the list. PRs should correspond to signed
> tags. Stephen and I might ignore PRs sent after -rc4, and will
> definitely ignore PRs sent after -rc6 since we want some stabilization
> time before the merge window. Base your branch on -rc1, not on clk-next.
>
> Also feel free to submit a patch to MAINTAINERS with either one or both
> of you maintaining the meson clk stuff, assuming that you're OK to
> review all of those patches and collect them into a PR.
>
> Thoughts?
Thanks Mike, I'll be glad to co-maintain this with jerome !
Neil
>
> If it sounds good to you then I suggest grabbing the clk-meson branch
> from the clk tree and using that as a baseline for your first PR. In the
> future you'll just Linus' -rc1, but I have already created a branch for
> this cycle. You can apply these 8 patches with my Ack and send a PR by
> -rc6 (possibly with other stuff collected from Martin, etc).
Acked !
>
> Thanks,
> Mike
>
>>
>> Jerome Brunet (8):
>> dt-bindings: clock: gxbb: expose spdif clock gates
>> clk: meson: gxbb: protect against holes in the onecell_data array
>> clk: meson: add audio clock divider support
>> clk: meson: gxbb: add cts_amclk
>> clk: meson: gxbb: add cts_mclk_i958
>> clk: meson: gxbb: add cts_i958 clock
>> dt-bindings: clock: gxbb: expose i2s master clock
>> dt-bindings: clock: gxbb: expose spdif master clock
>>
>> drivers/clk/meson/Makefile | 2 +-
>> drivers/clk/meson/clk-audio-divider.c | 149 ++++++++++++++++++++++++++++++++++
>> drivers/clk/meson/clkc.h | 10 +++
>> drivers/clk/meson/gxbb.c | 144 ++++++++++++++++++++++++++++++++
>> drivers/clk/meson/gxbb.h | 13 ++-
>> include/dt-bindings/clock/gxbb-clkc.h | 5 ++
>> 6 files changed, 319 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/clk/meson/clk-audio-divider.c
>>
>> --
>> 2.9.3
>>
^ permalink raw reply
* Re: [PATCH v3 3/7] arm: dts: dt-bindings: Add Renesas RZ pinctrl header
From: Linus Walleij @ 2017-03-30 8:15 UTC (permalink / raw)
To: Chris Brandt
Cc: Jacopo Mondi, Bjorn Andersson, Geert Uytterhoeven,
Laurent Pinchart, Rob Herring, Mark Rutland, Russell King,
Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <SG2PR06MB11659AB956F83E8DCE2C9AA18A350@SG2PR06MB1165.apcprd06.prod.outlook.com>
On Wed, Mar 29, 2017 at 4:55 PM, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Wednesday, March 29, 2017, Linus Walleij wrote:
>> On Fri, Mar 24, 2017 at 4:22 PM, Jacopo Mondi <jacopo+renesas@jmondi.org>
>> wrote:
>>
>> > Add dt-bindings for Renesas r7s72100 pin controller header file.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>
>> > +/*
>> > + * Pin is bi-directional.
>> > + * An alternate function that needs both input/output functionalities
>> > +shall
>> > + * be configured as bidirectional.
>> > + * Eg. SDA/SCL pins of an I2c interface.
>> > + */
>> > +#define BI_DIR (1 << 3)
>>
>> Any specific reason why this should not simply be added to
>> include/linux/pinctrl/pinconf-generic.h
>> as PIN_CONFIG_BIDIRECTIONAL and parsed in drivers/pinctrl/pinconf-
>> generic.c from the (new) DT property "bidirectional" simply?
>
> I see your point. It would cut down from every driver out there
> inventing some new property or config instead of everyone just sharing
> a fixed set.
> Maybe someone else out there will end up having a need for a
> "bidirectional" option.
I was thinking about that one. It is a bit weird electrically, like what
kind of electronics is really bidirectional?
It seems like a fancy name for open drain/open source, what we
call "single ended" configuration. (See docs in
Documentation/gpio/driver.txt)
It would be great if you could check if that is what they mean,
actually.
> But, what do we do for Ethernet? All the pins are "normal" except just
> the MDIO pin needs to be bidirectional.
I see Geert clarified what we could do here.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v12 00/10] mux controller abstraction and iio/i2c muxes
From: Greg Kroah-Hartman @ 2017-03-30 8:09 UTC (permalink / raw)
To: Peter Rosin
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c, devicetree, linux-kernel, linux-iio,
linux-doc, Andrew Morton, Colin Ian King, Paul Gortmaker
In-Reply-To: <c321dad0-4c0e-b192-ee93-45359e29f61b@axentia.se>
On Thu, Mar 30, 2017 at 09:34:52AM +0200, Peter Rosin wrote:
> On 2017-03-27 16:21, Peter Rosin wrote:
> > Hi Greg!
> >
> > Please apply.
> >
>
> *snip snip*
>
> > v10 -> v11 changes
> > - added a new patch (12) with a fix for messed up error path reported
> > by Paul Gortmaker.
>
> Oops, should be Dan Carpenter. Sorry about that...
>
> And, I forgot to high-light this:
>
> > v4 -> v5 changes
> > - driver for Analog Devices ADG792A/G, literally the first mux chip
> > I found on the Internet with an i2c interface (that was not a
> > dedicated i2c multiplexer like PCA9547) which I used to verify
> > that the abstractions in the mux core are up to the task. Untested,
> > just proof of concept that at least looks pretty and compiles...
>
> Maybe the patches related to adg792 (last two patches in v12) should
> not be applied? I don't care much either way, your call Greg...
Give me a chance to catch up on reviews, your patch series is behind
400+ other emails...
greg k-h
^ permalink raw reply
* [PATCH 1/5 v3] iio: xoadc: augment DT bindings a bit
From: Linus Walleij @ 2017-03-30 8:05 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA, Rob Herring
Cc: Linus Walleij, devicetree-u79uwXL29TY76Z2rM5mHXA
In order to accommodate in a logical manner for the premuxed channels
in PM8921 and the similarly addressed channels in later PMICs, we
need a twocell arrangement with premux and analog mux setting as
a tuple to uniquely identify a hardware channel.
These bindings are not yet in use, so it should be fine to augment
them before we actually start using it in drivers and device trees.
This scheme came out of lengthy discussions and reverse-engineering
and reading of the few information sources we have.
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
ChangeLog v2->v3:
- Drop leading zeroes on unit addresses.
ChangeLog v1->v2:
- Name nodes with <01 02> in a foo@0102 pattern.
- Minor spelling nits.
- Delete flimsy leftover docs from an interrim development path.
---
.../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 76 ++++++++++++----------
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
index 53cd146d8096..69c404112df1 100644
--- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
@@ -19,32 +19,42 @@ Required properties:
with PMIC variant but is typically something like 2.2 or 1.8V.
The following required properties are standard for IO channels, see
-iio-bindings.txt for more details:
+iio-bindings.txt for more details, but noitice that this particular
+ADC has a special adressing scheme that require two cells for
+identifying each ADC channel:
-- #address-cells: should be set to <1>
+- #address-cells: should be set to <2>, the first cell is the
+ prescaler (on PM8058) or premux (on PM8921) with two valid bits
+ so legal values are 0x00, 0x01 or 0x02. The second cell
+ is the main analog mux setting (0x00..0x0f). The combination
+ of prescaler/premux and analog mux uniquely addresses a hardware
+ channel on all systems.
- #size-cells: should be set to <0>
-- #io-channel-cells: should be set to <1>
+- #io-channel-cells: should be set to <2>, again the cells are
+ precaler or premux followed by the analog muxing line.
- interrupts: should refer to the parent PMIC interrupt controller
and reference the proper ADC interrupt.
Required subnodes:
-The ADC channels are configured as subnodes of the ADC. Since some of
-them are used for calibrating the ADC, these nodes are compulsory:
+The ADC channels are configured as subnodes of the ADC.
+
+Since some of them are used for calibrating the ADC, these nodes are
+compulsory:
adc-channel@c {
- reg = <0x0c>;
+ reg = <0x00 0x0c>;
};
adc-channel@d {
- reg = <0x0d>;
+ reg = <0x00 0x0d>;
};
adc-channel@f {
- reg = <0x0f>;
+ reg = <0x00 0x0f>;
};
These three nodes are used for absolute and ratiometric calibration
@@ -52,13 +62,13 @@ and only need to have these reg values: they are by hardware definition
1:1 ratio converters that sample 625, 1250 and 0 milliV and create
an interpolation calibration for all other ADCs.
-Optional subnodes: any channels other than channel 0x0c, 0x0d and
-0x0f are optional.
+Optional subnodes: any channels other than channels [0x00 0x0c],
+[0x00 0x0d] and [0x00 0x0f] are optional.
Required channel node properties:
- reg: should contain the hardware channel number in the range
- 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
+ 0 .. 0xff (8 bits).
Optional channel node properties:
@@ -94,56 +104,54 @@ Example:
xoadc: xoadc@197 {
compatible = "qcom,pm8058-adc";
reg = <0x197>;
- interrupt-parent = <&pm8058>;
- interrupts = <76 1>;
- #address-cells = <1>;
+ interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
+ #address-cells = <2>;
#size-cells = <0>;
- #io-channel-cells = <1>;
+ #io-channel-cells = <2>;
vcoin: adc-channel@0 {
- reg = <0x00>;
+ reg = <0x00 0x00>;
};
vbat: adc-channel@1 {
- reg = <0x01>;
+ reg = <0x00 0x01>;
};
dcin: adc-channel@2 {
- reg = <0x02>;
+ reg = <0x00 0x02>;
};
ichg: adc-channel@3 {
- reg = <0x03>;
+ reg = <0x00 0x03>;
};
vph_pwr: adc-channel@4 {
- reg = <0x04>;
+ reg = <0x00 0x04>;
};
usb_vbus: adc-channel@a {
- reg = <0x0a>;
+ reg = <0x00 0x0a>;
};
die_temp: adc-channel@b {
- reg = <0x0b>;
+ reg = <0x00 0x0b>;
};
ref_625mv: adc-channel@c {
- reg = <0x0c>;
+ reg = <0x00 0x0c>;
};
ref_1250mv: adc-channel@d {
- reg = <0x0d>;
+ reg = <0x00 0x0d>;
};
ref_325mv: adc-channel@e {
- reg = <0x0e>;
+ reg = <0x00 0x0e>;
};
ref_muxoff: adc-channel@f {
- reg = <0x0f>;
+ reg = <0x00 0x0f>;
};
};
-
/* IIO client node */
iio-hwmon {
compatible = "iio-hwmon";
- io-channels = <&xoadc 0x01>, /* Battery */
- <&xoadc 0x02>, /* DC in (charger) */
- <&xoadc 0x04>, /* VPH the main system voltage */
- <&xoadc 0x0b>, /* Die temperature */
- <&xoadc 0x0c>, /* Reference voltage 1.25V */
- <&xoadc 0x0d>, /* Reference voltage 0.625V */
- <&xoadc 0x0e>; /* Reference voltage 0.325V */
+ io-channels = <&xoadc 0x00 0x01>, /* Battery */
+ <&xoadc 0x00 0x02>, /* DC in (charger) */
+ <&xoadc 0x00 0x04>, /* VPH the main system voltage */
+ <&xoadc 0x00 0x0b>, /* Die temperature */
+ <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
+ <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
+ <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
};
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 2/4] ARM: dts: rockchip: add ARM Mali GPU node for rk3288
From: Enric Balletbo i Serra @ 2017-03-30 8:03 UTC (permalink / raw)
To: Guillaume Tucker, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sjoerd Simons, John Reitan
In-Reply-To: <46d14d3c969a35e800b1c06da0ddb652986e6827.1490789802.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 29/03/17 14:44, Guillaume Tucker wrote:
> Add Mali GPU device tree node for the rk3288 SoC, with devfreq
> opp table.
>
> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> arch/arm/boot/dts/rk3288.dtsi | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index df8a0dbe9d91..213224ea309e 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -43,6 +43,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/clock/rk3288-cru.h>
> +#include <dt-bindings/power/rk3288-power.h>
> #include <dt-bindings/thermal/thermal.h>
> #include <dt-bindings/power/rk3288-power.h>
> #include <dt-bindings/soc/rockchip,boot-mode.h>
> @@ -227,6 +228,28 @@
> ports = <&vopl_out>, <&vopb_out>;
> };
>
> + gpu: mali@ffa30000 {
> + compatible = "arm,mali-midgard";
> + reg = <0xffa30000 0x10000>;
> + interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "JOB", "MMU", "GPU";
> + clocks = <&cru ACLK_GPU>;
> + clock-names = "clk_mali";
> + operating-points = <
> + /* KHz uV */
> + 100000 950000
> + 200000 950000
> + 300000 1000000
> + 400000 1100000
> + 500000 1200000
> + 600000 1250000
> + >;
> + power-domains = <&power RK3288_PD_GPU>;
> + status = "disabled";
> + };
> +
> sdmmc: dwmmc@ff0c0000 {
> compatible = "rockchip,rk3288-dw-mshc";
> max-frequency = <150000000>;
>
This works on a veyron-minnie and a veyron-jerry, so
Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
--
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 1/4] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Enric Balletbo i Serra @ 2017-03-30 8:00 UTC (permalink / raw)
To: Guillaume Tucker, Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Sjoerd Simons, John Reitan
In-Reply-To: <db45d0d68957d699f13a0d92f4f84d8ebfd0270e.1490789802.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 29/03/17 14:44, Guillaume Tucker wrote:
> The ARM Mali Midgard GPU family is present in a number of SoCs
> from many different vendors such as Samsung Exynos and Rockchip.
>
> Import the device tree bindings documentation from the r16p0
> release of the Mali Midgard GPU kernel driver:
>
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
>
> The following optional bindings have been omitted in this initial
> version as they are only used in very specific cases:
>
> * snoop_enable_smc
> * snoop_disable_smc
> * jm_config
> * power_model
> * system-coherency
> * ipa-model
>
> The example has been simplified accordingly.
>
> The compatible string definition has been limited to
> "arm,mali-midgard" to avoid checkpatch.pl warnings and to match
> what the driver actually expects (as of r16p0 out-of-tree).
>
> CC: John Reitan <john.reitan-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> .../devicetree/bindings/gpu/arm,mali-midgard.txt | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> new file mode 100644
> index 000000000000..da8fc6d21bbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -0,0 +1,53 @@
> +#
> +# (C) COPYRIGHT 2013-2016 ARM Limited.
> +# Copyright (C) 2017 Collabora Ltd
> +#
> +# This program is free software and is provided to you under the terms of the
> +# GNU General Public License version 2 as published by the Free Software
> +# Foundation, and any use by you of this program is subject to the terms
> +# of such GNU licence.
> +#
> +
> +
> +ARM Mali Midgard GPU
> +====================
> +
> +Required properties:
> +
> +- compatible : Should be "arm,mali-midgard".
> +- reg : Physical base address of the device and length of the register area.
> +- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
> +- interrupt-names : Contains the names of IRQ resources in the order they were
> + provided in the interrupts property. Must contain: "JOB, "MMU", "GPU".
> +
> +Optional:
> +
> +- clocks : Phandle to clock for the Mali Midgard device.
> +- clock-names : Shall be "clk_mali".
> +- mali-supply : Phandle to regulator for the Mali device. Refer to
> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
> + for details.
> +
> +Example for a Mali-T602:
> +
> +gpu@0xfc010000 {
> + compatible = "arm,mali-midgard";
> + reg = <0xfc010000 0x4000>;
> + interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
> + interrupt-names = "JOB", "MMU", "GPU";
> +
> + clocks = <&pclk_mali>;
> + clock-names = "clk_mali";
> + mali-supply = <&vdd_mali>;
> + operating-points = <
> + /* KHz uV */
> + 533000 1250000,
> + 450000 1150000,
> + 400000 1125000,
> + 350000 1075000,
> + 266000 1025000,
> + 160000 925000,
> + 100000 912500,
> + >;
> +};
>
This works with veyron-minnie and veyron-jerry too, so
Tested-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
--
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 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-03-30 7:43 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Richard Purdie, Jacek Anaszewski, linux-kernel,
linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170330000955.GP20094@minitux>
[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]
Hi!
> > > There is a binding for ti,lp55xx, but there's nothing I can reuse from
> > > that binding...because it's completely different hardware.
> >
> > Agreed, if you drop the pattern stuff from the binding, at least for now.
>
> I do not have a strong preference to expose these knobs in devicetree
> and I do fear that finding some common "pattern" bindings that suits
> everyone will be very difficult.
>
> So I'll drop them from the binding for now.
Ok.
> > If you want driver merged quickly, I believe the best way would be to
> > leave out pattern support for now. We can merge the basic driver
> > easily to 4.12.
> >
>
> I'm not that much in a hurry and would rather see that we resolve any
> outstanding issues with the implementation of the pattern handling.
Ok, good.
> But regardless of this we still have the problem that the typical
> Qualcomm PMIC has 8 LPG-blocks and any triple could be driving a
> RGB-LED. So we would have to create some sort of in-driver-wrapper
> around any three instances exposing them as a single LED to the user.
Yes, I believe we should do the wrapping. In N900 case,
> I rather expose the individual channels and make sure that when we
> trigger a blink operation or enable a pattern (i.e. the two operations
> that do require synchronization) we will perform that synchronization
> under the hood.
First, we need a way to tell userspace which LEDs are synchronized,
because otherwise it will be confusing.
Second, there are more issues than just patterns with the RGB
LED. Most important is ability to set particular colors. You want to
set the RGB LED to "white", but that does not mean you can set
red=green=blue=1.0. You want color to look the same on LCD and on the
LED, which means coefficients for white and some kind of function for
brightness-to-PWM conversion.
> > Incremental patches sound like a good idea, yes.
> >
> > I'd say that testing with actual RGB LED is not a requirement... as
> > long as we design reasonable interface where the synchronizaction will
> > be easy.
> >
>
> As this relates to the board layout (which LPG-channels are hooked to a
> RGB) I think it makes sense to expose a mechanism in devicetree to
> indicate which channels should have their pattern/blink synchronized.
>
> We should be able to extend the LUT (the hardware that actually
> implements the pattern-walker logic) with a DT-property like:
>
> qcom,synchronize-group-0 = <1, 2, 3>;
> qcom,synchronize-group-1 = <5, 6, 7>;
>
> And whenever we configure a pattern involving one of the affected LEDs
> from a group we start all of them.
Yes we need some kind of grouping.
Additional complexity in the N900 case... groups can actually be
configured at run time. Original Maemo used that ability to group 6
keyboard backlight leds, and then run pattern on them. OTOH... I don't
think we _need_ to support that functionality.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCHv5 11/11] arm: sti: update sti-cec for CEC notifier support
From: Benjamin Gaignard @ 2017-03-30 7:41 UTC (permalink / raw)
To: Hans Verkuil
Cc: devicetree, moderated list:ARM/S5P EXYNOS AR..., Russell King,
Krzysztof Kozlowski, Patrice.chotard, Javier Martinez Canillas,
Hans Verkuil, dri-devel@lists.freedesktop.org, Daniel Vetter,
Marek Szyprowski, linux-media@vger.kernel.org
In-Reply-To: <20170329141543.32935-12-hverkuil@xs4all.nl>
+ Patrice for sti DT
2017-03-29 16:15 GMT+02:00 Hans Verkuil <hverkuil@xs4all.nl>:
> From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
>
> To use CEC notifier sti CEC driver needs to get phandle
> of the hdmi device.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> CC: devicetree@vger.kernel.org
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 12 ------------
> arch/arm/boot/dts/stih410.dtsi | 13 +++++++++++++
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index d753ac36788f..044184580326 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -742,18 +742,6 @@
> <&clk_s_c0_flexgen CLK_ETH_PHY>;
> };
>
> - cec: sti-cec@094a087c {
> - compatible = "st,stih-cec";
> - reg = <0x94a087c 0x64>;
> - clocks = <&clk_sysin>;
> - clock-names = "cec-clk";
> - interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
> - interrupt-names = "cec-irq";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_cec0_default>;
> - resets = <&softreset STIH407_LPM_SOFTRESET>;
> - };
> -
> rng10: rng@08a89000 {
> compatible = "st,rng";
> reg = <0x08a89000 0x1000>;
> diff --git a/arch/arm/boot/dts/stih410.dtsi b/arch/arm/boot/dts/stih410.dtsi
> index 3c9672c5b09f..21fe72b183d8 100644
> --- a/arch/arm/boot/dts/stih410.dtsi
> +++ b/arch/arm/boot/dts/stih410.dtsi
> @@ -281,5 +281,18 @@
> <&clk_s_c0_flexgen CLK_ST231_DMU>,
> <&clk_s_c0_flexgen CLK_FLASH_PROMIP>;
> };
> +
> + sti-cec@094a087c {
> + compatible = "st,stih-cec";
> + reg = <0x94a087c 0x64>;
> + clocks = <&clk_sysin>;
> + clock-names = "cec-clk";
> + interrupts = <GIC_SPI 140 IRQ_TYPE_NONE>;
> + interrupt-names = "cec-irq";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_cec0_default>;
> + resets = <&softreset STIH407_LPM_SOFTRESET>;
> + hdmi-phandle = <&sti_hdmi>;
> + };
> };
> };
> --
> 2.11.0
>
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v12 00/10] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2017-03-30 7:34 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker
In-Reply-To: <1490624525-15865-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 2017-03-27 16:21, Peter Rosin wrote:
> Hi Greg!
>
> Please apply.
>
*snip snip*
> v10 -> v11 changes
> - added a new patch (12) with a fix for messed up error path reported
> by Paul Gortmaker.
Oops, should be Dan Carpenter. Sorry about that...
And, I forgot to high-light this:
> v4 -> v5 changes
> - driver for Analog Devices ADG792A/G, literally the first mux chip
> I found on the Internet with an i2c interface (that was not a
> dedicated i2c multiplexer like PCA9547) which I used to verify
> that the abstractions in the mux core are up to the task. Untested,
> just proof of concept that at least looks pretty and compiles...
Maybe the patches related to adg792 (last two patches in v12) should
not be applied? I don't care much either way, your call Greg...
Cheers,
peda
^ permalink raw reply
* Re: [PATCH 0/2] mtd: spi-nor: add stm32 qspi driver
From: Ludovic BARRE @ 2017-03-30 7:31 UTC (permalink / raw)
To: Cyrille Pitchen, Cyrille Pitchen, Marek Vasut
Cc: Boris Brezillon, Alexandre Torgue,
devicetree-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Brian Norris,
David Woodhouse
In-Reply-To: <5224f3cd-a128-9e72-c0c8-62a137ceeb79-yU5RGvR974pGWvitb5QawA@public.gmane.org>
hi Cyrille
I see your patch series
[PATCH v5 0/6] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories
No problem, I rebase my V2 onto your patch
BR
Ludo
On 03/29/2017 06:51 PM, Cyrille Pitchen wrote:
> Hi Ludovic,
>
> Le 27/03/2017 à 14:54, Ludovic Barre a écrit :
>> From: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
>>
>> This patch set adds a SPI-NOR driver for stm32 QSPI controller.
>> It is a specialized SPI interface for serial Flash devices.
>> It supports 1 or 2 Flash device with single, dual and quad SPI Flash memories.
>>
>> It can operate in any of the following modes:
>> -indirect mode: all the operations are performed using the quadspi
>> registers
>> -read memory-mapped mode: the external Flash memory is mapped to the
>> microcontroller address space and is seen by the system as if it was
>> an internal memory
>>
>> Ludovic Barre (2):
>> dt-bindings: Document the STM32 QSPI bindings
>> mtd: spi-nor: add driver for STM32 quad spi flash controller
>>
>> .../devicetree/bindings/mtd/stm32-quadspi.txt | 45 ++
>> drivers/mtd/spi-nor/Kconfig | 7 +
>> drivers/mtd/spi-nor/Makefile | 1 +
>> drivers/mtd/spi-nor/stm32-quadspi.c | 679 +++++++++++++++++++++
>> 4 files changed, 732 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mtd/stm32-quadspi.txt
>> create mode 100644 drivers/mtd/spi-nor/stm32-quadspi.c
>>
> Just a small word to warn you that I'm likely to ask you to rebase this
> series onto the patch "mtd: spi-nor: introduce more SPI protocols and
> the Dual Transfer Mode". Indeed, I need to synchronize with Marek first
> but I plan to merge this patch within few days.
>
>
> Best regards,
>
> Cyrille
--
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 v4 01/18] dt-bindings: power: battery: add constant-charge-current property
From: Liam Breck @ 2017-03-30 7:30 UTC (permalink / raw)
To: Quentin Schulz; +Cc: Sebastian Reichel, robh+dt, linux-pm, devicetree
In-Reply-To: <614aa4ef-6900-0c56-a364-0ef4e8af2f97@free-electrons.com>
On Wed, Mar 29, 2017 at 11:41 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> Hi,
>
> On 29/03/2017 11:26, Liam Breck wrote:
>> On Wed, Mar 29, 2017 at 12:54 AM, Quentin Schulz
>> <quentin.schulz@free-electrons.com> wrote:
>>> Hi,
>>>
>>> On 29/03/2017 09:39, Liam Breck wrote:
>>>> On Wed, Mar 29, 2017 at 12:09 AM, Quentin Schulz
>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>> Hi Liam,
>>>>>
>>>>> On 29/03/2017 08:55, Liam Breck wrote:
>>>>>> Hi Quentin,
>>>>>>
>>>>>> On Thu, Mar 16, 2017 at 12:42 AM, Liam Breck <liam@networkimprov.net> wrote:
>>>>>>> On Thu, Mar 16, 2017 at 12:03 AM, Quentin Schulz
>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>> Hi Liam,
>>>>>>>>
>>>>>>>> On 16/03/2017 07:27, Liam Breck wrote:
>>>>>>>>> Hi Rob,
>>>>>>>>>
>>>>>>>>> On Wed, Mar 15, 2017 at 6:10 AM, Quentin Schulz
>>>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>>>> Hi Liam,
>>>>>>>>>>
>>>>>>>>>> On 15/03/2017 13:08, Liam Breck wrote:
>>>>>>>>>>> I dropped most of the CCs, pls re-add anyone essential. Use Cc lines
>>>>>>>>>>> in patch description to direct a patch to interested parties and
>>>>>>>>>>> relevant lists. I don't want to see all 19 patches in this series.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Mar 15, 2017 at 3:55 AM, Quentin Schulz
>>>>>>>>>>> <quentin.schulz@free-electrons.com> wrote:
>>>>>>>>>>>> This adds the constant-charge-current property to the list of optional
>>>>>>>>>>>> properties of the battery.
>>>>>>>>>>>>
>>>>>>>>>>>> The constant charge current is critical for batteries as they can't
>>>>>>>>>>>> handle all charge currents.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>>>>>>>>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> v4:
>>>>>>>>>>>> - switch from constant-charge-current-microamp to constant-charge-microamp,
>>>>>>>>>
>>>>>>>>> Sebastian is on record supporting name alignment between DT:battery
>>>>>>>>> properties and enum power_supply_property.
>>>>>>>>>
>>>>>>>>> Could you OK a change back to constant-charge-current-microamp in this patch?
>>>>>>>>>
>>>>>>>>> Note that the following could appear in DT:battery in future:
>>>>>>>>>
>>>>>>>>> constant-charge-current-microamp
>>>>>>>>> constant-charge-current-max-microamp
>>>>>>>>
>>>>>>>> OK. I am actually setting max constant charge current and constant
>>>>>>>> current charge with the same DT property so I might need to adapt my
>>>>>>>> patches.
>>>>>>>
>>>>>>> I suspect you should set battery:*-current-max with DT, as -current is
>>>>>>> "programmed by charger" so seems to be a stat, not a fixed
>>>>>>> characteristic.
>>>>>>
>>>>>> Did you resolve this issue?
>>>>>>
>>>>>
>>>>> Sorry, completely missed your first mail.
>>>>>
>>>>> Constant charge current is actually what I set in the PMIC. The maximum
>>>>> constant charge current is completely PMIC-agnostic in my driver as it
>>>>> is used to tell the user that (s)he shouldn't really have a constant
>>>>> charge current over the maximum limit as the battery might not be able
>>>>> to handle such high current.
>>>>>
>>>>> What I suggest is to have both properties in DT. I'll set the maximum as
>>>>> I do today and we can give the user the ability to set a "default"
>>>>> constant charge current (below maximum constant charge current) in the
>>>>> DT. Maybe we do not want to recharge your battery with the maximum value
>>>>> by default?
>>>>
>>>> The scope here is just static battery characteristics. For the battery
>>>> node, I think constant-charge-current-max-microamp is the relevant
>>>> term.
>>>
>>> If it's only for static battery characteristics, I agree.
>>>
>>>
>>>> If we added both properties, one would be an alias for the
>>>> other, which doesn't seem useful.
>>
>> Meaning if both properties describe static characteristics of the
>> battery, they wouldn't have different meaning.
>>
>>> Hum. Not really an alias. In my driver, I have a maximum which avoids to
>>> set a constant charge current higher than what the battery is supposed
>>> to be able to handle. The maximum can be increased via sysfs if ever the
>>> user decides to go wild (or if (s)he changes the battery for example).
>>> The maximum is never input in any of PMIC registers, it is not dealing
>>> with the PMIC at all.
>>
>> Using the battery's -max as the default for your user-adjustable max
>> sounds sensible. However the user-adjustable max should perhaps appear
>> in a custom sysfs attribute, not
>> /sys/class.../constant_charge_current_max (see comment re regulator).
>>
>
> Why?
Because charger's ccc_max should refer to its electrical
characteristics, not a user-adjustable setting. Maybe
/sys/class.../constant_charge_current_max_local or similar.
>> If the battery changes, the DT battery node should also change, esp if
>> its -max drops. I realize that's not nec trivial.
>>
>
> Disagree. That's definitely not user friendly.
There are ways to field-upgrade the dtb, tho that might not be
workable in all cases :-)
>>> If I have only the max constant charge current in the DT, I'll set the
>>> max and constant charge current with the same DT entry. That's perfectly
>>> fine.
>>
>> I assume the pmic ccc setting is adjustable via
>> /sys/class.../constant_charge_current?
>>
>
> Yes, it is then limited by a user-modifiable constant_charge_current_max.
>
>>> However, what I was thinking is to have a "default" value taken from DT
>>> for constant charge current (which will be below maximum ccc) if ever
>>> someone wants to set a maximum but use a lower ccc value. Anyway, I
>>> guess it's more a "fancy" feature than a requirement (unlike max-ccc).
>>
>> Maybe a lower default ccc than battery's -max could be provided via a
>> % value in the pmic DT node? Then multiply battery -max by that to set
>> ccc.
>>
>
> That's battery-specific, why would you want to put it in the PMIC node?
A % modifier is not too battery-specific. If you want a specific
alternate default ccc, you could certainly put it in the battery node,
and read it from your driver the way power_supply_get_battery_info()
does. But if you are expecting battery changes which alter
characteristics, the less you hard-wire into DT, the better.
>>>> The pmic can report both independently of the battery characteristic,
>>>> and take a driver-specific DT property for
>>>> constant-charge-current-microamp which it applies if less than the
>>>> battery's -max setting.
>>>
>>> Indeed.
>>>
>>>> Or you could set that in userspace via
>>>> /sys/class.../constant_charge_current.
>>>
>>> The goal is to have both. The DT for default values (given by the
>>> vendor/upstream) and sysfs for custom values (interesting if you don't
>>> want to/can't recompile a DT.
>>>
>>>> The charger's -max value would
>>>> be a characteristic of its regulator.
>>>>
>>>
>>> I don't really understand what you mean by that.
>>
>> I believe the pmic's -max value is a characteristic of its electrical
>> design, the max current it can deliver. The power_supply_class docs
>> are not very clear - "maximum charge current supported by the power
>> supply object".
>>
>
> This PMIC can deliver a maximum of 1.8A or 2.5A depending on the variant
> for constant charge current but you do not want to easily allow your
> user to put such a high value as the battery is most likely not able to
> handle such a high current.
Right, and /sys/class.../constant_charge_current_max should probably
report exactly that. Hence the suggestion for ccc_max_local for the
adjustable ccc_max.
We really shouldn't be wondering what do do here, but alas, the kernel
power-supply framework is a bit under-developed :-p
Anyway I plan to add constant-charge-current-max-microamp in the
forthcoming patchset.
>>>> Or am I missing something...?
>>>>
>>>>>> Rob & Sebastian want me to merge all items for
>>>>>> bindings/power/supply/battery.txt. If I do that I'll also roll up
>>>>>> their counterparts in power_supply_core.c and submit a patchset for
>>>>>> those two files.
>>>>>>
>>>>>
>>>>> I guess that adding the two properties make sense, don't you think?
>>>>>
>>>>> Also, could you Cc me on your next version of your patches? So I know
>>>>> when to rebase and slightly rework my patches once your patch series is
>>>>> merged.
>>>>
>>>> Surely.
>>>>
>>>>> Thanks,
>>>>> Quentin
>>>>>
>>>>>>> You may program your charger's -current with the battery's
>>>>>>> -current-max, of course.
>>>>>>>
>>>>>>> Note that your charger also has a -current-max characteristic, likely
>>>>>>> different than your battery. You may not need that in DT tho.
>>>>>>>
>>>>>>>>> constant-charge-voltage-microvolt
>>>>>>>>> constant-charge-voltage-max-microvolt
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>>>> Must be constant-charge-current-microamp for the reasons discussed in
>>>>>>>>>>> battery.txt - consistency with sysfs names.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hum. Just nitpicking, but I disagree with the use of 'must'. IIRC there
>>>>>>>>>> is nothing in the code that would require the property to be named after
>>>>>>>>>> a property from the enum power_supply_property.
>>>>>>>>>>
>>>>>>>>>> I would say that you _want_ it to be named like that because it
>>>>>>>>>> underlines the relation between the DT property and the actual impacted
>>>>>>>>>> property in the power supply subsystem. I'm fine with this reason but in
>>>>>>>>>> the end, the maintainer's opinion prevails (if (s)he does not want it,
>>>>>>>>>> (s)he will not take it). So, basically, I actually don't mind either
>>>>>>>>>> option and I see arguments on each side.
>>>>>>>>>>
>>>>>>>>>> So, just waiting for maintainer's opinion to make the final version of
>>>>>>>>>> this patch.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Quentin
>>>>>>>>>>
>>>>>>>>>>> Also applies to power_supply_core.c patch.
>>>>>>>>>>>
>>>>>>>>>>> Rob: enum power_supply_property also lists constant-charge-voltage,
>>>>>>>>>>> hence the -current
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> added in v3
>>>>>>>>>>>>
>>>>>>>>>>>> Documentation/devicetree/bindings/power/supply/battery.txt | 2 ++
>>>>>>>>>>>> 1 file changed, 2 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/power/supply/battery.txt b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>>> index 0278617..9594e1e 100644
>>>>>>>>>>>> --- a/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/power/supply/battery.txt
>>>>>>>>>>>> @@ -7,6 +7,7 @@ Optional Properties:
>>>>>>>>>>>> - voltage-min-design-microvolt: drained battery voltage
>>>>>>>>>>>> - energy-full-design-microwatt-hours: battery design energy
>>>>>>>>>>>> - charge-full-design-microamp-hours: battery design capacity
>>>>>>>>>>>> + - constant-charge-microamp: battery constant charge current
>>>>>>>>>>>>
>>>>>>>>>>>> Because drivers surface properties in sysfs using names derived
>>>>>>>>>>>> from enum power_supply_property, e.g.
>>>>>>>>>>>> @@ -30,6 +31,7 @@ Example:
>>>>>>>>>>>> voltage-min-design-microvolt = <3200000>;
>>>>>>>>>>>> energy-full-design-microwatt-hours = <5290000>;
>>>>>>>>>>>> charge-full-design-microamp-hours = <1430000>;
>>>>>>>>>>>> + constant-charge-microamp = <300000>;
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> charger: charger@11 {
>>>>>>>>>>>> --
>>>>>>>>>>>> 2.9.3
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Quentin Schulz, Free Electrons
>>>>>>>>>> Embedded Linux and Kernel engineering
>>>>>>>>>> http://free-electrons.com
>>>>>>>>
>>>>>>>> --
>>>>>>>> Quentin Schulz, Free Electrons
>>>>>>>> Embedded Linux and Kernel engineering
>>>>>>>> http://free-electrons.com
>>>>>
>>>>> --
>>>>> Quentin Schulz, Free Electrons
>>>>> Embedded Linux and Kernel engineering
>>>>> http://free-electrons.com
>>>
>>> --
>>> Quentin Schulz, Free Electrons
>>> Embedded Linux and Kernel engineering
>>> http://free-electrons.com
>
> --
> Quentin Schulz, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver
From: Dong Aisheng @ 2017-03-30 7:15 UTC (permalink / raw)
To: Andrey Smirnov
Cc: Shawn Guo, Andrey Yurovsky, Lucas Stach, Rob Herring,
Mark Rutland, Fabio Estevam, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <CAHQ1cqH4HnVsiAT6wxVJ=b-AJKWCK6L7kTxLZ7JFrZ4B-t2PQg@mail.gmail.com>
On Mon, Mar 27, 2017 at 11:42:51AM -0700, Andrey Smirnov wrote:
> On Thu, Mar 23, 2017 at 11:32 PM, Dong Aisheng <dongas86@gmail.com> wrote:
> > On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote:
> >> Add DT bindings for power domain driver for GPCv2 IP block found in
> >> i.MX7 SoCs.
> >>
> >> Cc: yurovsky@gmail.com
> >> Cc: Lucas Stach <l.stach@pengutronix.de>
> >> Cc: Rob Herring <robh+dt@kernel.org>
> >> Cc: Mark Rutland <mark.rutland@arm.com>
> >> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >> Cc: Dong Aisheng <dongas86@gmail.com>
> >> Cc: devicetree@vger.kernel.org
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Acked-by: Rob Herring <robh@kernel.org>
> >> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> >> ---
> >> .../devicetree/bindings/power/fsl,imx-gpcv2.txt | 71 ++++++++++++++++++++++
> >> include/dt-bindings/power/imx7-power.h | 18 ++++++
> >> 2 files changed, 89 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> >> create mode 100644 include/dt-bindings/power/imx7-power.h
> >>
> >> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> >> new file mode 100644
> >> index 0000000..02f45c6
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> >> @@ -0,0 +1,71 @@
> >> +Freescale i.MX General Power Controller v2
> >> +==========================================
> >> +
> >> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
> >> +Control (PGC) for various power domains.
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: Should be "fsl,imx7d-gpc"
> >> +
> >> +- reg: should be register base and length as documented in the
> >> + datasheet
> >> +
> >> +- interrupts: Should contain GPC interrupt request 1
> >> +
> >> +Power domains contained within GPC node are generic power domain
> >> +providers, documented in
> >> +Documentation/devicetree/bindings/power/power_domain.txt, which are
> >> +described as subnodes of the power gating controller 'pgc' node,
> >> +which, in turn, is expected to contain the following:
> >> +
> >> +Required properties:
> >> +
> >> +- reg: Power domain index. Valid values are defined in
> >> + include/dt-bindings/power/imx7-power.h
> >> +
> >> +- #power-domain-cells: Should be 0
> >> +
> >> +Optional properties:
> >> +
> >> +- power-supply: Power supply used to power the domain
> >> +
> >> +Example:
> >> +
> >> + gpc: gpc@303a0000 {
> >> + compatible = "fsl,imx7d-gpc";
> >> + reg = <0x303a0000 0x1000>;
> >> + interrupt-controller;
> >> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> >> + #interrupt-cells = <3>;
> >> + interrupt-parent = <&intc>;
> >> +
> >> + pgc {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + pgc_pcie_phy: power-domain@3 {
> >> + #power-domain-cells = <0>;
> >> +
> >> + reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
> >> + power-supply = <®_1p0d>;
> >> + };
> >> + };
> >> + };
> >> +
> >> +
> >> +Specifying power domain for IP modules
> >> +======================================
> >> +
> >> +IP cores belonging to a power domain should contain a 'power-domains'
> >> +property that is a phandle for PGC node representing the domain.
> >> +
> >> +Example of a device that is part of the PCIE_PHY power domain:
> >> +
> >> + pcie: pcie@33800000 {
> >> + reg = <0x33800000 0x4000>,
> >> + <0x4ff00000 0x80000>;
> >> + /* ... */
> >> + power-domains = <&pgc_pcie_phy>;
> >> + /* ... */
> >> + };
> >> diff --git a/include/dt-bindings/power/imx7-power.h b/include/dt-bindings/power/imx7-power.h
> >> new file mode 100644
> >> index 0000000..eb70023
> >> --- /dev/null
> >> +++ b/include/dt-bindings/power/imx7-power.h
> >> @@ -0,0 +1,18 @@
> >> +/*
> >> + * Copyright (C) 2017 Impinj
> >> + *
> >> + * This program 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.
> >> + */
> >> +
> >> +#ifndef __DT_BINDINGS_IMX7_POWER_H__
> >> +#define __DT_BINDINGS_IMX7_POWER_H__
> >> +
> >> +#define IMX7_POWER_DOMAIN_USB_HSIC_PHY 0
> >> +#define IMX7_POWER_DOMAIN_USB_OTG2_PHY 1
> >> +#define IMX7_POWER_DOMAIN_USB_OTG1_PHY 2
> >> +#define IMX7_POWER_DOMAIN_PCIE_PHY 3
> >> +#define IMX7_POWER_DOMAIN_MIPI_PHY 4
> >
> > Nitpick: Probably better to define according to the reference manual
> > defined order.
> >
> > 0x800 ~ 0x83F : PGC for A7 core0
> > 0x840 ~ 0x87F: PGC for A7 core1
> > 0x880 ~ 0x8BF: PGC for A7 SCU
> > 0xA00 ~ 0xA3F: PGC for fastmix/megamix
> > 0xC00 ~ 0xC3F: PGC for MIPI PHY
> > 0xC40 ~ 0xC7F: PGC for PCIE_PHY
> > 0xC80 ~ 0xCBF: Reserved
> > 0xCC0 ~ 0xCFF: Reserved
> > 0xD00 ~ 0xD3F: PGC for USB HSIC PHY
> >
> > You can drop A7 core/scu/fastmix/megamix as well.
> >
>
> Sure, will do.
>
BTW, i read some other SoC power domain implementations,
they keep the CPU domains although not used in kernel.
e.g.
include/dt-bindings/power/rk3288-power.h
include/soc/tegra/pmc.h
That probably is a good reference in case we may need them in the future.
And device tree actually is describe HW.
I wonder we may be better to keep them as well.
Regards
Dong Aisheng
> Thanks,
> Andrey Smirnov
^ permalink raw reply
* Re: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD driver
From: Lothar Waßmann @ 2017-03-30 7:08 UTC (permalink / raw)
To: Lucas Stach
Cc: A.S. Dong, devicetree@vger.kernel.org,
patchwork-lst@pengutronix.de, kernel@pengutronix.de,
Fabio Estevam, Shawn Guo, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1490804026.29083.29.camel@pengutronix.de>
Hi,
On Wed, 29 Mar 2017 18:13:46 +0200 Lucas Stach wrote:
> Am Mittwoch, den 29.03.2017, 16:08 +0000 schrieb A.S. Dong:
> > Hi Lucas,
> >
> > > -----Original Message-----
> > > From: Lucas Stach [mailto:l.stach@pengutronix.de]
> > > Sent: Thursday, March 23, 2017 10:44 PM
> > > To: Shawn Guo
> > > Cc: Fabio Estevam; A.S. Dong; devicetree@vger.kernel.org; linux-arm-
> > > kernel@lists.infradead.org; kernel@pengutronix.de; patchwork-
> > > lst@pengutronix.de
> > > Subject: [PATCH 2/2] soc/imx: add workaround for i.MX6QP to the GPC PD
> > > driver
> > >
> > > On i.MX6QP, due to hardware erratum ERR009619, the PRE clocks may be
> > > stalled during the power up sequencing of the PU power domain. As this may
> > > lead to a complete loss of display output, the recommended workaround is
> > > to keep the PU domain enabled during normal system operation.
> > >
> > > Implement this by rejecting the domain power down request on the affected
> > > SoC.
> > >
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > > ---
> > > drivers/soc/imx/gpc.c | 19 +++++++++++++++++++
> > > 1 file changed, 19 insertions(+)
> > >
> > > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c index
> > > 4294287e5f6c..599e1e46f694 100644
> > > --- a/drivers/soc/imx/gpc.c
> > > +++ b/drivers/soc/imx/gpc.c
> > > @@ -45,6 +45,7 @@ struct imx_pm_domain {
> > > unsigned int reg_offs;
> > > signed char cntr_pdn_bit;
> > > unsigned int ipg_rate_mhz;
> > > + bool allow_dynamic_pd;
> > > };
> > >
> > > static inline struct imx_pm_domain *
> > > @@ -59,6 +60,9 @@ static int imx6_pm_domain_power_off(struct
> > > generic_pm_domain *genpd)
> > > int iso, iso2sw;
> > > u32 val;
> > >
> > > + if (!pd->allow_dynamic_pd)
> > > + return -EBUSY;
> > > +
> > > /* Read ISO and ISO2SW power down delays */
> > > regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
> > > iso = val & 0x3f;
> > > @@ -255,6 +259,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > > },
> > > .reg_offs = 0x260,
> > > .cntr_pdn_bit = 0,
> > > + .allow_dynamic_pd = true,
> > > }, {
> > > .base = {
> > > .name = "DISPLAY",
> > > @@ -263,23 +268,33 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> > > },
> > > .reg_offs = 0x240,
> > > .cntr_pdn_bit = 4,
> > > + .allow_dynamic_pd = true,
> >
> > Just a Nitpick, besides shawn's comment in another mail,
> > if we use a domain flag like IMX_PD_ALWAYS_ON set by SoC errata flag,
> > then probably we can save all the default allow_dynamic_pd lines.
> > This also release the life when adding new domains.
>
> If other things like that show up we can certainly switch to a flags
> field. In the meantime I like that the current style is more explicit
> about it.
>
Since the purpose of the driver is all about dynamic power management,
I would rather add a 'disable_dynamic_pd' for the case(s) where it's
not allowed, rather than having to state the obvious over and over
again.
Lothar Waßmann
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: dts: add pinctrl dtsi file for HiKey960 development board
From: Wang Xiaoyin @ 2017-03-30 6:48 UTC (permalink / raw)
To: xuwei5, robh+dt, mark.rutland, catalin.marinas, will.deacon,
linux-arm-kernel, devicetree, linux-kernel
Cc: hw.wangxiaoyin, chenya99
In-Reply-To: <20170330064803.18648-1-hw.wangxiaoyin@hisilicon.com>
Add pinctrl dtsi file for HiKey960 development board, enable
5 pinmux devices and 1 pinconf device, also include some nodes
of configurations for pins.
Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 1 +
.../arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi | 407 +++++++++++++++++++++
2 files changed, 408 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
index ff37f0a0aa93..186251ffc6b2 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts
@@ -8,6 +8,7 @@
/dts-v1/;
#include "hi3660.dtsi"
+#include "hikey960-pinctrl.dtsi"
/ {
model = "HiKey960";
diff --git a/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
new file mode 100644
index 000000000000..c2096c6f46c4
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hikey960-pinctrl.dtsi
@@ -0,0 +1,407 @@
+/*
+ * pinctrl dts fils for Hislicon HiKey960 development board
+ *
+ */
+
+#include <dt-bindings/pinctrl/hisi.h>
+
+/ {
+ soc {
+ /* [IOMG_000, IOMG_123] */
+ range: gpio-range {
+ #pinctrl-single,gpio-range-cells = <3>;
+ };
+ pmx0: pinmux@e896c000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xe896c000 0x0 0x1f0>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <
+ &range 0 7 0
+ &range 8 116 0>;
+
+ isp0_pmx_func: isp0_pmx_func {
+ pinctrl-single,pins = <
+ 0x058 MUX_M1 /* ISP_CLK0 */
+ 0x064 MUX_M1 /* ISP_SCL0 */
+ 0x068 MUX_M1 /* ISP_SDA0 */
+ >;
+ };
+
+ isp1_pmx_func: isp1_pmx_func {
+ pinctrl-single,pins = <
+ 0x05c MUX_M1 /* ISP_CLK1 */
+ 0x06c MUX_M1 /* ISP_SCL1 */
+ 0x070 MUX_M1 /* ISP_SDA1 */
+ >;
+ };
+
+ i2c3_pmx_func: i2c3_pmx_func {
+ pinctrl-single,pins = <
+ 0x02c MUX_M1 /* I2C3_SCL */
+ 0x030 MUX_M1 /* I2C3_SDA */
+ >;
+ };
+
+ i2c4_pmx_func: i2c4_pmx_func {
+ pinctrl-single,pins = <
+ 0x090 MUX_M1 /* I2C4_SCL */
+ 0x094 MUX_M1 /* I2C4_SDA */
+ >;
+ };
+
+ pcie_perstn_pmx_func: pcie_perstn_pmx_func {
+ pinctrl-single,pins = <
+ 0x15c MUX_M1 /* PCIE_PERST_N */
+ >;
+ };
+
+ usbhub5734_pmx_func: usbhub5734_pmx_func {
+ pinctrl-single,pins = <
+ 0x11c MUX_M0 /* GPIO_073 */
+ 0x120 MUX_M0 /* GPIO_074 */
+ >;
+ };
+
+ spi1_pmx_func: spi1_pmx_func {
+ pinctrl-single,pins = <
+ 0x034 MUX_M1 /* SPI1_CLK */
+ 0x038 MUX_M1 /* SPI1_DI */
+ 0x03c MUX_M1 /* SPI1_DO */
+ 0x040 MUX_M1 /* SPI1_CS_N */
+ >;
+ };
+
+ uart0_pmx_func: uart0_pmx_func {
+ pinctrl-single,pins = <
+ 0x0cc MUX_M2 /* UART0_RXD */
+ 0x0d0 MUX_M2 /* UART0_TXD */
+ 0x0d4 MUX_M2 /* UART0_RXD_M */
+ 0x0d8 MUX_M2 /* UART0_TXD_M */
+ >;
+ };
+
+ uart1_pmx_func: uart1_pmx_func {
+ pinctrl-single,pins = <
+ 0x0b0 MUX_M2 /* UART1_CTS_N */
+ 0x0b4 MUX_M2 /* UART1_RTS_N */
+ 0x0a8 MUX_M2 /* UART1_RXD */
+ 0x0ac MUX_M2 /* UART1_TXD */
+ >;
+ };
+
+ uart2_pmx_func: uart2_pmx_func {
+ pinctrl-single,pins = <
+ 0x0bc MUX_M2 /* UART2_CTS_N */
+ 0x0c0 MUX_M2 /* UART2_RTS_N */
+ 0x0c8 MUX_M2 /* UART2_RXD */
+ 0x0c4 MUX_M2 /* UART2_TXD */
+ >;
+ };
+
+ uart3_pmx_func: uart3_pmx_func {
+ pinctrl-single,pins = <
+ 0x0dc MUX_M1 /* UART3_CTS_N */
+ 0x0e0 MUX_M1 /* UART3_RTS_N */
+ 0x0e4 MUX_M1 /* UART3_RXD */
+ 0x0e8 MUX_M1 /* UART3_TXD */
+ >;
+ };
+
+ uart4_pmx_func: uart4_pmx_func {
+ pinctrl-single,pins = <
+ 0x0ec MUX_M1 /* UART4_CTS_N */
+ 0x0f0 MUX_M1 /* UART4_RTS_N */
+ 0x0f4 MUX_M1 /* UART4_RXD */
+ 0x0f8 MUX_M1 /* UART4_TXD */
+ >;
+ };
+
+ uart5_pmx_func: uart5_pmx_func {
+ pinctrl-single,pins = <
+ 0x0c4 MUX_M3 /* UART5_CTS_N */
+ 0x0c8 MUX_M3 /* UART5_RTS_N */
+ 0x0bc MUX_M3 /* UART5_RXD */
+ 0x0c0 MUX_M3 /* UART5_TXD */
+ >;
+ };
+
+ uart6_pmx_func: uart6_pmx_func {
+ pinctrl-single,pins = <
+ 0x0cc MUX_M1 /* UART6_CTS_N */
+ 0x0d0 MUX_M1 /* UART6_RTS_N */
+ 0x0d4 MUX_M1 /* UART6_RXD */
+ 0x0d8 MUX_M1 /* UART6_TXD */
+ >;
+ };
+ };
+
+ /* [IOMG_MMC0_000, IOMG_MMC0_005] */
+ pmx1: pinmux@ff37e000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff37e000 0x0 0x18>;
+ #gpio-range-cells = <0x3>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 6 0>;
+
+ sd_pmx_func: sd_pmx_func {
+ pinctrl-single,pins = <
+ 0x000 MUX_M1 /* SD_CLK */
+ 0x004 MUX_M1 /* SD_CMD */
+ 0x008 MUX_M1 /* SD_DATA0 */
+ 0x00c MUX_M1 /* SD_DATA1 */
+ 0x010 MUX_M1 /* SD_DATA2 */
+ 0x014 MUX_M1 /* SD_DATA3 */
+ >;
+ };
+ };
+
+ /* [IOMG_FIX_000, IOMG_FIX_011] */
+ pmx2: pinmux@ff3b6000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff3b6000 0x0 0x30>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 12 0>;
+
+ spi3_pmx_func: spi3_pmx_func {
+ pinctrl-single,pins = <
+ 0x008 MUX_M1 /* SPI3_CLK */
+ 0x00c MUX_M1 /* SPI3_DI */
+ 0x010 MUX_M1 /* SPI3_DO */
+ 0x014 MUX_M1 /* SPI3_CS0_N */
+ >;
+ };
+ };
+
+ /* [IOMG_MMC1_000, IOMG_MMC1_005] */
+ pmx3: pinmux@ff3fd000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xff3fd000 0x0 0x18>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 6 0>;
+
+ sdio_pmx_func: sdio_pmx_func {
+ pinctrl-single,pins = <
+ 0x000 MUX_M1 /* SDIO_CLK */
+ 0x004 MUX_M1 /* SDIO_CMD */
+ 0x008 MUX_M1 /* SDIO_DATA0 */
+ 0x00c MUX_M1 /* SDIO_DATA1 */
+ 0x010 MUX_M1 /* SDIO_DATA2 */
+ 0x014 MUX_M1 /* SDIO_DATA3 */
+ >;
+ };
+ };
+
+ /* [IOMG_AO_000, IOMG_AO_041] */
+ pmx4: pinmux@fff11000 {
+ compatible = "pinctrl-single";
+ reg = <0x0 0xfff11000 0x0 0xa8>;
+ #pinctrl-cells = <1>;
+ #gpio-range-cells = <0x3>;
+ pinctrl-single,register-width = <0x20>;
+ pinctrl-single,function-mask = <0x7>;
+ /* pin base in node, nr pins & gpio function */
+ pinctrl-single,gpio-range = <&range 0 42 0>;
+
+ i2s2_pmx_func: i2s2_pmx_func {
+ pinctrl-single,pins = <
+ 0x044 MUX_M1 /* I2S2_DI */
+ 0x048 MUX_M1 /* I2S2_DO */
+ 0x04c MUX_M1 /* I2S2_XCLK */
+ 0x050 MUX_M1 /* I2S2_XFS */
+ >;
+ };
+
+ slimbus_pmx_func: slimbus_pmx_func {
+ pinctrl-single,pins = <
+ 0x02c MUX_M1 /* SLIMBUS_CLK */
+ 0x030 MUX_M1 /* SLIMBUS_DATA */
+ >;
+ };
+
+ i2c0_pmx_func: i2c0_pmx_func {
+ pinctrl-single,pins = <
+ 0x014 MUX_M1 /* I2C0_SCL */
+ 0x018 MUX_M1 /* I2C0_SDA */
+ >;
+ };
+
+ i2c1_pmx_func: i2c1_pmx_func {
+ pinctrl-single,pins = <
+ 0x01c MUX_M1 /* I2C1_SCL */
+ 0x020 MUX_M1 /* I2C1_SDA */
+ >;
+ };
+
+ i2c2_pmx_func: i2c2_pmx_func {
+ pinctrl-single,pins = <
+ 0x024 MUX_M1 /* I2C2_SCL */
+ 0x028 MUX_M1 /* I2C2_SDA */
+ >;
+ };
+
+ i2c7_pmx_func: i2c7_pmx_func {
+ pinctrl-single,pins = <
+ 0x024 MUX_M3 /* I2C7_SCL */
+ 0x028 MUX_M3 /* I2C7_SDA */
+ >;
+ };
+
+ spi2_pmx_func: spi2_pmx_func {
+ pinctrl-single,pins = <
+ 0x08c MUX_M1 /* SPI2_CLK */
+ 0x090 MUX_M1 /* SPI2_DI */
+ 0x094 MUX_M1 /* SPI2_DO */
+ 0x098 MUX_M1 /* SPI2_CS0_N */
+ >;
+ };
+
+ spi4_pmx_func: spi4_pmx_func {
+ pinctrl-single,pins = <
+ 0x08c MUX_M4 /* SPI4_CLK */
+ 0x090 MUX_M4 /* SPI4_DI */
+ 0x094 MUX_M4 /* SPI4_DO */
+ 0x098 MUX_M4 /* SPI4_CS0_N */
+ >;
+ };
+
+ i2s0_pmx_func: i2s0_pmx_func {
+ pinctrl-single,pins = <
+ 0x034 MUX_M1 /* I2S0_DI */
+ 0x038 MUX_M1 /* I2S0_DO */
+ 0x03c MUX_M1 /* I2S0_XCLK */
+ 0x040 MUX_M1 /* I2S0_XFS */
+ >;
+ };
+ };
+
+ pmx5: pinmux@ff3fd800 {
+ compatible = "pinconf-single";
+ reg = <0x0 0xff3fd800 0x0 0x18>;
+ #pinctrl-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ pinctrl-single,register-width = <32>;
+
+ sdio_clk_cfg_func: sdio_clk_cfg_func {
+ pinctrl-single,pins = <
+ 0x000 0x0 /* SDIO_CLK */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_DIS
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_32MA
+ DRIVE6_MASK
+ >;
+ };
+
+ sdio_cfg_func: sdio_cfg_func {
+ pinctrl-single,pins = <
+ 0x004 0x0 /* SDIO_CMD */
+ 0x008 0x0 /* SDIO_DATA0 */
+ 0x00c 0x0 /* SDIO_DATA1 */
+ 0x010 0x0 /* SDIO_DATA2 */
+ 0x014 0x0 /* SDIO_DATA3 */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_UP
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_19MA
+ DRIVE6_MASK
+ >;
+ };
+ };
+
+ pmx6: pinmux@ff37e800 {
+ compatible = "pinconf-single";
+ reg = <0x0 0xff37e800 0x0 0x18>;
+ #pinctrl-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ pinctrl-single,register-width = <32>;
+
+ sd_clk_cfg_func: sd_clk_cfg_func {
+ pinctrl-single,pins = <
+ 0x000 0x0 /* SD_CLK */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_DIS
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_32MA
+ DRIVE6_MASK
+ >;
+ };
+
+ sd_cfg_func: sd_cfg_func {
+ pinctrl-single,pins = <
+ 0x004 0x0 /* SD_CMD */
+ 0x008 0x0 /* SD_DATA0 */
+ 0x00c 0x0 /* SD_DATA1 */
+ 0x010 0x0 /* SD_DATA2 */
+ 0x014 0x0 /* SD_DATA3 */
+ >;
+ pinctrl-single,bias-pulldown = <
+ PULL_DIS
+ PULL_DOWN
+ PULL_DIS
+ PULL_DOWN
+ >;
+ pinctrl-single,bias-pullup = <
+ PULL_UP
+ PULL_UP
+ PULL_DIS
+ PULL_UP
+ >;
+ pinctrl-single,drive-strength = <
+ DRIVE6_19MA
+ DRIVE6_MASK
+ >;
+ };
+ };
+
+ };
+};
--
2.11.0-rc2
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: add drive-strength levels of pin for Hi3660 SoC
From: Wang Xiaoyin @ 2017-03-30 6:48 UTC (permalink / raw)
To: xuwei5, robh+dt, mark.rutland, catalin.marinas, will.deacon,
linux-arm-kernel, devicetree, linux-kernel
Cc: hw.wangxiaoyin, chenya99
Add drive-strength levels of pin for Hi3660 Soc.
Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@hisilicon.com>
---
include/dt-bindings/pinctrl/hisi.h | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/include/dt-bindings/pinctrl/hisi.h b/include/dt-bindings/pinctrl/hisi.h
index 38f1ea879ea1..0359bfdc9119 100644
--- a/include/dt-bindings/pinctrl/hisi.h
+++ b/include/dt-bindings/pinctrl/hisi.h
@@ -56,4 +56,19 @@
#define DRIVE4_08MA (4 << 4)
#define DRIVE4_10MA (6 << 4)
+/* drive strength definition for hi3660 */
+#define DRIVE6_MASK (15 << 4)
+#define DRIVE6_04MA (0 << 4)
+#define DRIVE6_12MA (4 << 4)
+#define DRIVE6_19MA (8 << 4)
+#define DRIVE6_27MA (10 << 4)
+#define DRIVE6_32MA (15 << 4)
+#define DRIVE7_02MA (0 << 4)
+#define DRIVE7_04MA (1 << 4)
+#define DRIVE7_06MA (2 << 4)
+#define DRIVE7_08MA (3 << 4)
+#define DRIVE7_10MA (4 << 4)
+#define DRIVE7_12MA (5 << 4)
+#define DRIVE7_14MA (6 << 4)
+#define DRIVE7_16MA (7 << 4)
#endif
--
2.11.0-rc2
^ permalink raw reply related
* [PATCH v3 16/37] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
From: Masahiro Yamada @ 2017-03-30 6:46 UTC (permalink / raw)
To: linux-mtd
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada, devicetree,
linux-kernel, Brian Norris, Richard Weinberger, Cyrille Pitchen,
Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro@socionext.com>
Add two compatible strings for UniPhier SoCs.
"socionext,uniphier-denali-nand-v5a" is used on UniPhier sLD3, LD4,
Pro4, sLD8 SoCs.
"socionext,uniphier-denali-nand-v5b" is used on UniPhier Pro5, PXs2,
LD6b, LD11, LD20 SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v3: None
Changes in v2:
- Change the compatible strings
- Fix the ecc_strength_capability
- Override revision number for the newer one
.../devicetree/bindings/mtd/denali-nand.txt | 6 ++++++
drivers/mtd/nand/denali_dt.c | 23 ++++++++++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 647618e..0b08ea5 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -3,6 +3,8 @@
Required properties:
- compatible : should be one of the following:
"altr,socfpga-denali-nand" - for Altera SOCFPGA
+ "socionext,uniphier-denali-nand-v5a" - for Socionext UniPhier (v5a)
+ "socionext,uniphier-denali-nand-v5b" - for Socionext UniPhier (v5b)
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
@@ -10,9 +12,13 @@ Required properties:
Optional properties:
- nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
512 for "altr,socfpga-denali-nand"
+ 1024 for "socionext,uniphier-denali-nand-v5a"
+ 1024 for "socionext,uniphier-denali-nand-v5b"
see nand.txt for details.
- nand-ecc-strength: see nand.txt for details. Available values are:
8, 15 for "altr,socfpga-denali-nand"
+ 8, 16, 24 for "socionext,uniphier-denali-nand-v5a"
+ 8, 16 for "socionext,uniphier-denali-nand-v5b"
- nand-ecc-maximize: see nand.txt for details
Note:
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index c3bc333..1f2f68a 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -41,11 +41,34 @@ static const struct denali_dt_data denali_socfpga_data = {
DENALI_CAP_ECC_SIZE_512,
};
+static const struct denali_dt_data denali_uniphier_v5a_data = {
+ .ecc_strength_avail = BIT(24) | BIT(16) | BIT(8),
+ .caps = DENALI_CAP_HW_ECC_FIXUP |
+ DENALI_CAP_DMA_64BIT |
+ DENALI_CAP_ECC_SIZE_1024,
+};
+
+static const struct denali_dt_data denali_uniphier_v5b_data = {
+ .revision = 0x0501,
+ .ecc_strength_avail = BIT(16) | BIT(8),
+ .caps = DENALI_CAP_HW_ECC_FIXUP |
+ DENALI_CAP_DMA_64BIT |
+ DENALI_CAP_ECC_SIZE_1024,
+};
+
static const struct of_device_id denali_nand_dt_ids[] = {
{
.compatible = "altr,socfpga-denali-nand",
.data = &denali_socfpga_data,
},
+ {
+ .compatible = "socionext,uniphier-denali-nand-v5a",
+ .data = &denali_uniphier_v5a_data,
+ },
+ {
+ .compatible = "socionext,uniphier-denali-nand-v5b",
+ .data = &denali_uniphier_v5b_data,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
--
2.7.4
^ permalink raw reply related
* [PATCH v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Masahiro Yamada @ 2017-03-30 6:46 UTC (permalink / raw)
To: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Historically, this driver tried to choose as big ECC strength as
possible, but it would be reasonable to allow DT to set a particular
ECC strength with "nand-ecc-strength" property. This is useful
when a particular ECC setting is hard-coded by firmware (or hard-
wired by boot ROM).
If no ECC strength is specified in DT, "nand-ecc-maximize" is implied
since this was the original behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v3: None
Changes in v2:
- Add available values in the binding document
Documentation/devicetree/bindings/mtd/denali-nand.txt | 6 ++++++
drivers/mtd/nand/denali.c | 18 ++++++++++++++++--
drivers/mtd/nand/denali_pci.c | 1 +
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 25313c7..647618e 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -11,6 +11,12 @@ Optional properties:
- nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
512 for "altr,socfpga-denali-nand"
see nand.txt for details.
+ - nand-ecc-strength: see nand.txt for details. Available values are:
+ 8, 15 for "altr,socfpga-denali-nand"
+ - nand-ecc-maximize: see nand.txt for details
+
+Note:
+Either nand-ecc-strength or nand-ecc-maximize should be specified.
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index ce87b95..2f796e3 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1641,9 +1641,23 @@ int denali_init(struct denali_nand_info *denali)
goto failed_req_irq;
}
- ret = denali_set_max_ecc_strength(denali);
- if (ret)
+ if (!chip->ecc.strength && !(chip->ecc.options & NAND_ECC_MAXIMIZE)) {
+ dev_info(denali->dev,
+ "No ECC strength strategy is specified. Maximizing ECC strength\n");
+ chip->ecc.options |= NAND_ECC_MAXIMIZE;
+ }
+
+ if (chip->ecc.options & NAND_ECC_MAXIMIZE) {
+ ret = denali_set_max_ecc_strength(denali);
+ if (ret)
+ goto failed_req_irq;
+ } else if (!(denali->ecc_strength_avail & BIT(chip->ecc.strength))) {
+ dev_err(denali->dev,
+ "ECC strength %d is not supported on this controller.\n",
+ chip->ecc.strength);
+ ret = -EINVAL;
goto failed_req_irq;
+ }
chip->ecc.bytes = denali_calc_ecc_bytes(chip->ecc.size,
chip->ecc.strength);
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index a1ee9f8..a39682a5 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -87,6 +87,7 @@ static int denali_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
denali->ecc_strength_avail = BIT(15) | BIT(8);
denali->caps |= DENALI_CAP_ECC_SIZE_512;
+ denali->nand.ecc.options |= NAND_ECC_MAXIMIZE;
ret = denali_init(denali);
if (ret)
--
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 v3 12/37] mtd: nand: denali: support 1024 byte ECC step size
From: Masahiro Yamada @ 2017-03-30 6:45 UTC (permalink / raw)
To: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Richard Weinberger, Cyrille Pitchen, Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
This driver was originally written for the Intel MRST platform with
several platform specific parameters hard-coded. Another thing we
need to fix is the hard-coded ECC step size. Currently, it is
defined as follows:
#define ECC_SECTOR_SIZE 512
(somehow, it is defined in both denali.c and denali.h)
This must be avoided because the Denali IP supports 1024B ECC size
as well. The Denali User's Guide also says supporting both 512B and
1024B ECC sectors is possible, though it would require instantiation
of two different ECC circuits. So, possible cases are:
[1] only 512B ECC size is supported
[2] only 1024B ECC size is supported
[3] both 512B and 1024B ECC sizes are supported
Newer versions of this IP need ecc.size and ecc.steps explicitly
set up via the following registers:
CFG_DATA_BLOCK_SIZE (0x6b0)
CFG_LAST_DATA_BLOCK_SIZE (0x6c0)
CFG_NUM_DATA_BLOCKS (0x6d0)
Older versions do not have such registers (they were reserved), so
write accesses are safely ignored.
This commit adds new flags DENALI_CAP_ECC_SIZE_{512,1024}.
The DT property "nand-ecc-step-size" is still optional; a reasonable
default will be chosen for [1] and [2]. For case [3], users can
force ECC size via DT in case firmware hard-codes ECC settings.
If not specified, the driver will use chip's ECC requirement as a
hint to decide the ECC size.
Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v3:
- Move DENALI_CAP_ define out of struct denali_nand_info
- Use chip->ecc_step_ds as a hint to choose chip->ecc.size
where possible
Changes in v2:
- Change the capability prefix DENALI_CAPS_ -> DENALI_CAP_
- Make ECC 512 cap and ECC 1024 cap independent
- Set up three CFG_... registers
.../devicetree/bindings/mtd/denali-nand.txt | 5 +++
drivers/mtd/nand/denali.c | 51 ++++++++++++++++------
drivers/mtd/nand/denali.h | 12 ++++-
drivers/mtd/nand/denali_dt.c | 3 +-
drivers/mtd/nand/denali_pci.c | 2 +
5 files changed, 57 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index e593bbe..25313c7 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -7,6 +7,11 @@ Required properties:
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
+Optional properties:
+ - nand-ecc-step-size: must be 512 or 1024. If not specified, default to:
+ 512 for "altr,socfpga-denali-nand"
+ see nand.txt for details.
+
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 16634df..78d3b18 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -886,8 +886,6 @@ static int denali_hw_ecc_fixup(struct mtd_info *mtd,
return max_bitflips;
}
-#define ECC_SECTOR_SIZE 512
-
#define ECC_SECTOR(x) (((x) & ECC_ERROR_ADDRESS__SECTOR_NR) >> 12)
#define ECC_BYTE(x) (((x) & ECC_ERROR_ADDRESS__OFFSET))
#define ECC_CORRECTION_VALUE(x) ((x) & ERR_CORRECTION_INFO__BYTEMASK)
@@ -899,6 +897,7 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
struct denali_nand_info *denali,
unsigned long *uncor_ecc_flags, uint8_t *buf)
{
+ unsigned int ecc_size = denali->nand.ecc.size;
unsigned int bitflips = 0;
unsigned int max_bitflips = 0;
uint32_t err_addr, err_cor_info;
@@ -928,9 +927,9 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
* an erased sector.
*/
*uncor_ecc_flags |= BIT(err_sector);
- } else if (err_byte < ECC_SECTOR_SIZE) {
+ } else if (err_byte < ecc_size) {
/*
- * If err_byte is larger than ECC_SECTOR_SIZE, means error
+ * If err_byte is larger than ecc_size, means error
* happened in OOB, so we ignore it. It's no need for
* us to correct it err_device is represented the NAND
* error bits are happened in if there are more than
@@ -939,7 +938,7 @@ static int denali_sw_ecc_fixup(struct mtd_info *mtd,
int offset;
unsigned int flips_in_byte;
- offset = (err_sector * ECC_SECTOR_SIZE + err_byte) *
+ offset = (err_sector * ecc_size + err_byte) *
denali->devnum + err_device;
/* correct the ECC error */
@@ -1587,21 +1586,43 @@ int denali_init(struct denali_nand_info *denali)
chip->options |= NAND_NO_SUBPAGE_WRITE;
/*
+ * If the controller supports both 512B and 1024B ECC, and DT does not
+ * specify "nand-ecc-step-size", use the chip's requirement for a hint
+ * to choose ECC size.
+ */
+ if (!chip->ecc.size &&
+ denali->caps & DENALI_CAP_ECC_SIZE_512 &&
+ denali->caps & DENALI_CAP_ECC_SIZE_1024)
+ chip->ecc.size = chip->ecc_step_ds;
+
+ if (!chip->ecc.size) {
+ if (denali->caps & DENALI_CAP_ECC_SIZE_512)
+ chip->ecc.size = 512;
+ if (denali->caps & DENALI_CAP_ECC_SIZE_1024)
+ chip->ecc.size = 1024;
+ }
+
+ if (!(chip->ecc.size == 512 && denali->caps & DENALI_CAP_ECC_SIZE_512) &&
+ !(chip->ecc.size == 1024 && denali->caps & DENALI_CAP_ECC_SIZE_1024)) {
+ dev_err(denali->dev, "ECC size %d is not supported on this controller",
+ chip->ecc.size);
+ goto failed_req_irq;
+ }
+
+ /*
* Denali Controller only support 15bit and 8bit ECC in MRST,
* so just let controller do 15bit ECC for MLC and 8bit ECC for
* SLC if possible.
* */
if (!nand_is_slc(chip) &&
- (mtd->oobsize > (denali->bbtskipbytes +
- ECC_15BITS * (mtd->writesize /
- ECC_SECTOR_SIZE)))) {
+ mtd->oobsize > denali->bbtskipbytes +
+ ECC_15BITS * (mtd->writesize / chip->ecc.size)) {
/* if MLC OOB size is large enough, use 15bit ECC*/
chip->ecc.strength = 15;
chip->ecc.bytes = ECC_15BITS;
iowrite32(15, denali->flash_reg + ECC_CORRECTION);
- } else if (mtd->oobsize < (denali->bbtskipbytes +
- ECC_8BITS * (mtd->writesize /
- ECC_SECTOR_SIZE))) {
+ } else if (mtd->oobsize <
+ denali->bbtskipbytes + ECC_8BITS * (mtd->writesize / chip->ecc.size)) {
pr_err("Your NAND chip OOB is not large enough to contain 8bit ECC correction codes");
goto failed_req_irq;
} else {
@@ -1610,10 +1631,14 @@ int denali_init(struct denali_nand_info *denali)
iowrite32(8, denali->flash_reg + ECC_CORRECTION);
}
+ iowrite32(chip->ecc.size, denali->flash_reg + CFG_DATA_BLOCK_SIZE);
+ iowrite32(chip->ecc.size, denali->flash_reg + CFG_LAST_DATA_BLOCK_SIZE);
+ /* chip->ecc.steps is set by nand_scan_tail(); not available here */
+ iowrite32(mtd->writesize / chip->ecc.size,
+ denali->flash_reg + CFG_NUM_DATA_BLOCKS);
+
mtd_set_ooblayout(mtd, &denali_ooblayout_ops);
- /* override the default read operations */
- chip->ecc.size = ECC_SECTOR_SIZE;
chip->ecc.read_page = denali_read_page;
chip->ecc.read_page_raw = denali_read_page_raw;
chip->ecc.write_page = denali_write_page;
diff --git a/drivers/mtd/nand/denali.h b/drivers/mtd/nand/denali.h
index ec00485..7c24d82 100644
--- a/drivers/mtd/nand/denali.h
+++ b/drivers/mtd/nand/denali.h
@@ -265,6 +265,14 @@
#define ECC_COR_INFO__MAX_ERRORS 0x007f
#define ECC_COR_INFO__UNCOR_ERR 0x0080
+#define CFG_DATA_BLOCK_SIZE 0x6b0
+
+#define CFG_LAST_DATA_BLOCK_SIZE 0x6c0
+
+#define CFG_NUM_DATA_BLOCKS 0x6d0
+
+#define CFG_META_DATA_SIZE 0x6e0
+
#define DMA_ENABLE 0x700
#define DMA_ENABLE__FLAG 0x0001
@@ -307,8 +315,6 @@
#define MODE_10 0x08000000
#define MODE_11 0x0C000000
-#define ECC_SECTOR_SIZE 512
-
struct nand_buf {
int head;
int tail;
@@ -347,6 +353,8 @@ struct denali_nand_info {
#define DENALI_CAP_HW_ECC_FIXUP BIT(0)
#define DENALI_CAP_DMA_64BIT BIT(1)
+#define DENALI_CAP_ECC_SIZE_512 BIT(2)
+#define DENALI_CAP_ECC_SIZE_1024 BIT(3)
extern int denali_init(struct denali_nand_info *denali);
extern void denali_remove(struct denali_nand_info *denali);
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index df9ef36..1681a30 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -35,7 +35,8 @@ struct denali_dt_data {
};
static const struct denali_dt_data denali_socfpga_data = {
- .caps = DENALI_CAP_HW_ECC_FIXUP,
+ .caps = DENALI_CAP_HW_ECC_FIXUP |
+ DENALI_CAP_ECC_SIZE_512,
};
static const struct of_device_id denali_nand_dt_ids[] = {
diff --git a/drivers/mtd/nand/denali_pci.c b/drivers/mtd/nand/denali_pci.c
index ac84323..5202a11 100644
--- a/drivers/mtd/nand/denali_pci.c
+++ b/drivers/mtd/nand/denali_pci.c
@@ -85,6 +85,8 @@ static int denali_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
goto failed_remap_reg;
}
+ denali->caps |= DENALI_CAP_ECC_SIZE_512;
+
ret = denali_init(denali);
if (ret)
goto failed_remap_mem;
--
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 v3 09/37] mtd: nand: denali_dt: remove dma-mask DT property
From: Masahiro Yamada @ 2017-03-30 6:45 UTC (permalink / raw)
To: linux-mtd
Cc: Enrico Jorns, Artem Bityutskiy, Dinh Nguyen, Boris Brezillon,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, Masahiro Yamada, devicetree,
linux-kernel, Brian Norris, Richard Weinberger, Cyrille Pitchen,
Rob Herring, Mark Rutland
In-Reply-To: <1490856383-31560-1-git-send-email-yamada.masahiro@socionext.com>
The driver sets appropriate DMA mask. Delete the "dma-mask" DT
property. See [1] for negative comments for this binding.
[1] https://lkml.org/lkml/2016/2/8/57
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v3: None
Changes in v2: None
Documentation/devicetree/bindings/mtd/denali-nand.txt | 2 --
drivers/mtd/nand/denali_dt.c | 9 ---------
2 files changed, 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
index 6f4ab4c..e593bbe 100644
--- a/Documentation/devicetree/bindings/mtd/denali-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -6,7 +6,6 @@ Required properties:
- reg : should contain registers location and length for data and reg.
- reg-names: Should contain the reg names "nand_data" and "denali_reg"
- interrupts : The interrupt number.
- - dm-mask : DMA bit mask
The device tree may optionally contain sub-nodes describing partitions of the
address space. See partition.txt for more detail.
@@ -20,5 +19,4 @@ nand: nand@ff900000 {
reg = <0xff900000 0x100000>, <0xffb80000 0x10000>;
reg-names = "nand_data", "denali_reg";
interrupts = <0 144 4>;
- dma-mask = <0xffffffff>;
};
diff --git a/drivers/mtd/nand/denali_dt.c b/drivers/mtd/nand/denali_dt.c
index 9577bfd..b8a8284 100644
--- a/drivers/mtd/nand/denali_dt.c
+++ b/drivers/mtd/nand/denali_dt.c
@@ -46,8 +46,6 @@ static const struct of_device_id denali_nand_dt_ids[] = {
};
MODULE_DEVICE_TABLE(of, denali_nand_dt_ids);
-static u64 denali_dma_mask;
-
static int denali_dt_probe(struct platform_device *ofdev)
{
struct resource *denali_reg, *nand_data;
@@ -83,13 +81,6 @@ static int denali_dt_probe(struct platform_device *ofdev)
if (IS_ERR(denali->flash_mem))
return PTR_ERR(denali->flash_mem);
- if (!of_property_read_u32(ofdev->dev.of_node,
- "dma-mask", (u32 *)&denali_dma_mask)) {
- denali->dev->dma_mask = &denali_dma_mask;
- } else {
- denali->dev->dma_mask = NULL;
- }
-
dt->clk = devm_clk_get(&ofdev->dev, NULL);
if (IS_ERR(dt->clk)) {
dev_err(&ofdev->dev, "no clk available\n");
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox